1. 程式人生 > >Dubbo基本原理

Dubbo基本原理

版權宣告:本文為博主原創文章,轉載需標明出處哦 ^-^。 https://blog.csdn.net/qq_33101675/article/details/78701305

一、Duboo基本概念解釋

Dubbo是一種分散式服務框架。 Webservice也是一種服務框架,但是webservice並不是分散式的服務框架,他需要結合F5實現負載均衡。因此,dubbo除了可以提供服務之外,還可以實現軟負載均衡。它還提供了兩個功能Monitor 監控中心和呼叫中心。這兩個是可選的,需要單獨配置。

Dubbo的計數架構圖如下:

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

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

服務提供者先啟動start,根據配置檔案解析並轉換後,然後註冊register中心服務(通常是zookeeper單機或者叢集)。

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

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

二、dubbo原理

本篇部落格的內容總體上比較抽象,如果一個想馬上使用dubbo的同學來說,讀這篇部落格效果不太好,本篇部落格沒有寫怎麼使用、配置dubbo,接下來,我再令寫一篇dubbo入門包含demo的部落格。

I、初始化過程細節:
上圖中的第一步start,就是將服務裝載容器中,然後準備註冊服務。和Spring中啟動過程類似,spring啟動時,將bean裝載進容器中的時候,首先要解析bean。所以dubbo也是先讀配置檔案解析服務。
解析服務:
1)、基於dubbo.jar內的Meta-inf/spring.handlers配置,spring在遇到dubbo名稱空間時,會回撥DubboNamespaceHandler類。
2)、所有的dubbo標籤,都統一用DubboBeanDefinitionParser進行解析,基於一對一屬性對映,將XML標籤解析為Bean物件。
原始碼截圖:
在ServiceConfig.export 或者ReferenceConfig.get 初始化時,將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轉為客戶端需要的介面即可。