1. Dubbo核心功能

Dubbo主要提供了3大核心功能：面向接口的遠(yuǎn)程方法調(diào)用，智能容錯(cuò)和負(fù)載均衡，以及服務(wù)自動(dòng)注冊(cè)和發(fā)現(xiàn)。

1）遠(yuǎn)程方法調(diào)用

網(wǎng)絡(luò)通信框架，提供對(duì)多種NIO框架抽象封裝，包括“同步轉(zhuǎn)異步”和“請(qǐng)求-響應(yīng)”模式的信息交換方式。

 2）智能容錯(cuò)和負(fù)載均衡

提供基于接口方法的透明遠(yuǎn)程過(guò)程調(diào)用，包括多協(xié)議支持，以及軟負(fù)載均衡，失敗容錯(cuò)，地址路由，動(dòng)態(tài)配置等集群支持。

3）服務(wù)注冊(cè)和發(fā)現(xiàn)

服務(wù)注冊(cè)，基于注冊(cè)中心目錄服務(wù)，使服務(wù)消費(fèi)方能動(dòng)態(tài)的查找服務(wù)提供方，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器。

2. Dubbo核心組件

主要包含如下幾個(gè)核心組件：

1)注冊(cè)中心（registry）

生產(chǎn)者在此注冊(cè)并發(fā)布內(nèi)容，消費(fèi)者在此訂閱并接收發(fā)布的內(nèi)容。

2)消費(fèi)者（consumer）

客戶端，從注冊(cè)中心獲取到方法，可以調(diào)用生產(chǎn)者中的方法。

3)生產(chǎn)者（provider）

服務(wù)端，生產(chǎn)內(nèi)容，生產(chǎn)前需要依賴容器（先啟動(dòng)容器）。

4)容器（container）

生產(chǎn)者在啟動(dòng)執(zhí)行的時(shí)候，必須依賴容器才能正常啟動(dòng)（默認(rèn)依賴的是spring容器），

5)監(jiān)控(Monitor)

統(tǒng)計(jì)服務(wù)的調(diào)用次數(shù)與時(shí)間等。

3. Dubbo的架構(gòu)設(shè)計(jì)

Dubbo整體架構(gòu)如下圖所示：

圖中左邊淡藍(lán)背景的為服務(wù)消費(fèi)方使用的接口，右邊淡綠色背景的為服務(wù)提供方使用的接口， 位于中軸線上的為雙方都用到的接口。

Dubbo框架設(shè)計(jì)一共劃分了10個(gè)層：

1. 服務(wù)接口層（Service）

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

2. 配置層（Config）

對(duì)外配置接口，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類，也可以通過(guò)spring解析配置生成配置類。

3.服務(wù)代理層（Proxy）

服務(wù)接口透明代理，生成服務(wù)的客戶端Stub和服務(wù)器端Skeleton，以ServiceProxy為中心，擴(kuò)展接口為ProxyFactory。

4.服務(wù)注冊(cè)層（Registry）

封裝服務(wù)地址的注冊(cè)與發(fā)現(xiàn)，以服務(wù)URL為中心，擴(kuò)展接口為RegistryFactory、Registry和RegistryService?？赡軟](méi)有服務(wù)注冊(cè)中心，此時(shí)服務(wù)提供方直接暴露服務(wù)。

5.集群層（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)行交互。

6.監(jiān)控層（Monitor）

RPC調(diào)用次數(shù)和調(diào)用時(shí)間監(jiān)控，以Statistics為中心，擴(kuò)展接口為MonitorFactory、Monitor和MonitorService。

7.遠(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)。

8. 信息交換層（Exchange）

封裝請(qǐng)求響應(yīng)模式，同步轉(zhuǎn)異步，以Request和Response為中心，擴(kuò)展接口為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

9.網(wǎng)絡(luò)傳輸層（Transport）

抽象mina和netty為統(tǒng)一接口，以Message為中心，擴(kuò)展接口為Channel、Transporter、Client、Server和Codec。

10.數(shù)據(jù)序列化層（Serialize）

可復(fù)用的一些工具，擴(kuò)展接口為Serialization、 ObjectInput、ObjectOutput和ThreadPool。

4. Dubbo調(diào)用流程

 對(duì)照上面的整體架構(gòu)圖，大致分為以下8大步驟：

1、服務(wù)提供者啟動(dòng)，開(kāi)啟Netty服務(wù)，創(chuàng)建Zookeeper客戶端，向注冊(cè)中心注冊(cè)服務(wù)；

2、服務(wù)消費(fèi)者啟動(dòng)，通過(guò)Zookeeper向注冊(cè)中心獲取服務(wù)提供者列表，與服務(wù)提供者通過(guò)Netty建立長(zhǎng)連接；

3、服務(wù)消費(fèi)者通過(guò)接口開(kāi)始遠(yuǎn)程調(diào)用服務(wù)，ProxyFactory通過(guò)初始化Proxy對(duì)象，Proxy通過(guò)創(chuàng)建動(dòng)態(tài)代理對(duì)象；

4、動(dòng)態(tài)代理對(duì)象通過(guò)invoke方法，層層包裝生成一個(gè)Invoker對(duì)象，該對(duì)象包含了代理對(duì)象；

5、Invoker通過(guò)路由，負(fù)載均衡選擇了一個(gè)最合適的服務(wù)提供者，在通過(guò)加入各種過(guò)濾器，協(xié)議層包裝生成一個(gè)新的DubboInvoker對(duì)象；

6、再通過(guò)交換成將DubboInvoker對(duì)象包裝成一個(gè)Reuqest對(duì)象，該對(duì)象通過(guò)序列化通過(guò)NettyClient傳輸?shù)椒?wù)提供者的NettyServer端；

7、到了服務(wù)提供者這邊，再通過(guò)反序列化、協(xié)議解密等操作生成一個(gè)DubboExporter對(duì)象,再層層傳遞處理,會(huì)生成一個(gè)服務(wù)提供端的Invoker對(duì)象；

8、這個(gè)Invoker對(duì)象會(huì)調(diào)用本地服務(wù)，獲得結(jié)果再通過(guò)層層回調(diào)返回到服務(wù)消費(fèi)者，服務(wù)消費(fèi)者拿到結(jié)果后，再解析獲得最終結(jié)果。

到此這篇關(guān)于Java中的RPC框架Dubbo原理和機(jī)制詳解的文章就介紹到這了,更多相關(guān)Dubbo原理和機(jī)制內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論