Dubbo是Alibaba開源的分佈式服務框架，咱們能夠很是容易地經過Dubbo來構建分佈式服務，並根據本身實際業務應用場景來選擇合適的集羣容錯模式，這個對於不少應用都是迫切但願的，只須要經過簡單的配置就可以實現分佈式服務調用，也就是說服務提供方（Provider）發佈的服務能夠自然就是集羣服務，好比，在實時性要求很高的應用場景下，可能但願來自消費方（Consumer）的調用響應時間最短，只須要選擇Dubbo的Forking Cluster模式配置，就能夠對一個調用請求並行發送到多臺對等的提供方（Provider）服務所在的節點上，只選擇最快一個返回響應的，而後將調用結果返回給服務消費方（Consumer），顯然這種方式是以冗餘服務爲基礎的，須要消耗更多的資源，可是可以知足高實時應用的需求。算法
1、Dubbo服務集羣容錯
假設咱們使用的是單機模式的Dubbo服務，若是在服務提供方（Provider）發佈服務之後，服務消費方（Consumer）發出一次調用請求，剛好此次因爲網絡問題調用失敗，那麼咱們能夠配置服務消費方重試策略，可能消費方第二次重試調用是成功的（重試策略只須要配置便可，重試過程是透明的）；可是，若是服務提供方發佈服務所在的節點發生故障，那麼消費方再怎麼重試調用都是失敗的，因此咱們須要採用集羣容錯模式，這樣若是單個服務節點因故障沒法提供服務，還能夠根據配置的集羣容錯模式，調用其餘可用的服務節點，這就提升了服務的可用性。api
簡單地說目前Dubbo支持的集羣容錯模式，每種模式適應特定的應用場景，能夠根據實際須要進行選擇。Dubbo內置支持以下6種集羣模式：緩存
一、Failover Cluster模式安全
配置值爲failover。這種模式是Dubbo集羣容錯默認的模式選擇，調用失敗時，會自動切換，從新嘗試調用其餘節點上可用的服務。服務器
對於一些冪等性操做可使用該模式，如讀操做，由於每次調用的反作用是相同的，因此能夠選擇自動切換並重試調用，對調用者徹底透明。網絡
能夠看到，若是重試調用必然會帶來響應端的延遲，若是出現大量的重試調用，可能說明咱們的服務提供方發佈的服務有問題，如網絡延遲嚴重、硬件設備須要升級、程序算法很是耗時，等等，這就須要仔細檢測排查了。負載均衡
例如，能夠這樣顯式指定Failover模式，或者不配置則默認開啓Failover模式，配置示例以下：框架
<dubbo:service interface="org.shirdrn.dubbo.api.ChatRoomOnlineUserCounterService"
version="1.0.0" cluster="failover" retries="2" timeout="100"
ref="chatRoomOnlineUserCounterService" protocol="dubbo" >
<dubbo:method name="queryRoomUserCount" timeout="80" retries="2" />
</dubbo:service>
上述配置使用Failover Cluster模式，若是調用失敗一次，能夠再次重試2次調用，服務級別調用超時時間爲100ms，調用方法queryRoomUserCount的超時時間爲80ms，容許重試2次，最壞狀況調用花費時間160ms。若是該服務接口org.shirdrn.dubbo.api.ChatRoomOnlineUserCounterService還有其餘的方法可供調用，則其餘方法沒有顯式配置則會繼承使用dubbo:service配置的屬性值。dom
二、Failfast Cluster模式分佈式
配置值爲failfast。這種模式稱爲快速失敗模式，調用只執行一次，失敗則當即報錯。
這種模式適用於非冪等性操做，每次調用的反作用是不一樣的，如寫操做，
好比交易系統咱們要下訂單，若是一次失敗就應該讓它失敗，一般由服務消費方控制是否從新發起下訂單操做請求（另外一個新的訂單）。
三、Failsafe Cluster模式
配置值爲failsafe。失敗安全模式，若是調用失敗， 則直接忽略失敗的調用，
而是要記錄下失敗的調用到日誌文件，以便後續審計。
四、Failback Cluster模式
配置值爲failback。失敗自動恢復，後臺記錄失敗請求，定時重發。
一般用於消息通知操做。
五、Forking Cluster模式
配置值爲forking。並行調用多個服務器，只要一個成功即返回。
一般用於實時性要求較高的讀操做，但須要浪費更多服務資源。
六、Broadcast Cluster模式
配置值爲broadcast。
廣播調用全部提供者，逐個調用，任意一臺報錯則報錯（2.1.0開始支持）。
一般用於通知全部提供者更新緩存或日誌等本地資源信息。
上面的6種模式均可以應用於生產環境，咱們能夠根據實際應用場景選擇合適的集羣容錯模式。
若是咱們以爲Dubbo內置提供的幾種集羣容錯模式都不能知足應用須要，
也能夠定製實現本身的集羣容錯模式，由於Dubbo框架給我提供的擴展的接口，只須要實現接口com.alibaba.dubbo.rpc.cluster.Cluster便可。
2、Dubbo服務負載均衡
Dubbo框架內置提供負載均衡的功能以及擴展接口，咱們能夠透明地擴展一個服務或服務集羣，根據須要很是容易地增長/移除節點，提升服務的可伸縮性。
Dubbo框架內置提供了4種負載均衡策略，以下所示：
一、Random LoadBalance：隨機策略，配置值爲random。能夠設置權重，有利於充分利用服務器的資源，高配的能夠設置權重大一些，低配的能夠稍微小一些
二、RoundRobin LoadBalance：輪詢策略，配置值爲roundrobin。
三、LeastActive LoadBalance：配置值爲leastactive。根據請求調用的次數計數，處理請求更慢的節點會受到更少的請求
四、ConsistentHash LoadBalance：一致性Hash策略，具體配置方法能夠參考Dubbo文檔。相同調用參數的請求會發送到同一個服務提供方節點上，若是某個節點發生故障沒法提供服務，則會基於一致性Hash算法映射到虛擬節點上（其餘服務提供方）
在實際使用中，只須要選擇合適的負載均衡策略值，配置便可，下面是上述四種負載均衡策略配置的示例：
<dubbo:service interface="org.shirdrn.dubbo.api.ChatRoomOnlineUserCounterService" version="1.0.0"
cluster="failover" retries="2" timeout="100" loadbalance="random"
ref="chatRoomOnlineUserCounterService" protocol="dubbo" >
<dubbo:method name="queryRoomUserCount" timeout="80" retries="2" loadbalance="leastactive" />
</dubbo:service>
上述配置，也體現了Dubbo配置的繼承性特色，也就是dubbo:service元素配置了loadbalance=」random」，則該元素的子元素dubbo:method若是沒有指定負載均衡策略，則默認爲loadbalance=」random」，不然若是dubbo:method指定了loadbalance=」leastactive」，則使用子元素配置的負載均衡策略覆蓋了父元素指定的策略（這裏調用queryRoomUserCount方法使用leastactive負載均衡策略）。