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本身的高階特性.正如我們在說自定義擴充套件的時候一樣,這兩個特徵同樣也可以進行自定義擴充套件,使用者可以根據自己實際的需求來擴充套件他們從而滿足專案的實際需求.
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本身的高階特性.正如我們在說自定義擴充套件的時候一樣,這兩個特徵同樣也可以進行自定義擴充套件,使用者可以根據自己實際的需求來擴充套件他們從而滿足專案的實際需求.