dubbo 知識總結 dubbo配置參考

dubbo官方文檔

項目的規模愈來愈大，總得解耦，不能在一個項目裏，這時候，公司採用了dubbo做爲分佈式應用，將多項業務拆分，並作了庫存服務統1、價格服務統一等等一些特殊須要統一性的服務。

做爲dubbo我也接觸了快一年的時間，總會有一些本身的對dubbo的想法。

下面是對dubbo的說明：

節點角色說明：
    Provider: 暴露服務的服務提供方。
    Consumer: 調用遠程服務的服務消費方。
    Registry: 服務註冊與發現的註冊中心。
    Monitor: 統計服務的調用次調和調用時間的監控中心。
    Container: 服務運行容器。
    調用關係說明：
0. 服務容器負責啓動，加載，運行服務提供者。
1. 服務提供者在啓動時，向註冊中心註冊本身提供的服務。
2. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。
3. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。
4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。
5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。
(1) 連通性：
註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小
監控中心負責統計各服務調用次數，調用時間等，統計先在內存彙總後每分鐘一次發送到監控中心服務器，並以報表展現
服務提供者向註冊中心註冊其提供的服務，並彙報調用時間到監控中心，此時間不包含網絡開銷
服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷
註冊中心，服務提供者，服務消費者三者之間均爲長鏈接，監控中心除外
註冊中心經過長鏈接感知服務提供者的存在，服務提供者宕機，註冊中心將當即推送事件通知消費者
註冊中心和監控中心所有宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
註冊中心和監控中心都是可選的，服務消費者能夠直連服務提供者
(2) 健狀性：

監控中心宕掉不影響使用，只是丟失部分採樣數據
數據庫宕掉後，註冊中心仍能經過緩存提供服務列表查詢，但不能註冊新服務
註冊中心對等集羣，任意一臺宕掉後，將自動切換到另外一臺
註冊中心所有宕掉後，服務提供者和服務消費者仍能經過本地緩存通信
服務提供者無狀態，任意一臺宕掉後，不影響使用
服務提供者所有宕掉後，服務消費者應用將沒法使用，並沒有限次重連等待服務提供者恢復
(3) 伸縮性：

註冊中心爲對等集羣，可動態增長機器部署實例，全部客戶端將自動發現新的註冊中心
服務提供者無狀態，可動態增長機器部署實例，註冊中心將推送新的服務提供者信息給消費者
(4) 升級性：

當服務集羣規模進一步擴大，帶動IT治理結構進一步升級，須要實現動態部署，進行流動計算，現有分佈式服務架構不會帶來阻力

當zookeeper掛掉了，其實dubbo的消費者也能訪問生產者，由於項目在啓動的時候，會去主動拉取全部生產者的地址端口等數據。每次消費者應用訪問的時候首先是從本地地址緩存中讀取。

服務提供方調試：

<!-- 提供方應用信息，用於計算依賴關係 -->
    <dubbo:application name="hello-world-app"  />

    <!-- 使用zookeeper註冊中心暴露服務地址 -->
    <dubbo:registry address="zookeeper://224.5.6.7:1234" />

    <!-- 用dubbo協議在20880端口暴露服務 這個端口可用於點對點調試-->
    <dubbo:protocol name="dubbo" port="20880" />

    <!-- 聲明須要暴露的服務接口 -->
    <dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" />

    <!-- 和本地bean同樣實現服務 -->
    <bean id="demoService" class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" />

服務消費方配置：

    <!-- 消費方應用名，用於計算依賴關係，不是匹配條件，不要與提供方同樣 -->
    <dubbo:application name="consumer-of-helloworld-app"  />

    <!-- 使用zookeeper註冊中心暴露發現服務地址 -->
    <dubbo:registry address="zookeeper://224.5.6.7:1234" />

    <!-- 生成遠程服務代理，能夠和本地bean同樣使用demoService -->
    <dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" />

官方給的文檔能夠根據包直接掃描包下含com.alibaba.dubbo.config.annotation.Service注直接解的類，但通常不採用這個，通常都是在xml文件裏面配，由於這樣能夠清楚的看到你配的全部dubbo服務提供方接口以及接口的限制條件

<!-- 掃描註解包路徑，多個包用逗號分隔，不填pacakge表示掃描當前ApplicationContext中全部的類 -->
<dubbo:annotation package="com.foo.bar.service" />

經常使用消費者的屬性

<!-- 服務啓動關閉對該服務提供者的接口是否正常的監測，也就是BarService是否能夠正常調用不影響本應用的啓動，當爲true的時候若是該接口掛了，本應用就起不起來了-->
<dubbo:reference interface="com.foo.BarService" check="false" />

<!-- 關閉全部服務的啓動時檢查 -->
<dubbo:consumer check="false" />

<!-- 配置重試次數，最好只用於讀的重試，寫操做可能會引發屢次寫入 下面三個任意一個配置就行 默認retries="0"-->
<dubbo:service retries="2" />
<dubbo:reference retries="2" />
<dubbo:reference>
    <dubbo:method name="findFoo" retries="2" />
</dubbo:reference>

dubbo調用服務的負載均衡，最後一種比較適合短期內大量參數同樣的請求

Random LoadBalance
    隨機，按權重設置隨機機率。
    在一個截面上碰撞的機率高，但調用量越大分佈越均勻，並且按機率使用權重後也比較均勻，有利於動態調整提供者權重。
RoundRobin LoadBalance
    輪循，按公約後的權重設置輪循比率。
    存在慢的提供者累積請求問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上。
LeastActive LoadBalance
    最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差。
    使慢的提供者收到更少請求，由於越慢的提供者的調用先後計數差會越大。
ConsistentHash LoadBalance
    一致性Hash，相同參數的請求老是發到同一提供者。
    當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。
    算法參見：http://en.wikipedia.org/wiki/Consistent_hashing。
    缺省只對第一個參數Hash，若是要修改，請配置<dubbo:parameter key="hash.arguments" value="0,1" />
    缺省用160份虛擬節點，若是要修改，請配置<dubbo:parameter key="hash.nodes" value="320" />
配置如：

<dubbo:service interface="..." loadbalance="roundrobin" />
或：

<dubbo:reference interface="..." loadbalance="roundrobin" />
或：

<dubbo:service interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>
或：

<dubbo:reference interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>

事件處理線程說明
    若是事件處理的邏輯能迅速完成，而且不會發起新的IO請求，好比只是在內存中記個標識，則直接在IO線程上處理更快，由於減小了線程池調度。
    但若是事件處理邏輯較慢，或者須要發起新的IO請求，好比須要查詢數據庫，則必須派發到線程池，不然IO線程阻塞，將致使不能接收其它請求。
    若是用IO線程處理事件，又在事件處理過程當中發起新的IO請求，好比在鏈接事件中發起登陸請求，會報「可能引起死鎖」異常，但不會真死鎖。
    Dispatcher
    all 全部消息都派發到線程池，包括請求，響應，鏈接事件，斷開事件，心跳等。
    direct 全部消息都不派發到線程池，所有在IO線程上直接執行。
    message 只有請求響應消息派發到線程池，其它鏈接斷開事件，心跳等消息，直接在IO線程上執行。
    execution 只請求消息派發到線程池，不含響應，響應和其它鏈接斷開事件，心跳等消息，直接在IO線程上執行。
    connection 在IO線程上，將鏈接斷開事件放入隊列，有序逐個執行，其它消息派發到線程池。
    ThreadPool
    fixed 固定大小線程池，啓動時創建線程，不關閉，一直持有。(缺省)
    cached 緩存線程池，空閒一分鐘自動刪除，須要時重建。
    limited 可伸縮線程池，但池中的線程數只會增加不會收縮。(爲避免收縮時忽然來了大流量引發的性能問題)。

配置如：
<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />

下面這個配置能夠形成服務提供方只訂閱不向註冊中心註冊

爲方便開發測試，常常會在線下共用一個全部服務可用的註冊中心，這時，若是一個正在開發中的服務提供者註冊，可能會影響消費者不能正常運行。
禁用註冊配置：
<dubbo:registry address="10.20.153.10:9090" register="false" />
或者：
<dubbo:registry address="10.20.153.10:9090?register=false" />

下面這個配置能夠形成服務消費方只註冊不向註冊中心訂閱

若是有兩個鏡像環境，兩個註冊中心，有一個服務只在其中一個註冊中心有部署，另外一個註冊中心還沒來得及部署，而兩個註冊中心的其它應用都須要依賴此服務，因此須要將服務同時註冊到兩個註冊中心，但卻不能讓此服務同時依賴兩個註冊中心的其它服務。
禁用訂閱配置：

<dubbo:registry id="hzRegistry" address="10.20.153.10:9090" />
<dubbo:registry id="qdRegistry" address="10.20.141.150:9090" subscribe="false" />
或者：
<dubbo:registry id="hzRegistry" address="10.20.153.10:9090" />
<dubbo:registry id="qdRegistry" address="10.20.141.150:9090?subscribe=false" />

不一樣服務在性能上適用不一樣協議進行傳輸，好比大數據用短鏈接協議，小數據大併發用長鏈接協議。

   <dubbo:application name="world"  />
   <dubbo:registry id="registry" address="10.20.141.150:9090" username="admin" password="hello1234" />

   <!-- 多協議配置 -->
   <dubbo:protocol name="dubbo" port="20880" />
   <dubbo:protocol name="rmi" port="1099" />

   <!-- 使用dubbo協議暴露服務 -->
   <dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" protocol="dubbo" />
   <!-- 使用rmi協議暴露服務 -->
   <dubbo:service interface="com.alibaba.hello.api.DemoService" version="1.0.0" ref="demoService" protocol="rmi" />
   <!-- 使用多個協議暴露服務 -->
   <dubbo:service id="helloService" interface="com.alibaba.hello.api.HelloService" version="1.0.0" protocol="dubbo,hessian" />

多註冊中心

中文站有些服務來不及在青島部署，只在杭州部署，而青島的其它應用須要引用此服務，就能夠將服務同時註冊到兩個註冊中心。

 <dubbo:application name="world"  />

    <!-- 多註冊中心配置 -->
    <dubbo:registry id="hangzhouRegistry" address="10.20.141.150:9090" />
    <dubbo:registry id="qingdaoRegistry" address="10.20.141.151:9010" default="false" />

    <!-- 向多個註冊中心註冊 -->
    <dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" registry="hangzhouRegistry,qingdaoRegistry" />

CRM有些服務是專門爲國際站設計的，有些服務是專門爲中文站設計的。
<dubbo:application name="world"  />

    <!-- 多註冊中心配置 -->
    <dubbo:registry id="chinaRegistry" address="10.20.141.150:9090" />
    <dubbo:registry id="intlRegistry" address="10.20.154.177:9010" default="false" />

    <!-- 向中文站註冊中心註冊 -->
    <dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" registry="chinaRegistry" />

    <!-- 向國際站註冊中心註冊 -->
    <dubbo:service interface="com.alibaba.hello.api.DemoService" version="1.0.0" ref="demoService" registry="intlRegistry" />

當一個接口有多種實現時，能夠用group區分。

<dubbo:service group="feedback" interface="com.xxx.IndexService" />
<dubbo:service group="member" interface="com.xxx.IndexService" />
<dubbo:reference id="feedbackIndexService" group="feedback" interface="com.xxx.IndexService" />
<dubbo:reference id="memberIndexService" group="member" interface="com.xxx.IndexService" />
任意組：(2.2.0以上版本支持，老是隻調一個可用組的實現)
<dubbo:reference id="barService" interface="com.foo.BarService" group="*" />

當一個接口實現，出現不兼容升級時，能夠用版本號過渡，版本號不一樣的服務相互間不引用。
在低壓力時間段，先升級一半提供者爲新版本
再將全部消費者升級爲新版本
而後將剩下的一半提供者升級爲新版本

<dubbo:service interface="com.foo.BarService" version="1.0.0" />
<dubbo:service interface="com.foo.BarService" version="2.0.0" />
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />

不區分版本：(2.2.0以上版本支持)
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

按組合並返回結果，好比菜單服務，接口同樣，但有多種實現，用group區分，如今消費方需從每種group中調用一次返回結果，合併結果返回，這樣就能夠實現聚合菜單項。比較雞肋，小點的項目應該都用不到
配置如：(搜索全部分組)
<dubbo:reference interface="com.xxx.MenuService" group="*" merger="true" />
(合併指定分組)
<dubbo:reference interface="com.xxx.MenuService" group="aaa,bbb" merger="true" />

(指定方法合併結果，其它未指定的方法，將只調用一個Group)
<dubbo:reference interface="com.xxx.MenuService" group="*">
    <dubbo:method name="getMenuItems" merger="true" />
</dubbo:service>

(某個方法不合並結果，其它都合併結果)
<dubbo:reference interface="com.xxx.MenuService" group="*" merger="true">
<dubbo:method name="getMenuItems" merger="false" />
</dubbo:service>

(指定合併策略，缺省根據返回值類型自動匹配，若是同一類型有兩個合併器時，需指定合併器的名稱)
<dubbo:reference interface="com.xxx.MenuService" group="*">
    <dubbo:method name="getMenuItems" merger="mymerge" />
</dubbo:service>

(指定合併方法，將調用返回結果的指定方法進行合併，合併方法的參數類型必須是返回結果類型自己)
<dubbo:reference interface="com.xxx.MenuService" group="*">
    <dubbo:method name="getMenuItems" merger=".addAll" />
</dubbo:service>

dubbo 參數驗證   

字段驗證
    @NotNull // 不容許爲空
    @Size(min = 1, max = 20) // 長度或大小範圍
    private String name;

    @NotNull(groups = ValidationService.Save.class) // 保存時不容許爲空，更新時容許爲空 ，表示不更新該字段
    @Pattern(regexp = "^\\s*\\w+(?:\\.{0,1}[\\w-]+)*@[a-zA-Z0-9]+(?:[-.][a-zA-Z0-9]+)*\\.[a-zA-Z]+\\s*$")
    private String email;

    @Min(18) // 最小值
    @Max(100) // 最大值
    private int age;

    @Past // 必須爲一個過去的時間
    private Date loginDate;

    @Future // 必須爲一個將來的時間
    private Date expiryDate;

    分組驗證示例：
     //下面這個驗證應該是用於做用在參數類屬性上的時候，當被調用的方法屬於ValidationService接口的時候校驗不爲空
     // 缺省可按服務接口區分驗證場景，如：@NotNull(groups = ValidationService.class)
    public interface ValidationService { 

        //下面這個驗證應該是用於做用在參數類屬性上的時候，當被調用的方法屬於ValidationService接口的save方法的時候校驗不爲空
        @interface Save{} // 與方法同名接口，首字母大寫，用於區分驗證場景，如：@NotNull(groups = ValidationService.Save.class)，可選
        void save(ValidationParameter parameter);

        @interface Update{} // 與方法同名接口，首字母大寫，用於區分驗證場景，如：@NotNull(groups = ValidationService.Update.class)，可選
        void update(ValidationParameter parameter);

        void delete(@Min(1) long id, @NotNull @Size(min = 2, max = 16) @Pattern(regexp = "^[a-zA-Z]+$") String operator);

    }

    關聯驗證示例：
    public interface ValidationService {

         //下面這個驗證應該是指該方法的調用參數必須知足Update組合Save組驗證規則
        @GroupSequence(Update.class) // 同時驗證Update組規則
        @interface Save{}
        void save(ValidationParameter parameter);

        @interface Update{} 
        void update(ValidationParameter parameter);

    }

    在客戶端驗證參數：
    <dubbo:reference id="validationService" interface="com.alibaba.dubbo.examples.validation.api.ValidationService" validation="true" />

    在服務器端驗證參數：
    <dubbo:service interface="com.alibaba.dubbo.examples.validation.api.ValidationService" ref="validationService" validation="true" />

dubbo的令牌驗證

防止消費者繞過註冊中心訪問提供者
在註冊中心控制權限，以決定要不要下發令牌給消費者
註冊中心可靈活改變受權方式，而不需修改或升級提供者
能夠全局設置開啓令牌驗證：

<!--隨機token令牌，使用UUID生成-->
<dubbo:provider interface="com.foo.BarService" token="true" />
<!--固定token令牌，至關於密碼-->
<dubbo:provider interface="com.foo.BarService" token="123456" />
也可在服務級別設置：

<!--隨機token令牌，使用UUID生成-->
<dubbo:service interface="com.foo.BarService" token="true" />
<!--固定token令牌，至關於密碼-->
<dubbo:service interface="com.foo.BarService" token="123456" />

dubbo經常使用配置：
<dubbo:service> version version string  可選  0.0.0   服務發現    服務版本，建議使用兩位數字版本，如：1.0，一般在接口不兼容時版本號才須要升級

<dubbo:service> group   group   string  可選      服務發現    服務分組，當一個接口有多個實現，能夠用分組區分

//主要由於dubbo服務在spring2.X初始化全部類以前被暴露出去，致使被請求鎖死了singletonObjects、beanDefinitionMap
<dubbo:service> delay   delay   int  可選 0   性能調優    延遲註冊服務時間(毫秒) ，設爲-1時，表示延遲到Spring容器初始化完成時暴露服務

<dubbo:service> timeout timeout int 可選  1000    性能調優    遠程服務調用超時時間(毫秒)

<dubbo:service> retries retries int 可選  2   性能調優    遠程服務調用重試次數，不包括第一次調用，不須要重試請設爲0

//這裏應該還有個一致性Hash的方式，文檔介紹有，可是配置文檔沒有。
<dubbo:service> loadbalance loadbalance string  可選  random  性能調優    負載均衡策略，可選值：random,roundrobin,leastactive，分別表示：隨機，輪循，最少活躍調用

<dubbo:service> token   token   string/boolean  可選  false   服務治理    令牌驗證，爲空表示不開啓，若是爲true，表示隨機生成動態令牌，不然使用靜態令牌，令牌的做用是防止消費者繞過註冊中心直接訪問，保證註冊中心的受權功能有效，若是使用點對點調用，需關閉令牌功能

<dubbo:service> registry        string  可選  缺省向全部registry註冊 配置關聯    向指定註冊中心註冊，在多個註冊中心時使用，值爲<dubbo:registry>的id屬性，多個註冊中心ID用逗號分隔，若是不想將該服務註冊到任何registry，可將值設爲N/A

<dubbo:service> provider        string  可選  缺使用第一個provider配置    配置關聯    指定provider，值爲<dubbo:provider>的id屬性

<dubbo:service> dynamic dynamic boolean 可選  true    服務治理    服務是否動態註冊，若是設爲false，註冊後將顯示後disable狀態，需人工啓用，而且服務提供者中止時，也不會自動取消冊，需人工禁用。

<dubbo:service> cluster cluster string  可選  failover    性能調優    集羣方式，可選：failover/failfast/failsafe/failback/forking

<dubbo:service> register    register    boolean 可選  true    服務治理    該協議的服務是否註冊到註冊中心

<dubbo:service> owner   owner   string  可選      服務治理    服務負責人，用於服務治理，請填寫負責人公司郵箱前綴

<dubbo:reference>   version version string  可選      服務發現    服務版本，與服務提供者的版本一致

<dubbo:reference>   group   group   string  可選      服務發現    服務分組，當一個接口有多個實現，能夠用分組區分，必需和服務提供方一致

<dubbo:reference>   timeout timeout long    可選  缺省使用<dubbo:consumer>的timeout    性能調優    服務方法調用超時時間(毫秒)

<dubbo:reference>   retries retries int 可選  缺省使用<dubbo:consumer>的retries    性能調優    遠程服務調用重試次數，不包括第一次調用，不須要重試請設爲0

<dubbo:reference>   loadbalance loadbalance string  可選  缺省使用<dubbo:consumer>的loadbalance    性能調優    負載均衡策略，可選值：random,roundrobin,leastactive，分別表示：隨機，輪循，最少活躍調用

<dubbo:reference>   check   check   boolean 可選  缺省使用<dubbo:consumer>的check  服務治理    啓動時檢查提供者是否存在，true報錯，false忽略

<dubbo:reference>   url <url>   string  可選      服務治理    點對點直連服務提供者地址，將繞過註冊中心

<dubbo:reference>   cache   cache   string/boolean  可選      服務治理    以調用參數爲key，緩存返回結果，可選：lru, threadlocal, jcache等   

<dubbo:reference>   validation  validation  boolean 可選      服務治理    是否啓用JSR303標準註解驗證，若是啓用，將對方法參數上的註解進行校驗

<dubbo:reference>   registry        string  可選  缺省將從全部註冊中心獲服務列表後合併結果    配置關聯    從指定註冊中心註冊獲取服務列表，在多個註冊中心時使用，值爲<dubbo:registry>的id屬性，多個註冊中心ID用逗號分隔

<dubbo:reference>   owner   owner   string  可選      服務治理    調用服務負責人，用於服務治理，請填寫負責人公司郵箱前綴

<dubbo:protocol>    id      string  可選  dubbo   配置關聯    協議BeanId，能夠在<dubbo:service protocol="">中引用此ID，若是ID不填，缺省和name屬性值同樣，重複則在name後加序號

<dubbo:protocol>    name    <protocol>  string  必填  dubbo   性能調優    協議名稱

<dubbo:protocol>    port    <port>  int 可選  dubbo協議缺省端口爲20880，rmi協議缺省端口爲1099，http和hessian協議缺省端口爲80 
若是配置爲-1 或者 沒有配置port，則會分配一個沒有被佔用的端口。Dubbo 2.4.0+，分配的端口在協議缺省端口的基礎上增加，確保端口段可控。 服務發現    服務端口

<dubbo:protocol>    threadpool  threadpool  string  可選  fixed   性能調優    線程池類型，可選：fixed/cached

<dubbo:protocol>    heartbeat   heartbeat   int 可選  0   性能調優    心跳間隔，對於長鏈接，當物理層斷開時，好比拔網線，TCP的FIN消息來不及發送，對方收不到斷開事件，此時須要心跳來幫助檢查鏈接是否已斷開

<dubbo:protocol>    register    register    boolean 可選  true    服務治理    該協議的服務是否註冊到註冊中心

<dubbo:registry>    id      string  可選      配置關聯    註冊中心引用BeanId，能夠在<dubbo:service registry="">或<dubbo:reference registry="">中引用此ID

<dubbo:registry>    address <host:port> string  必填      服務發現    註冊中心服務器地址，若是地址沒有端口缺省爲9090，同一集羣內的多個地址用逗號分隔，如：ip:port,ip:port，不一樣集羣的註冊中心，請配置多個<dubbo:registry>標籤

<dubbo:registry>    protocol    <protocol>  string  可選  dubbo   服務發現    注同中心地址協議，支持dubbo, http, local三種協議，分別表示，dubbo地址，http地址，本地註冊中心

<dubbo:registry>    port    <port>  int 可選  9090    服務發現    註冊中心缺省端口，當address沒有帶端口時使用此端口作爲缺省值

<dubbo:registry>    username    <username>  string  可選      服務治理    登陸註冊中心用戶名，若是註冊中心不須要驗證可不填

<dubbo:registry>    password    <password>  string  可選      服務治理    登陸註冊中心密碼，若是註冊中心不須要驗證可不填

<dubbo:registry>    timeout registry.timeout    int 可選  5000    性能調優    註冊中心請求超時時間(毫秒)

<dubbo:registry>    check   check   boolean 可選  true    服務治理    註冊中心不存在時，是否報錯

<dubbo:registry>    register    register    boolean 可選  true    服務治理    是否向此註冊中心註冊服務，若是設爲false，將只訂閱，不註冊

<dubbo:registry>    subscribe   subscribe   boolean 可選  true    服務治理    是否向此註冊中心訂閱服務，若是設爲false，將只註冊，不訂閱

<dubbo:application> name    application string  必填      服務治理    當前應用名稱，用於註冊中心計算應用間依賴關係，注意：消費者和提供者應用名不要同樣，此參數不是匹配條件，你當前項目叫什麼名字就填什麼，和提供者消費者角色無關，好比：kylin應用調用了morgan應用的服務，則kylin項目配成kylin，morgan項目配成morgan，可能kylin也提供其它服務給別人使用，但kylin項目永遠配成kylin，這樣註冊中心將顯示kylin依賴於morgan

標籤  屬性  對應URL參數 類型  是否必填    缺省值 做用  描述  兼容性
<dubbo:application> name    application string  必填      服務治理    當前應用名稱，用於註冊中心計算應用間依賴關係，注意：消費者和提供者應用名不要同樣，此參數不是匹配條件，你當前項目叫什麼名字就填什麼，和提供者消費者角色無關，好比：kylin應用調用了morgan應用的服務，則kylin項目配成kylin，morgan項目配成morgan，可能kylin也提供其它服務給別人使用，但kylin項目永遠配成kylin，這樣註冊中心將顯示kylin依賴於morgan   1.0.16以上版本

<dubbo:application> version application.version string  可選      服務治理    當前應用的版本

這兩個標籤感受沒什麼特殊的，應該是能夠配一些共通的配置在service和reference上使用而已。

註冊中心上通常採用zookeeper做爲註冊中心，阿里內部並無採用Zookeeper作爲註冊中心，而是使用本身實現的基於數據庫的註冊中心，即：Zookeeper註冊中心並無在阿里內部長時間運行的可靠性保障，此Zookeeper橋接實現只爲開源版本提供，其可靠性依賴於Zookeeper自己的可靠性。

dubbo所有的配置信息都看了一遍，受益良多，發現了不少平時沒注意的地方。你們得多看看官方文檔。