1 Dubbo核心功能

對于以上的3個核心功能，Dubbo有涉及到哪些組件角色，來協(xié)作完成分布式治理的呢？

2 Dubbo組件角色

調用關系說明：

服務容器Container負責啟動，加載，運行服務提供者。 服務提供者Provider在啟動時，向注冊中心注冊自己提供的服務。 服務消費者Consumer在啟動時，向注冊中心訂閱自己所需的服務。 注冊中心Registry返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數(shù)據(jù)給消費者。 服務消費者Consumer，從提供者地址列表中，基于軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。 服務消費者Consumer和提供者Provider，在內存中累計調用次數(shù)和調用時間，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心Monitor。

3 Dubbo總體架構

上面介紹給出的都是抽象層面的組件關系，可以說是縱向的以服務模型的組件分析，其實Dubbo最大的特點是按照分層的方式來架構，使用這種方式可以使各個層之間解耦合（或者最大限度地松耦合）。所以，我們橫向以分層的方式來看下Dubbo的架構，如圖所示：

Dubbo框架設計一共劃分了10個層，而最上面的Service層是留給實際想要使用Dubbo開發(fā)分布式服務的開發(fā)者實現(xiàn)業(yè)務邏輯的接口層。圖中左邊淡藍背景的為服務消費方使用的接口，右邊淡綠色背景的為服務提供方使用的接口， 位于中軸線上的為雙方都用到的接口。

下面，結合Dubbo官方文檔，我們分別理解一下框架分層架構中，各個層次的設計要點：

從上圖可以看出，Dubbo對于服務提供方和服務消費方，從框架的10層中分別提供了各自需要關心和擴展的接口，構建整個服務生態(tài)系統(tǒng)（服務提供方和服務消費方本身就是一個以服務為中心的）。

根據(jù)官方提供的，對于上述各層之間關系的描述，如下所示：

在RPC中，Protocol是核心層，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC調用，然后在Invoker的主過程上Filter攔截點。 圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的了解哪些類分屬于客戶端與服務器端，不用Client和Server的原因是Dubbo在很多場景下都使用Provider、Consumer、Registry、Monitor劃分邏輯拓普節(jié)點，保持統(tǒng)一概念。 而Cluster是外圍概念，所以Cluster的目的是將多個Invoker偽裝成一個Invoker，這樣其它人只要關注Protocol層Invoker即可，加上Cluster或者去掉Cluster對其它層都不會造成影響，因為只有一個提供者時，是不需要Cluster的。 Proxy層封裝了所有接口的透明化代理，而在其它層都以Invoker為中心，只有到了暴露給用戶使用時，才用Proxy將Invoker轉成接口，或將接口實現(xiàn)轉成Invoker，也就是去掉Proxy層RPC是可以Run的，只是不那么透明，不那么看起來像調本地服務一樣調遠程服務。 而Remoting實現(xiàn)是Dubbo協(xié)議的實現(xiàn)，如果你選擇RMI協(xié)議，整個Remoting都不會用上，Remoting內部再劃為Transport傳輸層和Exchange信息交換層，Transport層只負責單向消息傳輸，是對Mina、Netty、Grizzly的抽象，它也可以擴展UDP傳輸，而Exchange層是在傳輸層之上封裝了Request-Response語義。 Registry和Monitor實際上不算一層，而是一個獨立的節(jié)點，只是為了全局概覽，用層的方式畫在一起。

4 服務調用流程

5 注冊/注銷服務

服務的注冊與注銷，是對服務提供方角色而言，那么注冊服務與注銷服務的時序圖，如圖所示：

6 訂閱/取消服務

為了滿足應用系統(tǒng)的需求，服務消費方的可能需要從服務注冊中心訂閱指定的有服務提供方發(fā)布的服務，在得到通知可以使用服務時，就可以直接調用服務。反過來，如果不需要某一個服務了，可以取消該服務。下面看一下對應的時序圖，如圖所示：

作者：猿碼架構

“做程序員，圈子和學習最重要”因為有有了圈子可以讓你少走彎路，擴寬人脈，擴展思路，學習他人的一些經驗及學習方法！同時在這分享一下是一直以來整理的Java后端進階筆記文檔和學習資料免費分享給大家！需要資料的朋友私信我扣【1】