Dubbo 是阿里巴巴開源項目的一個分布式服務(wù)框架，至于于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案拗馒，以及SOA服務(wù)治理方案。

RPC遠(yuǎn)程調(diào)用：封裝長鏈接NIO框架，如Netty茎毁，Mina等，采用的是多線程模式忱辅。

集群容錯七蜘，提供基于借口方法的遠(yuǎn)程調(diào)用功能，并實現(xiàn)了負(fù)載均衡策略墙懂，失敗容錯功能橡卤。

服務(wù)發(fā)現(xiàn)，集成了Apache的Zookeeper組件损搬，用于服務(wù)的注冊和發(fā)現(xiàn)碧库。

Dubbo最大的特點(diǎn)是按照分層架構(gòu)思維構(gòu)建應(yīng)用服務(wù)，使用這種方式可以使各個層之間解耦合（或者最大限度地松耦合）巧勤。從服務(wù)模型的角度來看嵌灰，Dubbo采用的是一種非常簡單的模型，要么是提供方提供服務(wù)颅悉，要么是消費(fèi)方消費(fèi)服務(wù)沽瞭，所以基于這一點(diǎn)可以抽象出服務(wù)提供方（Provider）和服務(wù)消費(fèi)方（Consumer）兩個角色。

Dubbo包含遠(yuǎn)程通訊剩瓶、服務(wù)集群和服務(wù)發(fā)現(xiàn)與注冊三個核心部分驹溃。提供透明化的遠(yuǎn)程方法調(diào)用，實現(xiàn)像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法延曙，只需簡單配置豌鹤，沒有任何API侵入。同時具備軟負(fù)載均衡及容錯機(jī)制搂鲫，可在內(nèi)網(wǎng)替代F5等硬件負(fù)載均衡器傍药，降低成本，減少單點(diǎn)」樟桑可以實現(xiàn)服務(wù)自動注冊與發(fā)現(xiàn)拣挪，不再需要寫死服務(wù)提供方地址，注冊中心基于接口名查詢服務(wù)提供者的IP地址俱诸，并且能夠平滑添加或刪除服務(wù)提供者菠劝。

Remoting：遠(yuǎn)程通訊，提供對多種NIO框架抽象封裝睁搭，包括“同步轉(zhuǎn)異步”和“請求-響應(yīng)”模式的信息交換方式赶诊。

Cluster：服務(wù)集群，提供基于接口方法的透明遠(yuǎn)程過程調(diào)用园骆，包括多協(xié)議支持舔痪，以及軟負(fù)載均衡，失敗容錯锌唾，地址路由锄码，動態(tài)配置等集群支持。

Registry：服務(wù)發(fā)現(xiàn)與注冊晌涕，基于注冊中心目錄服務(wù)滋捶，使服務(wù)消費(fèi)方能動態(tài)的查找服務(wù)提供方，使地址透明余黎，使服務(wù)提供方可以平滑增加或減少機(jī)器重窟。

2. Dubbo組件角色

Dubbo組件

序號 組件角色 說明

1 Provider 服務(wù)提供者，向外提供服務(wù)

2 Consumer 服務(wù)消費(fèi)者惧财，調(diào)用遠(yuǎn)程服務(wù)

3 Registry 服務(wù)發(fā)現(xiàn)與注冊中心

4 Monitor 服務(wù)監(jiān)控巡扇，統(tǒng)計服務(wù)調(diào)用頻度與時間

5 Container 服務(wù)運(yùn)行容器

Dubbo服務(wù)組件調(diào)用關(guān)秕說明 ：

服務(wù)容器Container負(fù)責(zé)啟動，加載垮衷，運(yùn)行服務(wù)提供者霎迫。

服務(wù)提供者Provider在啟動時，向注冊中心注冊自己提供的服務(wù)帘靡。

服務(wù)消費(fèi)者Consumer在啟動時，向注冊中心訂閱自己所需的服務(wù)瓤帚。

服務(wù)注冊中心Registry返回服務(wù)提供者地址列表給消費(fèi)者描姚，如果有變更，注冊中心將基于長連接推送變更數(shù)據(jù)給消費(fèi)者戈次。

服務(wù)消費(fèi)者Consumer轩勘，從提供者地址列表中，基于軟負(fù)載均衡算法怯邪，選一臺提供者進(jìn)行調(diào)用绊寻，如果調(diào)用失敗，再選另一臺調(diào)用。

服務(wù)消費(fèi)者Consumer和提供者Provider澄步，在內(nèi)存中累計調(diào)用次數(shù)和調(diào)用時間冰蘑，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心Monitor。

Dubbo服務(wù)結(jié)構(gòu)

3. Dubbo總體架構(gòu)

image

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

下面，結(jié)合Dubbo官方文檔东羹，我們分別理解一下框架分層架構(gòu)中剂桥，各個層次的設(shè)計要點(diǎn)：

服務(wù)接口層（Service）：與實際業(yè)務(wù)邏輯相關(guān)的，根據(jù)服務(wù)提供方和服務(wù)消費(fèi)方的 業(yè)務(wù)設(shè)計對應(yīng)的接口和實現(xiàn)属提。

配置層（Config）：對外配置接口权逗，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類垒拢，也可以通過Spring解析配置生成配置類旬迹。

服務(wù)代理層（Proxy）：服務(wù)接口透明代理，生成服務(wù)的客戶端Stub和服務(wù)器端Skeleton求类，以ServiceProxy為中心奔垦，擴(kuò)展接口為ProxyFactory。

服務(wù)注冊層（Registry）：封裝服務(wù)地址的注冊與發(fā)現(xiàn)尸疆，以服務(wù)URL為中心椿猎，擴(kuò)展接口為RegistryFactory、Registry和RegistryService寿弱》该撸可能沒有服務(wù)注冊中心，此時服務(wù)提供方直接暴露服務(wù)症革。

集群層（Cluster）：封裝多個提供者的路由及負(fù)載均衡筐咧，并橋接注冊中心，以Invoker為中心噪矛，擴(kuò)展接口為Cluster量蕊、Directory、Router和LoadBalance艇挨。將多個服務(wù)提供方組合為一個服務(wù)提供方残炮，實現(xiàn)對服務(wù)消費(fèi)方來透明，只需要與一個服務(wù)提供方進(jìn)行交互缩滨。

監(jiān)控層（Monitor）：RPC調(diào)用次數(shù)和調(diào)用時間監(jiān)控势就，以Statistics為中心泉瞻，擴(kuò)展接口為MonitorFactory、Monitor和MonitorService苞冯。

遠(yuǎn)程調(diào)用層（Protocol）：封將RPC調(diào)用袖牙，以Invocation和Result為中心，擴(kuò)展接口為Protocol抱完、Invoker和Exporter贼陶。Protocol是服務(wù)域，它是Invoker暴露和引用的主功能入口巧娱，它負(fù)責(zé)Invoker的生命周期管理碉怔。Invoker是實體域，它是Dubbo的核心模型禁添，其它模型都向它靠擾撮胧，或轉(zhuǎn)換成它，它代表一個可執(zhí)行體老翘，可向它發(fā)起invoke調(diào)用芹啥，它有可能是一個本地的實現(xiàn)，也可能是一個遠(yuǎn)程的實現(xiàn)铺峭，也可能一個集群實現(xiàn)墓怀。

信息交換層（Exchange）：封裝請求響應(yīng)模式，同步轉(zhuǎn)異步卫键，以Request和Response為中心傀履，擴(kuò)展接口為Exchanger、ExchangeChannel莉炉、ExchangeClient和ExchangeServer钓账。

網(wǎng)絡(luò)傳輸層（Transport）：抽象mina和netty為統(tǒng)一接口，以Message為中心絮宁，擴(kuò)展接口為Channel梆暮、Transporter、Client绍昂、Server和Codec啦粹。

數(shù)據(jù)序列化層（Serialize）：可復(fù)用的一些工具，擴(kuò)展接口為Serialization窘游、 ObjectInput卖陵、ObjectOutput和ThreadPool。

從上圖可以看出张峰，Dubbo對于服務(wù)提供方和服務(wù)消費(fèi)方，從框架的10層中分別提供了各自需要關(guān)心和擴(kuò)展的接口棒旗，構(gòu)建整個服務(wù)生態(tài)系統(tǒng)（服務(wù)提供方和服務(wù)消費(fèi)方本身就是一個以服務(wù)為中心的）喘批。

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

在RPC中饶深，Protocol是核心層餐曹，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC調(diào)用，然后在Invoker的主過程上Filter攔截點(diǎn)敌厘。

圖中的Consumer和Provider是抽象概念台猴，只是想讓看圖者更直觀的了解哪些類分屬于客戶端與服務(wù)器端，不用Client和Server的原因是Dubbo在很多場景下都使用Provider俱两、Consumer饱狂、Registry、Monitor劃分邏輯拓普節(jié)點(diǎn)宪彩，保持統(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實際上不算一層，而是一個獨(dú)立的節(jié)點(diǎn)笆豁，只是為了全局概覽郎汪，用層的方式畫在一起赤赊。