dubbo的配置
在之前的文章中配置了spring boot和dubbo框架的使用（傳送門：springboot使用dubbo框架），看到了把dubbo相關的配置配置在了配置文件中。這裏官方文檔中也去講解了對應的dubbo配置的加載。
dubbo的配置加載流程
首先要知道dubbo的配置是在應用啓動階段，並且這裏的配置包括應用配置、註冊中心配置、服務配置等。
dubbo的配置來源
- Jvm System Properties，-D參數
- Externalized Coniguration， 外部化配置，這裏在文檔中提到的有zk、apollo
- ServiceConfig、ReferenceConfig等編程接口採集的配置
- 項目本地的配置文件 dubbo.properties
除了外部化配置，dubbo的配置讀取在總體上遵循了以下幾個原則：
- dubbo支持了多層級的配置，並且按預定優先級自動實現配置間的覆蓋，最終所有配置彙總到數據總線URL後，驅動後續的服務暴露、引用等流程。
- ApplicationConfig、ServiceConfig、ReferenceConfig也可以理解爲配置來源的一種，是直接面向用戶編程的配置採集方式
- 配置格式以Properties爲主，在配置上支持path-based的命名規範。
dubbo配置的覆蓋策略
dubbo的配置覆蓋策略如下圖：
這裏看到dubbo預先設置的配置覆蓋加載順序是jvm設置的啓動參數 —> 外部配置 —> spring的xml或者api配置 —> 項目中的本地文件。
這裏以上一篇中的spring boot和dubbo整合的demo來測試這個覆蓋順序。這裏外部的配置先不做演示，只去比較啓動參數、spring配置、本地dubbo.properties配置三個覆蓋順序。
我們以dubbo.protocol.port這個配置作爲示例：
- jvm啓動參數
首先配置啓動時的vm參數：
啓動之後，可以看到此時服務在dubbo-admin上顯示的端口爲我們在啓動參數中設置的20881。(配置文件中配置的是20880，這裏優先讀取的是啓動參數中的配置)
- spring配置
這裏因爲使用的是spring boot，所以在application.properties中配置即可。
這裏啓動provider項目，可以看到之前的接口下線，然後暴露服務的端口變爲了20880。
- 本地的dubbo.properties配置
在本地建立一個dubbo.properties文件，這裏寫成暴露服務的端口是20882。(這裏要主要將spring配置中配置註釋掉。)
重新啓動provider，可以看到對應的dubbo接口暴露爲了20882。
以xml配置說明不同粒度的覆蓋和優先級
由下圖可以知道這些配置標籤分爲provider側、consumer側、應用共享的配置(這裏包括application、註冊中心、monitor的配置)、還有一些子配置(方法、參數級別的配置)不同的粒度。
這些不同的粒度的配置也有對應的覆蓋關係，以timeout爲例，其他retries，loadbalance，actives等類似，都遵守粒度之間的覆蓋規則：
- 方法級別優先，接口級別次之，全局配置再次之。
- 如果級別一樣，則消費方優先，提供方次之。
其中，服務提供方配置，通過 URL 經由註冊中心傳遞給消費方。具體如下圖所示：
這裏就timeout這個超時參數，建議由服務提供方設置超時，因爲一個方法需要執行多長時間，服務提供方更清楚，如果一個消費方同時引用多個服務，就不需要關心每個服務的超時設置。
這裏的一個小tips：
引用缺省是延遲初始化的，只有引用被注入到其它 Bean，或被 getBean() 獲取，纔會初始化。如果需要飢餓加載，即沒有人引用也立即生成動態代理，可以配置：<dubbo:reference ... init="true" />