Dubbo高可用和負載均衡
1、高可用
現象：zookeeper註冊中心宕機，還可以消費dubbo暴露的服務。
原因：
- 監控中心宕掉不影響使用，只是丟失部分取樣資料
- 資料庫宕掉後，註冊中心仍能通過快取提供服務列表查詢，但不能註冊新服務
- 註冊中心對等叢集，任意一臺宕掉後，將自動切換到另一臺
- 註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地快取通訊
- 服務提供者無狀態，任意一臺宕掉後，不影響使用
- 服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復
高可用：通過設計，減少系統不能提供服務的時間；
Dubbo直連：消費端也可以不通過註冊中心直接調服務端介面，在消費端指定url:
2、負載均衡
在叢集負載均衡時，Dubbo 提供了多種均衡策略，預設為 random 隨機呼叫。
- 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" />
啟動3個服務提供者。
啟動消費者。發現，3號提供者列印了。關閉消費者，再啟動消費者，發現，訪問的提供者是隨機的。
修改一下負載均衡的策略：
經過測試，發現，確實是輪詢的訪問3個服務提供者。
可以在控制檯控制權重：
