dubbo服務的集羣擴展、目錄服務、路由規則、負載均衡

1. Cluster-集羣擴展

當有多個服務提供方時，將多個服務提供方組織成一個集羣，並假裝成一個提供方。已知的實現以下，

1-1. FailoverCluster（默認的）

失敗轉移，當出現失敗，重試其它服務器，一般用於讀操做，但重試會帶來更長延遲。

1-2. AvailableCluster

獲取可用的調用。遍歷全部Invokers判斷Invoker.isAvalible,只要一個有爲true直接調用返回，無論成不成功。

1-3. BroadcastCluster

挨個調用集羣中全部的providers，一般用於通知全部的服務提供者更新某些資源，例如緩存、日誌。

1-4. FailbackCluster

失敗自動恢復，後臺記錄失敗請求，定時重發，一般用於消息通知操做。

1-5. FailfastCluster

快速失敗，只發起一次調用，失敗當即報錯，一般用於非冪等性的寫操做。

1-6. ForkingCluster

並行調用，只要一個成功即返回，一般用於實時性要求較高的操做，但須要浪費更多服務資源。

1-7. MergeableCluster

按組合並返回結果，好比菜單服務，接口同樣，但有多種實現，用group區分，如今消費者需從每種group中調用一次返回結果，合併結果返回，這樣就能夠實現聚合菜單項。

2. Directory-目錄服務

Directory.java的頭部註釋中，引用http://en.wikipedia.org/wiki/... service作了一個介紹。directory service有點陌生，可是name service應該比較熟悉吧，就是命名服務。 每個name service都映射了網絡中的一種資源。
這裏面一個Directory就表明一個provider提供的List<Invoker>，可是這個List<Invoker>多是動態變化的，好比註冊中心的推送變動。
Cluster將Directory中的多個Invoker假裝成一個Invoker，對上層透明，假裝過程包含了容錯邏輯，調用失敗後，重試另外一個。

2-1. RegistryDirectory

註冊目錄服務，它的Invoker集合是從註冊中心獲取的，好比消費方要調用某遠程服務，會向註冊中心訂閱這個服務的全部服務提供方，訂閱時和服務提供方數據有變更時，會回調消費方的回調接口並傳入服務的全部提供方的url地址，而後將urls地址轉爲爲invokers，也就是refer遠程服務。

2-2. StaticDirectory

靜態目錄服務， 它的全部Invoker經過構造函數傳入。

3. Router-路由規則

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

4. LoadBalance-負載均衡

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

4-1. RandomLoadBalance（默認的）

隨機，按權重設置隨機機率。
在一個截面上碰撞的機率高，但調用量越大分佈越均勻，並且按機率使用權重後也比較均勻，有利於動態調整提供者權重。

4-2. RoundRobinLoadBalance

輪循，按公約後的權重設置輪循比率。
存在慢的提供者累積請求問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上。

4-3. LeastActiveLoadBalance

最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差，使慢的機器收到更少。
例如，每一個服務維護一個活躍數計數器。當A機器開始處理請求，該計數器加1，此時A還未處理完成。若處理完畢則計數器減1。而B機器接受到請求後很快處理完畢。那麼A,B的活躍數分別是1，0。當又產生了一個新的請求，則選擇B機器去執行(B活躍數最小)，這樣使慢的機器A收到少的請求。

4-4. ConsistentHashLoadBalance

一致性Hash，相同參數的請求老是發到同一提供者。
當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。
算法參見：http://en.wikipedia.org/wiki/...。缺省只對第一個參數Hash，若是要修改，請配置 <dubbo:parameter key="hash.arguments" value="0,1" />缺省用160份虛擬節點，若是要修改，請配置 <dubbo:parameter key="hash.nodes" value="320" />