1 Dubbo核心功能
對于以上的3個核心功能，Dubbo有涉及到哪些組件角色，來協(xié)作完成分布式治理的呢？
2 Dubbo組件角色
組件角色 | 說明 |
Provider | 暴露服務(wù)的服務(wù)提供方 |
Consumer | 調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費方 |
Registry | 服務(wù)注冊與發(fā)現(xiàn)的注冊中心 |
Monitor | 統(tǒng)計服務(wù)的調(diào)用次調(diào)和調(diào)用時間的監(jiān)控中心 |
Container | 服務(wù)運行容器 |
調(diào)用關(guān)系說明：
服務(wù)容器Container負(fù)責(zé)啟動，加載，運行服務(wù)提供者。 服務(wù)提供者Provider在啟動時，向注冊中心注冊自己提供的服務(wù)。 服務(wù)消費者Consumer在啟動時，向注冊中心訂閱自己所需的服務(wù)。 注冊中心Registry返回服務(wù)提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數(shù)據(jù)給消費者。 服務(wù)消費者Consumer，從提供者地址列表中，基于軟負(fù)載均衡算法，選一臺提供者進(jìn)行調(diào)用，如果調(diào)用失敗，再選另一臺調(diào)用。 服務(wù)消費者Consumer和提供者Provider，在內(nèi)存中累計調(diào)用次數(shù)和調(diào)用時間，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心Monitor。
3 Dubbo總體架構(gòu)
上面介紹給出的都是抽象層面的組件關(guān)系，可以說是縱向的以服務(wù)模型的組件分析，其實Dubbo最大的特點是按照分層的方式來架構(gòu)，使用這種方式可以使各個層之間解耦合（或者最大限度地松耦合）。所以，我們橫向以分層的方式來看下Dubbo的架構(gòu)，如圖所示：
Dubbo框架設(shè)計一共劃分了10個層，而最上面的Service層是留給實際想要使用Dubbo開發(fā)分布式服務(wù)的開發(fā)者實現(xiàn)業(yè)務(wù)邏輯的接口層。圖中左邊淡藍(lán)背景的為服務(wù)消費方使用的接口，右邊淡綠色背景的為服務(wù)提供方使用的接口， 位于中軸線上的為雙方都用到的接口。
下面，結(jié)合Dubbo官方文檔，我們分別理解一下框架分層架構(gòu)中，各個層次的設(shè)計要點：
從上圖可以看出，Dubbo對于服務(wù)提供方和服務(wù)消費方，從框架的10層中分別提供了各自需要關(guān)心和擴(kuò)展的接口，構(gòu)建整個服務(wù)生態(tài)系統(tǒng)（服務(wù)提供方和服務(wù)消費方本身就是一個以服務(wù)為中心的）。
根據(jù)官方提供的，對于上述各層之間關(guān)系的描述，如下所示：
在RPC中，Protocol是核心層，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC調(diào)用，然后在Invoker的主過程上Filter攔截點。 圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的了解哪些類分屬于客戶端與服務(wù)器端，不用Client和Server的原因是Dubbo在很多場景下都使用Provider、Consumer、Registry、Monitor劃分邏輯拓普節(jié)點，保持統(tǒng)一概念。 而Cluster是外圍概念，所以Cluster的目的是將多個Invoker偽裝成一個Invoker，這樣其它人只要關(guān)注Protocol層Invoker即可，加上Cluster或者去掉Cluster對其它層都不會造成影響，因為只有一個提供者時，是不需要Cluster的。 Proxy層封裝了所有接口的透明化代理，而在其它層都以Invoker為中心，只有到了暴露給用戶使用時，才用Proxy將Invoker轉(zhuǎn)成接口，或?qū)⒔涌趯崿F(xiàn)轉(zhuǎn)成Invoker，也就是去掉Proxy層RPC是可以Run的，只是不那么透明，不那么看起來像調(diào)本地服務(wù)一樣調(diào)遠(yuǎn)程服務(wù)。 而Remoting實現(xiàn)是Dubbo協(xié)議的實現(xiàn)，如果你選擇RMI協(xié)議，整個Remoting都不會用上，Remoting內(nèi)部再劃為Transport傳輸層和Exchange信息交換層，Transport層只負(fù)責(zé)單向消息傳輸，是對Mina、Netty、Grizzly的抽象，它也可以擴(kuò)展UDP傳輸，而Exchange層是在傳輸層之上封裝了Request-Response語義。 Registry和Monitor實際上不算一層，而是一個獨立的節(jié)點，只是為了全局概覽，用層的方式畫在一起。
4 服務(wù)調(diào)用流程
5 注冊/注銷服務(wù)
服務(wù)的注冊與注銷，是對服務(wù)提供方角色而言，那么注冊服務(wù)與注銷服務(wù)的時序圖，如圖所示：
6 訂閱/取消服務(wù)
為了滿足應(yīng)用系統(tǒng)的需求，服務(wù)消費方的可能需要從服務(wù)注冊中心訂閱指定的有服務(wù)提供方發(fā)布的服務(wù)，在得到通知可以使用服務(wù)時，就可以直接調(diào)用服務(wù)。反過來，如果不需要某一個服務(wù)了，可以取消該服務(wù)。下面看一下對應(yīng)的時序圖，如圖所示：
作者：猿碼架構(gòu)
“做程序員，圈子和學(xué)習(xí)最重要”因為有有了圈子可以讓你少走彎路，擴(kuò)寬人脈，擴(kuò)展思路，學(xué)習(xí)他人的一些經(jīng)驗及學(xué)習(xí)方法！同時在這分享一下是一直以來整理的Java后端進(jìn)階筆記文檔和學(xué)習(xí)資料免費分享給大家！需要資料的朋友私信我扣【1】
