Dubbo的設計結構和工做原理

（1）設計結構

Provider：暴露服務方稱之爲「服務提供者」。
Consumer：調用遠程服務方稱之爲「服務消費者」。
Registry：服務註冊與發現中心的目錄服務稱之爲「服務註冊中心」。
Monitor：統計服務的調用次調和調用時間的日誌服務稱之爲「服務監控中心」。
Container：服務運行容器。

（2）調用過程

服務容器負責啓動、加載、運行服務提供者。
服務提供者在啓動時，向註冊中心註冊本身提供的服務。
服務消費者在啓動時，向註冊中心訂閱本身所需的服務。
註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。
服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。
服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

（3）Dubbo的特性

 

連通性： 
`註冊中心`負責服務地址的註冊與查找，至關於`目錄服務`，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小。
監控中心負責統計各服務調用次數，調用時間等，統計先在內存彙總後每分鐘一次發送到監控中心服務器，並以報表展現。
服務提供者向註冊中心註冊其提供的服務，並彙報調用時間到監控中心，此時間不包含網絡開銷。
服務消費者向註冊中心獲取服務提供者地址列表，並根據`負載算法`直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷。
註冊中心、服務提供者、服務消費者三者之間均爲`長鏈接`，監控中心除外。
註冊中心經過長鏈接感知服務提供者的存在，服務提供者宕機，註冊中心將當即推送事件通知消費者。
註冊中心和監控中心所有宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表。
註冊中心和監控中心都是可選的，服務消費者能夠直連服務提供者。
健狀性： 
監控中心宕掉不影響使用，只是丟失部分採樣數據。
註冊中心數據庫宕掉後，註冊中心仍能經過緩存提供服務列表查詢，但不能註冊新服務。
註冊中心對等集羣，任意一臺宕掉後，將自動切換到另外一臺。
註冊中心所有宕掉後，服務提供者和服務消費者仍能經過本地緩存通信。
服務提供者無狀態，任意一臺宕掉後，不影響使用。
服務提供者所有宕掉後，服務消費者應用將沒法使用，並沒有限次重連等待服務提供者恢復。
伸縮性： 
註冊中心爲對等集羣，可動態增長機器部署實例，全部客戶端將自動發現新的註冊中心。
服務提供者無狀態，可動態增長機器部署實例，註冊中心將推送新的服務提供者信息給消費者。

Dubbo的集羣容錯機制

當服務調用失敗時（好比響應超時），根據咱們的業務不一樣，可使用不一樣的策略來應對這種失敗。
好比： 
咱們調用的服務是一個查詢服務，不會修改數據庫，那麼能夠給該服務設置容錯方式爲`failover`，當調用失敗時，自動切換到其餘服務提供者去調用，當失敗次數超過指定重試次數，那麼就拋出錯誤；
若是服務是更新數據的服務，那就不能使用失敗重試的方式了， 由於這樣可能產生數據重複修改的問題，好比調用提供者A的插入用戶方法，可是該方法業務邏輯複雜，執行過程很慢，致使響應超時，那麼此時若是再去調用另一個服務提供者的插入用戶方法，將會又重複插入同一個用戶。對於這種類型的服務，可使用容錯方式爲`failfast`，若是第一次調用失敗，當即報錯，不須要重試。
另外還有下面幾種容錯類型： 
failsafe 出現錯誤，直接忽略，不重試也不報錯。
failback 失敗後不報錯，會將該失敗請求，定時重發，適合消息通知類型的服務。
forking 並行調用多個服務器，只要在某一臺提供者上面成功，那麼方法返回， 適合實時性要求較高的查詢服務，可是要犧牲性能。由於每臺服務器會作同一個操做。
broadcast 廣播調用全部服務提供者，逐個調用，任意一臺報錯則報錯。適合與更新每臺提供者上面的緩存這種類型的服務。

 

Dubbo的特性

（1）服務註冊中心

• 相比Hessian類RPC框架，Dubbo有本身的服務中心， 寫好的服務能夠註冊到服務中心， 客戶端從服務中心尋找服務，而後再到相應的服務提供者機器獲取服務。經過服務中心能夠實現集羣、負載均衡、高可用(容錯) 等重要功能。
• 服務中心通常使用zookeeper實現，也有redis和其餘一些方式。以使用zookeeper做爲服務中心爲例，服務提供者啓動後會在zookeeper的/dubbo節點下建立提供的服務節點，包含服務提供者ip、port等信息。服務提供者關閉時會從zookeeper中移除對應的服務。
• 服務使用者會從註冊中心zookeeper中尋找服務，同一個服務可能會有多個提供者，Dubbo會幫咱們找到合適的服務提供者，也就是針對服務提供者的負載均衡。

（2）負載均衡

• 當同一個服務有多個提供者在提供服務時，客戶端如何正確的選擇提供者實現負載均衡呢？dubbo也給咱們提供了幾種方案：
  • random `隨機`選提供者，並能夠給提供者設置權重
  • roundrobin `輪詢`選擇提供者
  • leastactive 最少活躍調用數，相同活躍數的隨機，活躍數：指調用先後計數差。使慢的提供者收到更少請求，由於越慢的提供者的調用先後計數差會越大。
  • consistenthash 一致性hash，相同參數的請求發到同一臺機器上。

（3）簡化測試，容許直連提供者

• 在開發階段爲了方便測試，一般系統客戶端能指定調用某個服務提供者，那麼能夠在引用服務時加一個url參數去指定服務提供者。 配置以下：

    <dubbo:reference id="xxxService"interface="com.alibaba.xxx.XxxService"url="dubbo://localhost:20890"/>

（4）服務版本，服務分組

• 在Dubbo配置文件中能夠經過制定版本實現鏈接制定提供者，也就是經過服務版本能夠控制服務的不兼容升級；當同一個服務有多種實現時，可使用服務分組進行區分。

https://blog.csdn.net/hzzhoushaoyu/article/details/43273099

https://www.cnblogs.com/woshimrf/p/hello-dubbo.html