隨著業(yè)務(wù)的發(fā)展土居、用戶量的增長(zhǎng)恐疲、系統(tǒng)并發(fā)訪問(wèn)需求越來(lái)越大梢褐，系統(tǒng)數(shù)量增多，調(diào)用依賴關(guān)系也變得復(fù)雜陨界，為了確保系統(tǒng)高可用、高并發(fā)的要求痛阻，系統(tǒng)的架構(gòu)也從單體時(shí)代慢慢遷移至服務(wù)SOA時(shí)代普碎，根據(jù)不同服務(wù)對(duì)系統(tǒng)資源的要求不同，我們可以更合理的配置系統(tǒng)資源录平，使系統(tǒng)資源利用率最大化麻车。而Dubbo則是SOA服務(wù)化治理方案的一個(gè)核心框架。
Dubbo作為阿里巴巴內(nèi)部的SOA服務(wù)化治理方案的核心框架斗这，在2012年時(shí)已經(jīng)每天為2000+個(gè)服務(wù)提供3,000,000,000+次訪問(wèn)量支持动猬，并被廣泛應(yīng)用于阿里巴巴集團(tuán)的各成員站點(diǎn)。Dubbo自2011年開(kāi)源后表箭，已被許多非阿里系公司使用赁咙，其中既有當(dāng)當(dāng)網(wǎng)、網(wǎng)易考拉等互聯(lián)網(wǎng)公司免钻，也有中國(guó)人壽彼水、青島海爾等傳統(tǒng)企業(yè)。
1. Dubbo框架介紹
Dubbo是一個(gè)高性能服務(wù)框架极舔，致力于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案凤覆，以及SOA服務(wù)治理方案，使得應(yīng)用可通過(guò)高性能RPC實(shí)現(xiàn)服務(wù)的輸出和輸入功能拆魏，和Spring框架可以無(wú)縫集成盯桦。
作為一個(gè)分布式服務(wù)框架，以及SOA治理方案渤刃，Dubbo其功能主要包括：
高性能NIO通訊及多協(xié)議集成
服務(wù)動(dòng)態(tài)尋址與路由
軟負(fù)載均衡與容錯(cuò)
依賴分析與服務(wù)降級(jí)
Dubbo最大的特點(diǎn)是按照分層架構(gòu)思維構(gòu)建應(yīng)用服務(wù)拥峦，使用這種方式可以使各個(gè)層之間解耦合（或者最大限度地松耦合）。從服務(wù)模型的角度來(lái)看卖子，Dubbo采用的是一種非常簡(jiǎn)單的模型略号，要么是提供方提供服務(wù)，要么是消費(fèi)方消費(fèi)服務(wù)，所以基于這一點(diǎn)可以抽象出服務(wù)提供方（Provider）和服務(wù)消費(fèi)方（Consumer）兩個(gè)角色玄柠。
Dubbo包含遠(yuǎn)程通訊氛琢、服務(wù)集群和服務(wù)發(fā)現(xiàn)與注冊(cè)三個(gè)核心部分。提供透明化的遠(yuǎn)程方法調(diào)用随闪，實(shí)現(xiàn)像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法阳似，只需簡(jiǎn)單配置，沒(méi)有任何API侵入铐伴。同時(shí)具備軟負(fù)載均衡及容錯(cuò)機(jī)制撮奏，可在內(nèi)網(wǎng)替代F5等硬件負(fù)載均衡器，降低成本当宴，減少單點(diǎn)畜吊。可以實(shí)現(xiàn)服務(wù)自動(dòng)注冊(cè)與發(fā)現(xiàn)户矢，不再需要寫(xiě)死服務(wù)提供方地址玲献，注冊(cè)中心基于接口名查詢服務(wù)提供者的IP地址，并且能夠平滑添加或刪除服務(wù)提供者梯浪。
Remoting：遠(yuǎn)程通訊捌年，提供對(duì)多種NIO框架抽象封裝，包括“同步轉(zhuǎn)異步”和“請(qǐng)求-響應(yīng)”模式的信息交換方式挂洛。
Cluster：服務(wù)集群礼预，提供基于接口方法的透明遠(yuǎn)程過(guò)程調(diào)用，包括多協(xié)議支持虏劲，以及軟負(fù)載均衡托酸，失敗容錯(cuò)，地址路由柒巫，動(dòng)態(tài)配置等集群支持励堡。
Registry：服務(wù)發(fā)現(xiàn)與注冊(cè)，基于注冊(cè)中心目錄服務(wù)堡掏，使服務(wù)消費(fèi)方能動(dòng)態(tài)的查找服務(wù)提供方应结，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器布疼。
2. Dubbo組件角色
| 序號(hào) | 組件角色 | 說(shuō)明 |
|---|---|---|
| 1 | Provider | 服務(wù)提供者摊趾，向外提供服務(wù) |
| 2 | Consumer | 服務(wù)消費(fèi)者币狠，調(diào)用遠(yuǎn)程服務(wù) |
| 3 | Registry | 服務(wù)發(fā)現(xiàn)與注冊(cè)中心 |
| 4 | Monitor | 服務(wù)監(jiān)控游两，統(tǒng)計(jì)服務(wù)調(diào)用頻度與時(shí)間 |
| 5 | Container | 服務(wù)運(yùn)行容器 |
Dubbo服務(wù)組件調(diào)用關(guān)秕說(shuō)明 ：
服務(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ù)侨糟。
服務(wù)注冊(cè)中心Registry返回服務(wù)提供者地址列表給消費(fèi)者，如果有變更瘩燥，注冊(cè)中心將基于長(zhǎng)連接推送變更數(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)
Dubbo框架設(shè)計(jì)一共劃分了10個(gè)層，而最上面的Service層是留給實(shí)際想要使用Dubbo開(kāi)發(fā)分布式服務(wù)的開(kāi)發(fā)者實(shí)現(xiàn)業(yè)務(wù)邏輯的接口層仗哨。圖中左邊淡藍(lán)背景的為服務(wù)消費(fèi)方使用的接口形庭，右邊淡綠色背景的為服務(wù)提供方使用的接口， 位于中軸線上的為雙方都用到的接口厌漂。
下面碘勉，結(jié)合Dubbo官方文檔，我們分別理解一下框架分層架構(gòu)中桩卵，各個(gè)層次的設(shè)計(jì)要點(diǎn)：
服務(wù)接口層（Service）：與實(shí)際業(yè)務(wù)邏輯相關(guān)的验靡，根據(jù)服務(wù)提供方和服務(wù)消費(fèi)方的 業(yè)務(wù)設(shè)計(jì)對(duì)應(yīng)的接口和實(shí)現(xiàn)。
配置層（Config）：對(duì)外配置接口雏节，以ServiceConfig和ReferenceConfig為中心胜嗓，可以直接new配置類(lèi)，也可以通過(guò)Spring解析配置生成配置類(lèi)钩乍。
服務(wù)代理層（Proxy）：服務(wù)接口透明代理辞州，生成服務(wù)的客戶端Stub和服務(wù)器端Skeleton，以ServiceProxy為中心寥粹，擴(kuò)展接口為ProxyFactory变过。
服務(wù)注冊(cè)層（Registry）：封裝服務(wù)地址的注冊(cè)與發(fā)現(xiàn)，以服務(wù)URL為中心涝涤，擴(kuò)展接口為RegistryFactory媚狰、Registry和RegistryService±可能沒(méi)有服務(wù)注冊(cè)中心崭孤，此時(shí)服務(wù)提供方直接暴露服務(wù)。
集群層（Cluster）：封裝多個(gè)提供者的路由及負(fù)載均衡，并橋接注冊(cè)中心辨宠，以Invoker為中心遗锣，擴(kuò)展接口為Cluster、Directory嗤形、Router和LoadBalance精偿。將多個(gè)服務(wù)提供方組合為一個(gè)服務(wù)提供方，實(shí)現(xiàn)對(duì)服務(wù)消費(fèi)方來(lái)透明赋兵，只需要與一個(gè)服務(wù)提供方進(jìn)行交互还最。
監(jiān)控層（Monitor）：RPC調(diào)用次數(shù)和調(diào)用時(shí)間監(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是實(shí)體域达吞，它是Dubbo的核心模型，其它模型都向它靠擾荒典，或轉(zhuǎn)換成它酪劫，它代表一個(gè)可執(zhí)行體，可向它發(fā)起invoke調(diào)用寺董，它有可能是一個(gè)本地的實(shí)現(xiàn)覆糟，也可能是一個(gè)遠(yuǎn)程的實(shí)現(xiàn)，也可能一個(gè)集群實(shí)現(xiàn)遮咖。
信息交換層（Exchange）：封裝請(qǐng)求響應(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對(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的主過(guò)程上Filter攔截點(diǎn)。
圖中的Consumer和Provider是抽象概念鹰椒，只是想讓看圖者更直觀的了解哪些類(lèi)分屬于客戶端與服務(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的粉捻，只是不那么透明礁遣，不那么看起來(lái)像調(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)部再劃為T(mén)ransport傳輸層和Exchange信息交換層，Transport層只負(fù)責(zé)單向消息傳輸沸呐，是對(duì)Mina醇王、Netty、Grizzly的抽象崭添，它也可以擴(kuò)展UDP傳輸寓娩，而Exchange層是在傳輸層之上封裝了Request-Response語(yǔ)義。
Registry和Monitor實(shí)際上不算一層呼渣，而是一個(gè)獨(dú)立的節(jié)點(diǎn)棘伴，只是為了全局概覽，用層的方式畫(huà)在一起屁置。
