DUBBO架構設計

2021-08-31 07:37:59 字數 2231 閱讀 3318

筆者本次分享主要涉及三方面:

dubbo架構設計

dubbo admin原理

dubbo monitor原理

dubbo是alibaba開源的分布式服務框架,它最大的特點是按照分層的方式來架構,使用這種方式可以使各個層之間解耦合(或者最大限度地鬆耦合)。從服務模型的角度來看,dubbo採用的是一種非常簡單的模型,要麼是提供方提供服務,要麼是消費方消費服務,所以基於這一點可以抽象出服務提供方(provider)和服務消費方(consumer)兩個角色。關於註冊中心、協議支援、服務監控等內容,詳見後面描述。

節點角色說明

provider

暴漏服務的服務提供方

consumer

呼叫遠端服務的服務消費方

registry

服務註冊與發現的註冊中心

monitor

統計服務的呼叫次數和呼叫時間的監控中心

container

服務執行的容器

dubbo作為乙個分布式服務框架,主要具有如下幾個核心的要點:

dubbo的分層架構,如圖所示:圖中左邊淡藍背景的為服務消費方使用的介面,右邊淡綠色背景的為服務提供方使用的介面, 位於中軸線上的為雙方都用到的介面

dubbo框架設計一共劃分了10個層,而最上面的service層是留給實際想要使用dubbo開發分布式服務的開發者實現業務邏輯的介面層。

下面,結合dubbo官方文件,我們分別理解一下框架分層架構中,各個層次的設計要點:

配置層(config):對外配置介面,以serviceconfig和referenceconfig為中心,可以直接new配置類,也可以通過spring解析配置生成配置類。

服務**層(proxy):服務介面透明**,分為服務的客戶端**和伺服器端**,以serviceproxy為中心,擴充套件介面為proxyfactory。

服務註冊層(registry):封裝服務位址的註冊與發現,以服務url為中心,擴充套件介面為registryfactory、registry和registryservice。可能沒有服務註冊中心,此時服務提供方直接暴露服務。

集群層(cluster):封裝多個提供者的路由及負載均衡,並橋接註冊中心,以invoker為中心,擴充套件介面為cluster、directory、router和loadbalance。將多個服務提供方組合為乙個服務提供方,實現對服務消費方來透明,只需要與乙個服務提供方進行互動。

監控層(monitor):rpc呼叫次數和呼叫時間監控,以statistics為中心,擴充套件介面為monito***ctory、monitor和monitorservice。

遠端呼叫層(protocol):封裝rpc呼叫,以invocation和result為中心,擴充套件介面為protocol、invoker和exporter。protocol是服務域,它是invoker暴露和引用的主功能入口,它負責invoker的生命週期管理。invoker是實體域,它是dubbo的核心模型,其它模型都向它靠擾,或轉換成它,它代表乙個可執行體,可向它發起invoke呼叫,它有可能是乙個本地的實現,也可能是乙個遠端的實現,也可能乙個集群實現。

資訊交換層(exchange):封裝請求響應模式,同步轉非同步,以request和response為中心,擴充套件介面為exchanger、exchangechannel、exchangeclient和exchangeserver。

網路傳輸層(transport):抽象mina和netty為統一介面,以message為中心,擴充套件介面為channel、transporter、client、server和codec。

資料序列化層(serialize):可復用的一些工具,擴充套件介面為serialization、 objectinput、objectoutput和threadpool。

根據官方提供的,對於上述各層之間關係的描述,如下所示:

接著,將上面抽象的呼叫流程圖展開,詳細如圖所示:

圖中下面淡藍背景的為服務消費方使用的介面,上面淡綠色背景的為服務提供方使用的介面, 位於中軸線上的為雙方都用到的介面

其實dubbo admin就是registryservice的消費者,即註冊中心的消費者。註冊中心提供的服務:

另外,實現了notifylistener介面,watch zk的服務目錄資訊變化,即時更新本地快取的服務資訊

dubbo-******-monitor是monitor service的提供者

客戶端產生第一條請求時,會觸發monitorfilter中monitor service服務的訂閱,然後該服務的消費者例項會快取下來。該消費者一分鐘會上報一次資料(全都是非同步的過程,所以不會影響正常的服務呼叫)

dubbo原始碼解析 集群容錯架構設計

本來是想把整個dubbo原始碼解析一次性弄完,再做成乙個系列來發布的,但是正巧最近有位好朋友要去杭州面試,就和我交流了一下.本著對dubbo原始碼略有心得的心態,在交流過程中也發表了個人的一些粗劣的拙見.但是非常不幸的是,交流過程中我這位朋友問到了幾個問題,我卻沒能回答得上,讓我感到十分慚愧.故而將...

salesforce 架構設計 從架構設計到架構師

因為碎片化的時間多了,所以開始刷起某乎了,關注了架構相關的板塊,也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段,對於做架構沒有相對具象的一些理解,更沒有系統化的認識。所以把最近回答的一些內容整理一下,權當記錄,留給3年後的自己 按慣例,容許我裝x開頭 一 架構的定義 在軟體開發...

mysql架構設計 初識mysql架構設計

一 應用系統如何與mysql進行一次互動?最開始接觸jdbc的時候,我們系統如何完成一次sql操作呢?第一步,建立資料庫連線 第二步,操作sql 第三步,釋放連線。但是每次建立與資料庫的連線非常耗時和資源,所以我們加入了連線池的概念。第一步的獲取連線是從連線池中獲取乙個可用的連線,第三步的釋放連線不...