一、Dubbo調(diào)用關(guān)系說明

1.1 組成部分

在這里主要由四部分組成:

● Provider: 暴露服務(wù)的服務(wù)提供方
Protocol：負(fù)責(zé)提供者和消費(fèi)者之間的協(xié)議交互數(shù)據(jù)
Service：真實(shí)的業(yè)務(wù)服務(wù)信息，可以理解成接口和實(shí)現(xiàn)
Container：Dubbo的運(yùn)行環(huán)境
● Consumer：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方
Protocol：負(fù)責(zé)提供者和消費(fèi)者之間的協(xié)議交互數(shù)據(jù)
Cluster：感知提供者端的列表信息
Proxy：可以理解成提供者的服務(wù)調(diào)用代理，由它接管Consumer中的接口調(diào)用邏輯
● Register：注冊(cè)中心，用于作為服務(wù)發(fā)現(xiàn)和路由配置等工作，提供者和消費(fèi)者都會(huì)在這里進(jìn)行注冊(cè)
● Monitor：用于提供者和消費(fèi)者中的數(shù)據(jù)統(tǒng)計(jì)，比如調(diào)用頻次、成功失敗次數(shù)等信息

1.2 啟動(dòng)和執(zhí)行流程說明

● 提供者端啟動(dòng)，容器負(fù)責(zé)把Service信息加載，并通過Protocol注冊(cè)到注冊(cè)中心；
● 消費(fèi)者端啟動(dòng)，通過監(jiān)聽提供者列表來(lái)感知提供者信息，并在提供者發(fā)生改變時(shí)，通過 注冊(cè)中心及時(shí)通知消費(fèi)端
● 消費(fèi)方通過Proxy模塊發(fā)起請(qǐng)求；
● 消費(fèi)者端利用Cluster模塊選擇真實(shí)的要調(diào)用的提供者；
● 消費(fèi)者利用Consumer中的Protocol將信息發(fā)送給提供者；
● 提供者通過Protocol模塊來(lái)處理消費(fèi)者信息；
● 最后由提供者的Service來(lái)進(jìn)行處理

二、整體調(diào)用鏈路

說明：淡綠色代表服務(wù)生產(chǎn)者的范圍，淡藍(lán)色代表服務(wù)消費(fèi)者的范圍，紅色箭頭代表調(diào)用的方向：業(yè)務(wù)邏輯層 -> RPC層（遠(yuǎn)程過程調(diào)用）-> Remoting（遠(yuǎn)程數(shù)據(jù)傳輸）

整體調(diào)用流程如下：

● 消費(fèi)者通過Interface進(jìn)行方法調(diào)用，統(tǒng)一交由消費(fèi)者端的Proxy，通過ProxyFactory來(lái)進(jìn)行代理對(duì)象的創(chuàng)建，這里使用jdk的javassist技術(shù)
● 交給Filter模塊做統(tǒng)一的過濾請(qǐng)求
● 接下來(lái)就是最主要的Invoker調(diào)用邏輯了
○ 通過Directory去配置中讀取信息，最終通過list方法獲取所有的Invoker
○ 通過Cluster模塊，根據(jù)選擇的具體路由規(guī)則來(lái)選取Invoker列表
○ 通過LoadBalance模塊，根據(jù)負(fù)載均衡策略選擇一個(gè)具體的Invoker來(lái)處理請(qǐng)求
○ 如果執(zhí)行中出現(xiàn)錯(cuò)誤，并且Consumer階段配置了重試機(jī)制，則會(huì)重新嘗試執(zhí)行
● 繼續(xù)經(jīng)過Filter進(jìn)行執(zhí)行功能的前后封裝，Invoker選擇具體的執(zhí)行協(xié)議
● 客戶端進(jìn)行編碼和序列化，然后發(fā)送數(shù)據(jù)
● 達(dá)到Provider中的Server層進(jìn)行反編碼和發(fā)序列化接收到的數(shù)據(jù)
● 使用Exporter選擇執(zhí)行器
● 交由Filter進(jìn)行一個(gè)提供者端的過濾，到達(dá)Invoker執(zhí)行器
● 通過Invoker調(diào)用接口的具體實(shí)現(xiàn)，然后返回結(jié)果

三、Dubbo整體設(shè)計(jì)

圖例說明：

● 圖中左邊淡藍(lán)背景的為服務(wù)消費(fèi)方使用的接口，右邊淡綠色背景的為服務(wù)提供方使用的接口，位于中軸線上的為雙方都用到的接口。
● 圖中從上往下分為十層，各層為單向依賴，右邊的黑色箭頭代表層之間的依賴關(guān)系，每一層都可以剝離上層被復(fù)用，其中Service和Config層為API，其他各層均為SPI
● 圖中綠色的小塊為擴(kuò)展接口，藍(lán)色小塊為實(shí)現(xiàn)類，圖中只顯示用于關(guān)聯(lián)各層的實(shí)現(xiàn)類
● 圖中藍(lán)色虛線為初始化過程，即啟動(dòng)時(shí)組裝鏈，紅色實(shí)線為方法調(diào)用過程，即運(yùn)行時(shí)調(diào)用鏈，紫色箭頭為繼承，可以把子類看做父類的同一個(gè)節(jié)點(diǎn)，線上的文字為調(diào)用的方法。

Dubbo源碼整體設(shè)計(jì)與調(diào)用鏈路十分相似。只不過這里可以看到接口的一些具體實(shí)現(xiàn)以及左側(cè)也有更為詳細(xì)的層次劃分，我們?cè)诤竺娴脑创a解析時(shí)也會(huì)著重介紹其中比較重要的模塊實(shí)現(xiàn)。

接下來(lái)分層進(jìn)行介紹

1、Business業(yè)務(wù)邏輯層
● Service業(yè)務(wù)層：包括業(yè)務(wù)代碼比如接口和實(shí)現(xiàn)類
2、RPC層：遠(yuǎn)程過程調(diào)用層
● config配置層，對(duì)外提供配置，以ServiceConfig、ReferenceConfig為核心，可以直接初始化配置類，也可解析配置文件
● Proxy服務(wù)代理層，無(wú)論是生產(chǎn)者還是消費(fèi)者，框架都會(huì)產(chǎn)生一個(gè)代理類，整個(gè)過程對(duì)上層透明，業(yè)務(wù)層對(duì)遠(yuǎn)程調(diào)用無(wú)感
● Register注冊(cè)中心層，封裝服務(wù)地址的注冊(cè)與發(fā)現(xiàn)，以服務(wù)的URL位中心
● Cluster路由層（集群容錯(cuò)層），提供了多個(gè)提供者的路由和負(fù)載均衡，并且它橋接注冊(cè)中心以Invoker為中心
● Monitor監(jiān)控層，RPC調(diào)用相關(guān)的信息，如調(diào)用次數(shù)、失敗情況、調(diào)用時(shí)間等統(tǒng)計(jì)信息都會(huì)在這一層完成統(tǒng)計(jì)
● Protocol遠(yuǎn)程調(diào)用層，封裝RPC調(diào)用，無(wú)論是服務(wù)的暴露還是服務(wù)的引用，都是在Protocol中作為主功能入口負(fù)責(zé)Invoker的整個(gè)生命周期，Dubbo中的所有模型都向Invoker靠攏
3、Rmoting層：遠(yuǎn)程數(shù)據(jù)傳輸層
● Exchange信息交換層，封裝請(qǐng)求和響應(yīng)的模式，把請(qǐng)求由同步轉(zhuǎn)為異步
● Transport網(wǎng)絡(luò)傳輸層，統(tǒng)一網(wǎng)絡(luò)傳輸?shù)慕涌?，比如Netty和mina統(tǒng)一為一個(gè)網(wǎng)絡(luò)傳輸接口
● Serialize數(shù)據(jù)序列化層，負(fù)責(zé)管理整個(gè)框架中的數(shù)據(jù)傳輸?shù)男蛄谢头葱蛄谢?/p>

到此這篇關(guān)于Dubbo架構(gòu)整體設(shè)計(jì)詳解的文章就介紹到這了,更多相關(guān)Dubbo架構(gòu)設(shè)計(jì)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論