- 註冊中心全部宕掉後,服務提供者和服務消費者仍能通過本地緩存通訊
- 負載均衡機制
- 服務降級
- 集羣容錯
4.1 zk宕機,直連通信
現象:zookeeper註冊中心宕機,還可以消費dubbo暴露的服務。
<dubbo:reference id="demoService" check="false" interface="com.alibaba.dubbo.demo.DemoService" url="127.0.0.1:20882"/>
健壯性
- 監控中心宕掉不影響使用,只是丟失部分採樣數據
- 數據庫宕掉後,註冊中心仍能通過緩存提供服務列表查詢,但不能註冊新服務
- 註冊中心對等集羣,任意一臺宕掉後,將自動切換到另一臺
- 註冊中心全部宕掉後,服務提供者和服務消費者仍能通過本地緩存通訊
- 服務提供者無狀態,任意一臺宕掉後,不影響使用
- 服務提供者全部宕掉後,服務消費者應用將無法使用,並無限次重連等待服務提供者恢復
4.2 負載均衡
在集羣負載均衡時,Dubbo 提供了多種均衡策略,缺省爲 random 隨機調用。
4.2.1 Random LoadBalance
- 隨機,按權重設置隨機概率。
- 在一個截面上碰撞的概率高,但調用量越大分佈越均勻,而且按概率使用權重後也比較均勻,有利於動態調整提供者權重。
4.2.2 RoundRobin LoadBalance
- 輪循,按公約後的權重設置輪循比率。
- 存在慢的提供者累積請求的問題,比如:第二臺機器很慢,但沒掛,當請求調到第二臺時就卡在那,久而久之,所有請求都卡在調到第二臺上。
4.2.3 LeastActive LoadBalance
- 最少活躍調用數,相同活躍數的隨機,活躍數指調用前後計數差。—— 上一次耗時最少的請求優先調用
- 使慢的提供者收到更少請求,因爲越慢的提供者的調用前後計數差會越大。
4.2.3 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” />
4.3 服務降級
當服務器壓力劇增時,根據實際業務情況及流量,對一些服務和頁面有策略的不處理或者換種簡單的方式處理,從而釋放服務器資源以保證核心交易正常運作或高效運作。
4.3.1 屏蔽
直接返回Null,不發起遠程調用。用來屏蔽不重要服務不可用時對調用方的影響。
4.3.2 容錯
調用失敗後再返回null值,不拋出異常。用來容忍不重要服務不穩定時對調用方的影響。
4.4 集羣容錯
在集羣調用失敗時,Dubbo 提供了多種容錯方案,缺省爲 failover 重試。
4.4.1 Failover Cluster
失敗自動切換,當出現失敗,重試其它服務器。通常用於讀操作,但重試會帶來更長延遲。可通過retries=“2” 來設置重試次數(不含第一次)。
最後一次重試出錯纔會拋出異常。
重試次數配置如下:
<dubbo:service retries="2" />
或
<dubbo:reference retries="2" />
或
<dubbo:reference>
<dubbo:method name="findFoo" retries="2" />
</dubbo:reference>
4.4.2 Failfast Cluster
快速失敗,只發起一次調用,失敗立即報錯。通常用於非冪等性的寫操作,比如新增記錄。
4.4.3 Failsafe Cluster
失敗安全,出現異常時,直接忽略。通常用於寫入審計日誌等操作。
4.4.4 Failback Cluster
失敗自動恢復,後臺記錄失敗請求,定時重發。通常用於消息通知操作。
4.4.5 Forking Cluster
並行調用多個服務器,只要一個成功即返回。通常用於實時性要求較高的讀操作,但需要浪費更多服務資源。可通過forks=“2” 來設置最大並行數。
4.4.6 Broadcast Cluster
廣播調用所有提供者,逐個調用,任意一臺報錯則報錯。通常用於通知所有提供者更新緩存或日誌等本地資源信息。
Hystrix定製化容錯邏輯。