dubbo集群容錯解決方案


 

dubbo主要核心部件

Remoting:網絡通信框架,實現了sync-over-async和request-response消息機制。

RPC:一個遠程過程調用的抽象,支持負載均衡、容災和集群功能。

Registry:服務目錄框架用於服務的注冊和服務事件發布和訂閱。(類似第一篇文章中的點菜寶)

dubbo架構

 

 

 

Provider: 暴露服務的提供方。

Consumer:調用遠程服務的服務消費方。

Registry: 服務注冊中心和發現中心。

Monitor: 統計服務和調用次數,調用時間監控中心。(dubbo的控制台頁面中可以顯示)

Container:服務運行的容器。

 調用關系:

       0、服務器負責啟動,加載,運行提供者(例如在tomcat容器中,啟動dubbo服務端)。

        1、提供者在啟動時,向注冊中心注冊自己提供的服務。

        2、消費者啟動時,向注冊中心訂閱自己所需的服務。

        3、注冊中心返回提供者地址列表給消費者,如果有變更,注冊中心將基於長連接推送變更數據給消費者。

        4、消費者,從遠程接口列表中,調用遠程接口,dubbo會基於負載均衡算法,選一台提供者進行調用,如果調用失敗則選擇另一台。

        5、消費者和提供者,在內存中累計調用次數和調用時間,定時每分鍾發送一次統計數據到監控中心。(可以在dubbo的可視化界面看到)

dubbo的容錯方案

當我們的系統中用到Dubbo的集群環境,因為各種原因在集群調用失敗時,Dubbo提供了多種容錯方案,缺省為failover重試。

       Dubbo的集群容錯在這里想說說他是因為我們實際的項目中出現了此類的問題,因為依賴的第三方項目出現異常,導致dubbo調用超時,此時使用的是默認的集群容錯方式,而配置的reties='3',這樣前段系統連續掉用了三次服務,結果可想而知.

     先說一下各節點關系:

       這里的Invoker是Provider的一個可調用Service的抽象,Invoker封裝了Provider地址及Service接口信息。

        Directory代表多個Invoker,可以把它看成List<Invoker>,但與List不同的是,它的值可能是動態變化的,比如注冊中心推送變更。

         Cluster將Directory中的多個Invoker偽裝成一個Invoker,對上層透明,偽裝過程包含了容錯邏輯,調用失敗后,重試另一個。

         Router負責從多個Invoker中按路由規則選出子集,比如讀寫分離,應用隔離等。

         LoadBalance負責從多個Invoker中選出具體的一個用於本次調用,選的過程包含了負載均衡算法,調用失敗后,需要重選。

  集群容錯模式:

  Failover Cluster

失敗自動切換,當出現失敗,重試其它服務器。(缺省)

通常用於讀操作,但重試會帶來更長延遲。

可通過retries="2"來設置重試次數(不含第一次)。正是文章剛開始說的那種情況.

  Failfast Cluster

快速失敗,只發起一次調用,失敗立即報錯。

通常用於非冪等性的寫操作,比如新增記錄。

  Failsafe Cluster

失敗安全,出現異常時,直接忽略。

通常用於寫入審計日志等操作。

  Failback Cluster

失敗自動恢復,后台記錄失敗請求,定時重發。

通常用於消息通知操作。

  Forking Cluster

並行調用多個服務器,只要一個成功即返回。

通常用於實時性要求較高的讀操作,但需要浪費更多服務資源。

可通過forks="2"來設置最大並行數。

  Broadcast Cluster

廣播調用所有提供者,逐個調用,任意一台報錯則報錯。(2.1.0開始支持)

通常用於通知所有提供者更新緩存或日志等本地資源信息。

重試次數配置如:(failover集群模式生效)

<dubbo:serviceretries="2"/>

或:<dubbo:referenceretries="2"/>

或:<dubbo:reference>

             <dubbo:methodname="findFoo"retries="2"/>

     </dubbo:reference>

集群模式配置如:

<dubbo:servicecluster="failsafe"/>

或:<dubbo:referencecluster="failsafe"/>

dubbo負載均衡策略:

        在集群負載均衡時,Dubbo提供了多種均衡策略,缺省為random隨機調用。

    RandomLoadBalance

隨機,按權重設置隨機概率。

在一個截面上碰撞的概率高,但調用量越大分布越均勻,而且按概率使用權重后也比較均勻,有利於動態調整提供者權重。

    RoundRobin LoadBalance

輪循,按公約后的權重設置輪循比率。

存在慢的提供者累積請求問題,比如:第二台機器很慢,但沒掛,當請求調到第二台時就卡在那,久而久之,所有請求都卡在調到第二台上。

    LeastActive LoadBalance

最少活躍調用數,相同活躍數的隨機,活躍數指調用前后計數差。

使慢的提供者收到更少請求,因為越慢的提供者的調用前后計數差會越大。

   ConsistentHashLoadBalance

一致性Hash,相同參數的請求總是發到同一提供者。

當某一台提供者掛時,原本發往該提供者的請求,基於虛擬節點,平攤到其它提供者,不會引起劇烈變動。

 

       Dubbo的集群容錯和負載均衡同樣也是Dubbo本身的高級特性.正如我們在說自定義擴展的時候一樣,這兩個特征同樣也可以進行自定義擴展,用戶可以根據自己實際的需求來擴展他們從而滿足項目的實際需求.

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM