- 注冊中心全部宕掉後,服務提供者和服務消費者仍能通過本地緩存通訊
- 負載均衡機制
- 服務降級
- 叢集容錯
4.1 zk當機,直連通信
現象:zookeeper注冊中心當機,還可以消費dubbo暴露的服務。
<dubbo:reference id="demoService" check="false" intertoken string">"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定制化容錯邏輯。