其實dubbo的應用多結點集群配置相當簡單，只需要將應用中暴露的介面進行分組即可。但是dubbo中有以下約定：
只有group，inte***ce，version完全一致，才認為是同乙個服務。
dubbo應用集群配置：
1、zk的集群請參照我的另一篇博文：
2、dubbo應用集群：
服務提供方配置如下：
registry address為：zookeeper:
host="$"
port="$"
threads="$"/>
服務消費方配置如下：
消費方的註冊位址與服務一樣，服務一定要指定group。
通過以上配置，即完成多應用集群，將各應用起來即可進行測試驗證。
dubbo集群容錯模式：
failover cluster
失敗自動切換，當出現失敗，重試其它伺服器。(預設)
通常用於讀操作，但重試會帶來更長延遲。
可通過retries="2"來設定重試次數(不含第一次)。
failfast cluster
快速失敗，只發起一次呼叫，失敗立即報錯。
通常用於非冪等性的寫操作，比如新增記錄。
failsafe cluster
失敗安全，出現異常時，直接忽略。
通常用於寫入審計日誌等操作。
failback cluster
失敗自動恢復，後台記錄失敗請求，定時重發。
通常用於訊息通知操作。
forking cluster
並行呼叫多個伺服器，只要乙個成功即返回。
通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。
可通過forks="2"來設定最大並行數。
broadcast cluster
廣播呼叫所有提供者，逐個呼叫，任意一台報錯則報錯。(2.1.0開始支援)
通常用於通知所有提供者更新快取或日誌等本地資源資訊。
此外，dubbo還支援自行擴充套件集群容錯策略。
dubbo集群負載均衡策略：
配置如：
random loadbalance（預設策略）
隨機，按權重設定隨機概率。
在乙個截面上碰撞的概率高，但呼叫量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。
roundrobin loadbalance
輪循，按公約後的權重設定輪循比率。
存在慢的提供者累積請求問題，比如：第二台機器很慢，但沒掛，當請求調到第二台時就卡在那，久而久之，所有請求都卡在調到第二台上。
leastactive loadbalance
最少活躍呼叫數，相同活躍數的隨機，活躍數指呼叫前後計數差。
使慢的提供者收到更少請求，因為越慢的提供者的呼叫前後計數差會越大。
consistenthash loadbalance
一致性hash，相同引數的請求總是發到同一提供者。
當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。
演算法參見：
預設只對第乙個引數hash，如果要修改，請配置
預設用160份虛擬節點，如果要修改，請配置
此外，dubbo支援自行擴充套件負載均衡策略。
dubbo是乙個非常優秀的分布式服務框架，使用也非常簡單，官網上文件資料也相當全面。若有需要深入研究其高階特性可自行去查閱：
Dubbo 5 服務分組及多版本
服務分組 當乙個介面有多種實現時，可以用 group 區分。服務端配置 消費端配置 注 在2.2.0 以上，group屬性可以配置為 表示為任意組，總是只調乙個可用組的實現。如果服務分組了，則對應的消費者xml配置中group欄位必須存在且值不能為空。多版本當乙個介面實現，出現不相容公升級時，可以用...
dubbo多註冊中心
dubbo 支援同一服務向多註冊中心同時註冊，或者不同服務分別註冊到不同的註冊中心上去，甚至可以同時引用註冊在不同註冊中心上的同名服務。另外，註冊中心是支援自定義擴充套件的。比如 中文站有些服務來不及在成都部署，只在杭州部署，而成都的其它應用需要引用此服務，就可以將服務同時註冊到兩個註冊中心。比如 ...
Dubbo多註冊中心
1 建立工程 直接複製05 provider group工程，並命名為08 provider registers 2 修改配置檔案 1 建立工程 直接複製05 consumer group工程，並命名為08 consumer registers 2 修改配置檔案 對於消費者工程，用到哪個註冊中心了，...