科技

Dubbo學習(五) dubbo 架構圖 以及呼叫過程

一、Dubbo結構圖

duubo結構圖

我們解釋以下這個架構圖:

Consumer服務消費者,Provider服務提供者。Container服務容器。消費當然是invoke提供者了,invoke這條實線按照圖上的說明當然同步的意思了。但是在實際呼叫過程中,Provider的位置對於Consumer來說是透明的,上一次呼叫服務的位置(IP地址)和下一次呼叫服務的位置,是不確定的。這個地方就需要使用註冊中心來實現軟負載。

Register

服務提供者先啟動start,然後註冊register服務。消費訂閱subscribe服務,如果沒有訂閱到自己想獲得的服務,它會不斷的嘗試訂閱。新的服務註冊到註冊中心以後,註冊中心會將這些服務通過notify到消費者。

Monitor

這是一個監控,圖中虛線表明Consumer 和Provider通過非同步的方式傳送訊息至Monitor,Consumer和Provider會將資訊存放在本地磁碟,平均1min會發送一次資訊。Monitor在整個架構中是可選的(圖中的虛線並不是可選的意思),Monitor功能需要單獨配置,不配置或者配置以後,Monitor掛掉並不會影響服務的呼叫。

二、Dubbo原理

初始化過程細節: 第一步,就是將服務裝載容器中,然後準備註冊服務。和spring中啟動過程類似,spring啟動時,將bean裝載進容器中的時候,首先要解析bean。所以dubbo也是先讀配置檔案解析服務。

解析服務:

1)、基於dubbo.jar內的Meta-inf/spring.handlers配置,spring在遇到dubbo名稱空間時,會回撥DubboNamespaceHandler類。

2)、所有的dubbo標籤,都統一用DubboBeanDefinitionParser進行解析,基於一對一屬性對映,將XML標籤解析為Bean物件。生產者或者消費者初始化的時候,會將Bean物件轉會為url格式,將所有Bean屬性轉成url的引數。 然後將URL傳給Protocol擴充套件點,基於擴充套件點的Adaptive機制,根據URL的協議頭,進行不同協議的服務暴露和引用。

暴露服務:

a、 直接暴露服務埠

在沒有使用註冊中心的情況,這種情況一般適用在開發環境下,服務的呼叫這和提供在同一個IP上,只需要開啟服務的埠即可。 即,當配置 or ServiceConfig解析出的URL的格式為: Dubbo://service-host/com.xxx.TxxService?version=1.0.0 基於擴充套件點的Adaptiver機制,通過URL的“dubbo://”協議頭識別,直接呼叫DubboProtocol的export()方法,開啟服務埠。

b、向註冊中心暴露服務:

和上一種的區別:需要將服務的IP和埠一同暴露給註冊中心。 ServiceConfig解析出的url格式為: registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode(“dubbo://service-host/com.xxx.TxxService?version=1.0.0”)

基於擴充套件點的Adaptive機制,通過URL的“registry://”協議頭識別,呼叫RegistryProtocol的export方法,將export引數中的提供者URL先註冊到註冊中心,再重新傳給Protocol擴充套件點進行暴露: Dubbo://service-host/com.xxx.TxxService?version=1.0.0

引用服務:

a、直接引用服務:

在沒有註冊中心的,直連提供者情況下, ReferenceConfig解析出的URL格式為: Dubbo://service-host/com.xxx.TxxService?version=1.0.0

基於擴充套件點的Adaptive機制,通過url的“dubbo://”協議頭識別,直接呼叫DubboProtocol的refer方法,返回提供者引用。

b、從註冊中心發現引用服務:

此時,ReferenceConfig解析出的URL的格式為: registry://registry-host/com.alibaba.dubbo.registry.RegistryService?refer=URL.encode(“consumer://consumer-host/com.foo.FooService?version=1.0.0”)

基於擴充套件點的Apaptive機制,通過URL的“registry://”協議頭識別,就會呼叫RegistryProtocol的refer方法,基於refer引數總的條件,查詢提供者URL,如: Dubbo://service-host/com.xxx.TxxService?version=1.0.0

基於擴充套件點的Adaptive機制,通過提供者URL的“dubbo://”協議頭識別,就會呼叫DubboProtocol的refer()方法,得到提供者引用。 然後RegistryProtocol將多個提供者引用,通過Cluster擴充套件點,偽裝成單個提供這引用返回。

三、服務提供與消費詳細過程

服務提供者暴露一個服務的詳細過程

暴露服務的主過程:

首先ServiceConfig類拿到對外提供服務的實際類ref,然後將ProxyFactory類的getInvoker方法使用ref生成一個AbstractProxyInvoker例項,到這一步就完成具體服務到invoker的轉化。接下來就是Invoker轉換到Exporter的過程。 Dubbo處理服務暴露的關鍵就在Invoker轉換到Exporter的過程,下面我們以Dubbo和rmi這兩種典型協議的實現來進行說明: Dubbo的實現: Dubbo協議的Invoker轉為Exporter發生在DubboProtocol類的export方法,它主要是開啟socket偵聽服務,並接收客戶端發來的各種請求,通訊細節由dubbo自己實現。 Rmi的實現: RMI協議的Invoker轉為Exporter發生在RmiProtocol類的export方法,他通過Spring或Dubbo或JDK來實現服務,通訊細節由JDK底層來實現。

服務消費的主過程

服務消費的主過程:

首先ReferenceConfig類的init方法呼叫Protocol的refer方法生成Invoker例項。接下來把Invoker轉為客戶端需要的介面

分散式服務框架:

–高效能和透明化的RPC遠端服務呼叫方案

–SOA服務治理方案

-Apache MINA 框架基於Reactor模型通訊框架,基於tcp長連線

Dubbo預設協議採用單一長連線和NIO非同步通訊,

適合於小資料量大併發的服務呼叫,以及服務消費者機器數遠大於服務提供者機器數的情況

分析原始碼,基本原理如下:

client一個執行緒呼叫遠端介面,生成一個唯一的ID(比如一段隨機字串,UUID等),Dubbo是使用AtomicLong從0開始累計數字的將打包的方法呼叫資訊(如呼叫的介面名稱,方法名稱,引數值列表等),和處理結果的回撥物件callback,全部封裝在一起,組成一個物件object向專門存放呼叫資訊的全域性ConcurrentHashMap裡面put(ID, object)將ID和打包的方法呼叫資訊封裝成一物件connRequest,使用IoSession.write(connRequest)非同步傳送出去當前執行緒再使用callback的get()方法試圖獲取遠端返回的結果,在get()內部,則使用synchronized獲取回撥物件callback的鎖, 再先檢測是否已經獲取到結果,如果沒有,然後呼叫callback的wait()方法,釋放callback上的鎖,讓當前執行緒處於等待狀態。服務端接收到請求並處理後,將結果(此結果中包含了前面的ID,即回傳)傳送給客戶端,客戶端socket連線上專門監聽訊息的執行緒收到訊息,分析結果,取到ID,再從前面的ConcurrentHashMap裡面get(ID),從而找到callback,將方法呼叫結果設定到callback物件裡。監聽執行緒接著使用synchronized獲取回撥物件callback的鎖(因為前面呼叫過wait(),那個執行緒已釋放callback的鎖了),再notifyAll(),喚醒前面處於等待狀態的執行緒繼續執行(callback的get()方法繼續執行就能拿到呼叫結果了),至此,整個過程結束。當前執行緒怎麼讓它“暫停”,等結果回來後,再向後執行? 答:先生成一個物件obj,在一個全域性map裡put(ID,obj)存放起來,再用synchronized獲取obj鎖,再呼叫obj.wait()讓當前執行緒處於等待狀態,然後另一訊息監聽執行緒等到服 務端結果來了後,再map.get(ID)找到obj,再用synchronized獲取obj鎖,再呼叫obj.notifyAll()喚醒前面處於等待狀態的執行緒。

正如前面所說,Socket通訊是一個全雙工的方式,如果有多個執行緒同時進行遠端方法呼叫,這時建立在client server之間的socket連線上會有很多雙方傳送的訊息傳遞,前後順序也可能是亂七八糟的,server處理完結果後,將結果訊息傳送給client,client收到很多訊息,怎麼知道哪個訊息結果是原先哪個執行緒呼叫的? 答:使用一個ID,讓其唯一,然後傳遞給服務端,再服務端又回傳回來,這樣就知道結果是原先哪個執行緒的了。

總體架構

Dubbo的總體架構,如圖所示:

Dubbo框架設計一共劃分了10個層,最上面的Service層是留給實際想要使用Dubbo開發分散式服務的開發者實現業務邏輯的介面層。圖中左邊淡藍背景的為服務消費方使用的介面,右邊淡綠色背景的為服務提供方使用的介面, 位於中軸線上的為雙方都用到的介面。

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

服務介面層(Service):該層是與實際業務邏輯相關的,根據服務提供方和服務消費方的業務設計對應的介面和實現。配置層(Config):對外配置介面,以ServiceConfig和ReferenceConfig為中心,可以直接new配置類,也可以通過spring解析配置生成配置類。服務代理層(Proxy):服務介面透明代理,生成服務的客戶端Stub和伺服器端Skeleton,以ServiceProxy為中心,擴充套件介面為ProxyFactory。服務註冊層(Registry):封裝服務地址的註冊與發現,以服務URL為中心,擴充套件介面為RegistryFactory、Registry和RegistryService。可能沒有服務註冊中心,此時服務提供方直接暴露服務。叢集層(Cluster):封裝多個提供者的路由及負載均衡,並橋接註冊中心,以Invoker為中心,擴充套件介面為Cluster、Directory、Router和LoadBalance。將多個服務提供方組合為一個服務提供方,實現對服務消費方來透明,只需要與一個服務提供方進行互動。監控層(Monitor):RPC呼叫次數和呼叫時間監控,以Statistics為中心,擴充套件介面為MonitorFactory、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。根據官方提供的,對於上述各層之間關係的描述,如下所示:

在RPC中,Protocol是核心層,也就是隻要有Protocol + Invoker + Exporter就可以完成非透明的RPC呼叫,然後在Invoker的主過程上Filter攔截點。圖中的Consumer和Provider是抽象概念,只是想讓看圖者更直觀的瞭解哪些類分屬於客戶端與伺服器端,不用Client和Server的原因是Dubbo在很多場景下都使用Provider、Consumer、Registry、Monitor劃分邏輯拓普節點,保持統一概念。而Cluster是外圍概念,所以Cluster的目的是將多個Invoker偽裝成一個Invoker,這樣其它人只要關注Protocol層Invoker即可,加上Cluster或者去掉Cluster對其它層都不會造成影響,因為只有一個提供者時,是不需要Cluster的。Proxy層封裝了所有介面的透明化代理,而在其它層都以Invoker為中心,只有到了暴露給使用者使用時,才用Proxy將Invoker轉成介面,或將介面實現轉成Invoker,也就是去掉Proxy層RPC是可以Run的,只是不那麼透明,不那麼看起來像調本地服務一樣調遠端服務。而Remoting實現是Dubbo協議的實現,如果你選擇RMI協議,整個Remoting都不會用上,Remoting內部再劃為Transport傳輸層和Exchange資訊交換層,Transport層只負責單向訊息傳輸,是對Mina、Netty、Grizzly的抽象,它也可以擴充套件UDP傳輸,而Exchange層是在傳輸層之上封裝了Request-Response語義。Registry和Monitor實際上不算一層,而是一個獨立的節點,只是為了全域性概覽,用層的方式畫在一起。Dubbo作為一個分散式服務框架,主要具有如下幾個核心的要點:

服務定義

服務是圍繞服務提供方和服務消費方的,服務提供方實現服務,而服務消費方呼叫服務。

服務註冊

服務提供方,它需要釋出服務,而且由於應用系統的複雜性,服務的數量、型別也不斷膨脹;對於服務消費方,它最關心如何獲取到它所需要的服務,而面對複雜的應用系統,需要管理大量的服務呼叫。而且,對於服務提供方和服務消費方來說,他們還有可能兼具這兩種角色,即既需要提供服務,有需要消費服務。

通過將服務統一管理起來,可以有效地優化內部應用對服務釋出/使用的流程和管理。服務註冊中心可以通過特定協議來完成服務對外的統一。Dubbo提供的註冊中心有如下幾種型別可供選擇:

Multicast註冊中心Zookeeper註冊中心Redis註冊中心Simple註冊中心服務監控

服務提供方,還是服務消費方,他們都需要對服務呼叫的實際狀態進行有效的監控,從而改進服務質量。

遠端通訊與資訊交換

遠端通訊需要指定通訊雙方所約定的協議,在保證通訊雙方理解協議語義的基礎上,還要保證高效、穩定的訊息傳輸。Dubbo繼承了當前主流的網路通訊框架,主要包括如下幾個:

MinaNettyGrizzly服務呼叫

下面從Dubbo官網直接拿來,看一下基於RPC層,服務提供方和服務消費方之間的呼叫關係,如圖所示:

節點角色說明:

Provider: 暴露服務的服務提供方。Consumer: 呼叫遠端服務的服務消費方。Registry: 服務註冊與發現的註冊中心。Monitor: 統計服務的呼叫次調和呼叫時間的監控中心。Container: 服務執行容器。上圖中,藍色的表示與業務有互動,綠色的表示只對Dubbo內部互動。上述圖所描述的呼叫流程如下:

服務容器負責啟動,載入,執行服務提供者。服務提供者在啟動時,向註冊中心註冊自己提供的服務。服務消費者在啟動時,向註冊中心訂閱自己所需的服務。註冊中心返回服務提供者地址列表給消費者,如果有變更,註冊中心將基於長連線推送變更資料給消費者。服務消費者,從提供者地址列表中,基於軟負載均衡演算法,選一臺提供者進行呼叫,如果呼叫失敗,再選另一臺呼叫。服務消費者和提供者,在記憶體中累計呼叫次數和呼叫時間,定時每分鐘傳送一次統計資料到監控中心。接著,將上面抽象的呼叫流程圖展開,詳細如圖所示:

註冊/登出服務

服務的註冊與登出,是對服務提供方角色而言,那麼註冊服務與登出服務的時序圖,如圖所示:

服務訂閱/取消

為了滿足應用系統的需求,服務消費方的可能需要從服務註冊中心訂閱指定的有服務提供方釋出的服務,在得到通知可以使用服務時,就可以直接呼叫服務。反過來,如果不需要某一個服務了,可以取消該服務。

Dubbo的模組組成

Dubbo以包結構來組織各個模組,各個模組及其關係,如圖所示:

可以通過Dubbo的程式碼(使用Maven管理)組織,與上面的模組進行比較。簡單說明各個包的情況:

dubbo-common 公共邏輯模組,包括Util類和通用模型。dubbo-remoting 遠端通訊模組,相當於Dubbo協議的實現,如果RPC用RMI協議則不需要使用此包。dubbo-rpc 遠端呼叫模組,抽象各種協議,以及動態代理,只包含一對一的呼叫,不關心叢集的管理。dubbo-cluster 叢集模組,將多個服務提供方偽裝為一個提供方,包括:負載均衡、容錯、路由等,叢集的地址列表可以是靜態配置的,也可以是由註冊中心下發。dubbo-registry 註冊中心模組,基於註冊中心下發地址的叢集方式,以及對各種註冊中心的抽象。dubbo-monitor 監控模組,統計服務呼叫次數,呼叫時間的,呼叫鏈跟蹤的服務。dubbo-config 配置模組,是Dubbo對外的API,使用者通過Config使用Dubbo,隱藏Dubbo所有細節。dubbo-container 容器模組,是一個Standalone的容器,以簡單的Main載入Spring啟動,因為服務通常不需要Tomcat/JBoss等Web容器的特性,沒必要用Web容器去載入服務。 本文轉自於部落格園aspirant的部落格

上一篇:Dubbo學習(四) Dubbo 從下載到編譯成功

Reference:科技日報

看更多!請加入我們的粉絲團

轉載請附文章網址

不可錯過的話題