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