dubbo工做原理，集羣容錯，負載均衡

dubbo主要核心部件

Remoting：網絡通訊框架，實現了sync-over-async和request-response消息機制。

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

Registry：服務目錄框架用於服務的註冊和服務事件發佈和訂閱。（相似第一篇文章中的點菜寶）

dubbo架構

Provider： 暴露服務的提供方。

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

Registry： 服務註冊中心和發現中心。

Monitor： 統計服務和調用次數，調用時間監控中心。（dubbo的控制檯頁面中能夠顯示）

Container：服務運行的容器。

 調用關係：

       0、服務器負責啓動，加載，運行提供者（例如在tomcat容器中，啓動dubbo服務端）。

        一、提供者在啓動時，向註冊中心註冊本身提供的服務。

        二、消費者啓動時，向註冊中心訂閱本身所需的服務。

        三、註冊中心返回提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。

        四、消費者，從遠程接口列表中，調用遠程接口，dubbo會基於負載均衡算法，選一臺提供者進行調用，若是調用失敗則選擇另外一臺。

        五、消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。（能夠在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自己的高級特性.正如咱們在說自定義擴展的時候同樣,這兩個特徵一樣也能夠進行自定義擴展,用戶能夠根據本身實際的需求來擴展他們從而知足項目的實際需求.

參考出處： http://blog.csdn.net/lovesummerforever/article/details/48180957

http://blog.csdn.net/jnqqls/article/details/46702103