這就是典型的點對點的服務調用。當然我們為了高可用，可以在consumer.xml中配置多個服務提供者，並配置響應的負載均衡策略

配置多個服務調用者在comsumer.xml的<dubbo:reference>標籤的url屬性中加入多個地址，中間用分號隔開即可

配置負載均衡策略在comsumer.xml的<dubbo:reference>標籤中增加loadbalance屬性即可，值可以為如下四種類型

1. RoundRobin LoadBalance，隨機，按權重設置隨機概率。
2. RoundRobin LoadBalance，輪詢，按公約後的權重設置輪詢比率。
3. LeastActive LoadBalance，最少活躍調用數，相同活躍數的隨機，活躍數指調用前後計數差。
4. ConsistentHash LoadBalance，一致性 Hash，相同參數的請求總是發到同一提供者。

現在整體架構是如下圖（假設服務消費者為訂單服務，服務提供者為用戶服務）：

這樣會有什麼問題呢？

1. 當服務提供者增加節點時，需要修改配置文件
2. 當其中一個服務提供者宕機時，服務消費者不能及時感知到，還會往宕機的服務發送請求

這個時候就得引入註冊中心了

註冊中心

Dubbo目前支持4種註冊中心,（multicast zookeeper redis simple） 推薦使用Zookeeper註冊中心，本文就講一下用zookeeper實現服務註冊和發現（敲黑板，又一種zookeeper的用處），大致流程如下

現在我們來看Dubbo官網對Dubbo的介紹圖，有沒有和我們上面畫的很相似

節點角色說明

調用關係說明

1. 服務容器負責啟動（上面例子為Spring容器），載入，運行服務提供者。
2. 服務提供者在啟動時，向註冊中心註冊自己提供的服務。
3. 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
4. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
5. 服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。
6. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

要使用註冊中心，只需要將provider.xml和consumer.xml更改為如下

如果zookeeper是一個集群，則多個地址之間用逗號分隔即可

<dubbo:registry protocol="zookeeper" address="192.168.11.129:2181,192.168.11.137:2181,192.168.11.138:2181"/>

把consumer.xml中配置的直連的方式去掉

註冊信息在zookeeper中如何保存？

啟動上面服務後，我們觀察zookeeper的根節點多了一個dubbo節點及其他，圖示如下

最後一個節點中192.168.1.104是小編的內網地址，你可以任務和上面配置的localhost一個效果，大家可以想一下我為什麼把最後一個節點標成綠色的。沒錯，最後一個節點是臨時節點，而其他節點是持久節點，這樣，當服務宕機時，這個節點就會自動消失，不再提供服務，服務消費者也不會再請求。如果部署多個DemoService，則providers下面會有好幾個節點，一個節點保存一個DemoService的服務地址

其實一個zookeeper集群能被多個應用公用，如小編Storm集群和Dubbo配置的就是一個zookeeper集群，為什麼呢？因為不同的框架會在zookeeper上建不同的節點，互不影響。如dubbo會創建一個/dubbo節點，storm會創建一個/storm節點，如圖

讀者福利

小編這邊給大家準備了一些Java學習資料，希望能夠幫助到大家，同時也省的大家再去網上找資料

領取方式

Java架構築基?

zhuanlan.zhihu.com

• 關注知乎專欄【Java架構築基】，專欄頂部有免費的領取方式
• ...
• 或者私信我【架構】，免費領取！
• ...
• 最後祝大家學習愉快！！！

推薦閱讀：