Dubbo入門和應用

dubbo 是阿裡巴巴公司開源的一個高性能優秀的服務架構，使得應用可通過高性能的 rpc 實作服務的輸出和輸入功能，以及soa服務治理方案。

（1）主要核心部件：

remoting: 網絡通信架構，實作了 sync-over-async 和 request-response 消息機制.

rpc: 一個遠端過程調用的抽象，支援負載均衡、容災和叢集功能

registry: 服務目錄架構用于服務的注冊和服務事件釋出和訂閱

（2）幾點我的了解

dubbo使用hessian協定實作，這裡的高性能的 rpc指的就是hessian協；

dubbo是一個遠端服務調用在分布式系統中的一個實作架構，不再使用以前的web service方式，而是通過服務提供者和消費者的方式調用；

并且通過在注冊中心注冊，消費者無需知道提供方的位址，可以通過注冊中心讀取，注冊中心作為中間層，在中間層又可以實作負載均衡等，

這樣就不需要負載均衡硬體，真正的實作大規模分布式系統的遠端服務調用；

同時在注冊中心當機的情況下，支援服務提供者和消費者直接通過位址調用，在容錯上表現較好；

并且改變服務提供者不需要通知服務消費者，實作了平滑删除和添加；

透明化的遠端方法調用，就像調用本地方法一樣調用遠端方法，隻需簡單配置，沒有任何api侵入。

軟負載均衡及容錯機制，可在内網替代f5等硬體負載均衡器，降低成本，減少單點。

服務自動注冊與發現，不再需要寫死服務提供方位址，注冊中心基于接口名查詢服務提供者的ip位址，并且能夠平滑添加或删除服務提供者。

（1）設計結構

provider：

暴露服務方稱之為“服務提供者”。

consumer：

調用遠端服務方稱之為“服務消費者”。

registry：

服務注冊與發現的中心目錄服務稱之為“服務注冊中心”。

monitor：

統計服務的調用次調和調用時間的日志服務稱之為“服務監控中心”。

container:

服務運作容器。

（2）調用過程

服務容器負責啟動，加載，運作服務提供者。

服務提供者在啟動時，向注冊中心注冊自己提供的服務。

服務消費者在啟動時，向注冊中心訂閱自己所需的服務。

注冊中心傳回服務提供者位址清單給消費者，如果有變更，注冊中心将基于長連接配接推送變更資料給消費者。

服務消費者，從提供者位址清單中，基于軟負載均衡算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。

 服務消費者和提供者，在記憶體中累計調用次數和調用時間，定時每分鐘發送一次統計資料到監控中心。

（3）dubbo的特性

連通性：

注冊中心負責服務位址的注冊與查找，相當于目錄服務，服務提供者和消費者隻在啟動時與注冊中心互動，注冊中心不轉發請求，壓力較小

監控中心負責統計各服務調用次數，調用時間等，統計先在記憶體彙總後每分鐘一次發送到監控中心伺服器，并以報表展示

服務提供者向注冊中心注冊其提供的服務，并彙報調用時間到監控中心，此時間不包含網絡開銷

服務消費者向注冊中心擷取服務提供者位址清單，并根據負載算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷

注冊中心，服務提供者，服務消費者三者之間均為長連接配接，監控中心除外

注冊中心通過長連接配接感覺服務提供者的存在，服務提供者當機，注冊中心将立即推送事件通知消費者

注冊中心和監控中心全部當機，不影響已運作的提供者和消費者，消費者在本地緩存了提供者清單

注冊中心和監控中心都是可選的，服務消費者可以直連服務提供者

健狀性：

監控中心宕掉不影響使用，隻是丢失部分采樣資料

資料庫宕掉後，注冊中心仍能通過緩存提供服務清單查詢，但不能注冊新服務

注冊中心對等叢集，任意一台宕掉後，将自動切換到另一台

注冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地緩存通訊

服務提供者無狀态，任意一台宕掉後，不影響使用

服務提供者全部宕掉後，服務消費者應用将無法使用，并無限次重連等待服務提供者恢複

伸縮性：

注冊中心為對等叢集，可動态增加機器部署執行個體，所有用戶端将自動發現新的注冊中心

服務提供者無狀态，可動态增加機器部署執行個體，注冊中心将推送新的服務提供者資訊給消費者

當服務調用失敗時（比如響應逾時），根據我們的業務不同，可以使用不同的政策來應對這種失敗。

比如我們調用的服務是一個查詢服務，不會修改資料庫，那麼可以給該服務設定容錯方式為failover ， 當調用失敗時，自動切換到其他服務提供者去調用，當失敗次數超過指定重試次數，那麼就抛出錯誤；

如果服務是更新資料的服務，那就不能使用失敗重試的方式了， 因為這樣可能産生資料重複修改的問題，比如調用提供者a的插入使用者方法，但是該方法業務邏輯複雜，執行過程很慢，導緻響應逾時， 那麼此時如果再去調用另外一個服務提供者的插入使用者方法，将會又重複插入同一個使用者。 對于這種類型的服務，可以使用容錯方式為failfast，如果第一次調用失敗，立即報錯，不需要重試；

另外還有下面幾種容錯類型：

failsafe 出現錯誤，直接忽略，不重試也不報錯

failback 失敗後不報錯，會将該失敗請求，定時重發，适合消息通知類型的服務

forking 并行調用多個伺服器，隻要在某一台提供者上面成功，那麼方法傳回， 适合實時性要求較高的查詢服務， 但是要犧牲性能。因為每台伺服器會做同一個操作

broadcast 廣播調用所有服務提供者，逐個調用，任意一台報錯則報錯。 适合與更新每台提供者上面的緩存這種類型的服務。

dubbo提供了多種協定給使用者選擇， 如dubbo、hessian、rmi 。 并可為每個服務指定不同的傳輸協定，粒度可以細化到方法， 不同服務在性能上适用不同協定進行傳輸，比如大資料用短連接配接協定，小資料大并發用長連接配接協定。

hessian、spring httpinvoke等。

相比其他同類元件，dubbo有自己的一些優勢：

（1）服務注冊中心

相比hessian類rpc架構，dubbo有自己的服務中心， 寫好的服務可以注冊到服務中心， 用戶端從服務中心尋找服務，然後再到相應的服務提供者機器擷取服務

通過服務中心可以實作叢集、負載均衡、高可用(容錯) 等重要功能。

服務中心一般使用zookeeper實作， 也有redis和其他一些方式 。 以使用zookeeper作為服務中心為例， 服務提供者啟動後會在zookeeper的 /dubbo節點下建立提供的服務節點，包含服務提供者ip、port等資訊。 服務提供者關閉時會從zookeeper中移除對應的服務。

服務使用者會從注冊中心zookeeper中尋找服務，同一個服務可能會有多個提供者， dubbo會幫我們找到合适的服務提供者，也就是針對服務提供者的負載均衡。

（2）負載均衡

當同一個服務有多個提供者在提供服務時， 用戶端如何正确的選擇提供者實作負載均衡dubbo也給我們提供了幾種方案：

random 随機選提供者，并可以給提供者設定權重

roundrobin 輪詢選擇提供者

leastactive 最少活躍調用數，相同活躍數的随機，活躍數指調用前後計數差。使慢的提供者收到更少請求，因為越慢的提供者的調用前後計數差會越大。

consistenthash 一緻性hash，相同參數的請求發到同一台機器上

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

在開發階段為了友善測試，通常系統用戶端能指定調用某個服務提供者，那麼可以在引用服務時加一個url參數去指定服務提供者

1

2

<code>&lt;dubbo:reference</code>

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

在dubbo配置檔案中可以通過制定版本實作連接配接制定提供者，

也就是通過服務版本可以控制服務的不相容更新；

當同一個服務有多種實作時，可以使用服務分組進行區分。