原文地址：http://www.carlzone.cn/dubbo/17-dubbo-cluster-summary/
在集中式環境中服務的機器臺只有一臺，這樣對於服務不僅存在服務單點故障問題而且還存在流量問題。爲了解決這個問題，就引入的分佈式與集羣概念。
>分佈式：一個業務分拆多個子業務，部署在不同的服務器上 >集羣：同一個業務，部署在多個服務器上
當請求來臨時，如何從多個服務器中，選擇一個有效、合適的服務器，這個集羣所需要面對一問題。所以在集羣裏面就引申出負載均衡（LoadBalance），高可用（HA），路由（Route）等概念。我們來看一下 dubbo 在進行服務調用的時候是如何處理的。
這張集羣容錯包含以下幾個角色：
Invoker：對Provider(服務提供者) 的一個可調用 Service 接口的抽象，Invoker封裝了Provider地址及Service接口信息。Cluster：Directory中的多個Invoker僞裝成一個Invoker，對上層透明，僞裝過程包含了容錯邏輯，調用失敗後，重試另一個Directory：代表多個Invoker，可以把它看成List<Invoker>，但與 List 不同的是，它的值可能是動態變化的，比如註冊中心推送變更Router： 負責從多個Invoker中按路由規則選出子集，比如讀寫分離，應用隔離等LoadBalance：LoadBalance負責從多個Invoker中選出具體的一個用於本次調用，選的過程包含了負載均衡算法，調用失敗後，需要重選.
我們再來對照看一下 dubbo 的核心架構圖。
通過之前的一系列的源碼分析，以及上面的二張 dubbo 架構圖，我們不難得出以下結論。
當 dubbo 的 Provider 進行一次服務暴露的時候，就會有 Registry 註冊一個服務，然後通過 Netty 進行暴露請求。當 Consumer 需要進行服務調用的時候，通過 Cluster 把多個服務僞裝成一個 Invoke，這樣對調用方就不需要關心到底有多少個服務調用方了。
集羣通過到註冊中心去拿暴露當前服務的接口信息的獲取到 Directory (服務列表)，然後通過配置的 Route (路由規則) 找到滿足的 Invoke 列表，最後通過 LoadBalance 找到合適的一個 Invoke 進行遠程調用。在集羣調用失敗時，Dubbo 提供了多種容錯方案，缺省爲 failover 重試。這樣就對服務的高可用做到了保證。