Dubbo框架設計——摘自Dubbo官方文檔

框架設計

概念

       Dubbo是一種分佈式框架，致力於提供性能和透明的RPC遠程服務調用方案，以及SOA服務治理方案。

整體設計：

 

Dubbo拓撲結構

名詞解釋

1、Registry：註冊中心，一般是使用Zookeeper作爲註冊中心。用於服務的註冊與發現。

2、Provider：暴露服務的服務提供方，會將服務註冊到Registry註冊中心。

3、Consumer：消費者，調用遠程服務的一方，Registry會向消費者發送提醒，提醒已經註冊的服務，Consumer負責詢問，一旦有服務可用，會向Provider通過RPC的方式調用（invoke）Provider的服務。

4、Monitor，監控中心，統計服務的調用次數和調用時間。

5、Scheduler調度器，基於訪問壓力自增減服務提供者

6、Container服務運行容器

 

調用關係說明：

1. 服務容器負責啓動、加載、運行服務提供者；
2. 服務提供者在啓動時，向註冊中心註冊自己的服務；
3. 服務消費者在啓動時，向註冊中心訂閱自己所需要的服務；
4. 註冊中心返回服務提供者地址列表給服務消費者，如有變更，註冊中心將基於長連接推送變更數據給消費者。
5. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
6. 服務消費者和服務提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

 

 

特性一覽：

1. 面向接口代理的高性能RPC調用

提供高性能的基於代理的遠程調用能力，服務以接口爲粒度，爲開發者屏蔽遠程調用的底層細節。

2、服務自動註冊與發現

提供多種服務註冊中心機制，服務上下線實時感知。

3、運行期流量調度

內置條件、腳本等路由策略，通過配置不同的路由規則，輕鬆實現灰度發佈，同機房優先等功能。

4、智能負載均衡

內置多種負載均衡策略，智能感知下游節點健康狀況，顯著減少調用延遲，提高系統吞吐量。

5、高度可擴展能力

遵循微內核加插件設計的原則，所有核心能力如Protocol、Transport、Serialization被設計擴展點，平等對待內置實現和第三方實現。

6、可視化服務治理與運維

提供豐富治理與運維工具：隨時查詢服務元數據、服務健康狀態以及調用統計、實施下發路由策略、調整配置參數。

 

整體設計：

 

圖例說明：

1. 圖中的藍色背景爲服務消費者方使用的接口，右邊淡綠色背景的爲服務提供方使用的接口，位於中軸線上的爲雙方都用到的接口。
2. 圖中從上至下分爲十層，各層均爲單向依賴，右邊的黑色箭頭代表層之間的依賴關係，每一層都可以剝離上層被複用，其中Service層和Config層爲API。其他各層爲SPI（串行外設接口）。
3. 圖中綠色小塊的爲擴展接口，藍色小塊爲實現類，圖中只顯示用於聯絡各層的實現類。
4. 圖中藍色虛線爲初始化過程，即啓動時組裝鏈，紅色實現爲方法調用過程，即運行時調用鏈，紫色三角箭頭爲繼承，可以把子類看作父類的同一個節點，線上的文字爲調用的方法。

 

各層說明

1. config配置層：對外設置接口，以ServiceConfig、ReferenceConfig爲中心，可以直接初始化配置類，也可以通過spring解析服務配置生成配置類。
2. proxy服務代理層：服務接口透明代理，生成服務的客戶端stub和服務端Skeleton，以ServiceProxy爲中心，擴展接口爲ProxyFactory。
3. cluster路由層：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker爲中心，擴展接口爲Cluster、Directory、Router、LoadBalance
4. monitor監控層：RPC調用次數和調用時間監控，以Statistics爲中心，擴展接口爲MonitorFactory、Monitor、MonitorService。
5. protocol遠程調用層：封裝RPC調用，以Invocation、Result爲中心，擴展接口爲Protocol、Invoker、Exporter
6. exchange信息交換層：封裝請求響應模式，同步轉異步，以Request、Response爲中心，擴展接口爲Exchange、ExchangeChannel、ExchangeClient、ExchangeServer
7. transport網絡傳輸層：抽象Mina和Netty爲統一接口，以Message爲中心，擴展爲Channel 、Transport、Client、Server、Codec
8. serialize數據序列化層：可複用一些工具，擴展接口爲Serialization，ObjectInput、ObjectOutput、ThreadPool

 

關係說明

1. 在RPC中，Protocol是核心層，也就是只要有Protocol+Invoker+Export就可以完成非透明的RPC調用，然後在Invoker的主過程上Filter攔截點。
2. 圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的瞭解哪些分類分屬於客戶端與服務器端，不用Client和Server的原因是Dubbo在很多場景下都使用Provider、Consumer、Registry、Monitor劃分邏輯拓撲節點，保持概念統一。
3. 而Cluster是外圍概念，所以Cluster的目的是將多個Invoker僞裝成一個Invoker，這樣其他人只要關注Protocol層Invoker即可，加上Cluster或者去掉Cluster對其他曾都不會造成影響，因爲只有一個提供者時，是不需要Cluster的。
4. Proxy層封裝了所有接口的透明代理，而在其它層都以Invoker爲中心，只有到了暴露給用戶使用時，才用Proxy將所有Invoker轉成接口，或將接口實現轉成Invoker，也就是去掉Proxy層RPC是可以RUN的，只是不那麼透明，不那麼看起來像調用本地服務一樣調用遠程服務。
5. 而Remoting實現是Dubbo協議的實現，如果你選擇RMI協議，整個Remoting都不會用上，Remoting內部再劃分爲Transport傳輸層和Exchange信息交換層，Transport層只負責單向消息傳輸，是對Mina、Netty、Grizzly的抽象，它可以擴展UDP傳輸，而Exchange層是在傳輸層之上封裝了Request-Response語義。
6. Registry和Monitor實際上不算一層，而是一個獨立的節點，只是爲了全局概覽，用層的方式畫在一起。

 

模塊分包

模塊說明：

1. dubbo-common公共邏輯模塊：包括Util類和通用模型
2. dubbo-remoting遠程通訊模塊：相當於Dubbo協議的實現，如果RPC用RMI協議則不需要使用此包；
3. dubbo-rpc遠程調用模塊：抽象各種協議，以及動態代理，只包含一對一的調用，不關心集羣管理。
4. dubbo-cluster集羣模塊：將多個服務提供方僞裝爲一個提供方，包括負載均衡，容錯。路由等。集羣的地址可以是靜態配置的，也可由註冊中心下發；
5. dubbo-registry註冊中心模塊：基於註冊中心下發地址的集羣方式，以及對各種註冊中心的抽象；
6. dubbo-monitor監控模塊：統計服務調用次數，調用時間的，調用鏈跟蹤的服務。
7. dubbo-config配置模塊：是Dubbo對外的API，用戶通過Config使用Dubbo，隱藏Dubbo所有細節。
8. dubbo-container容器模塊：是一個Standlone的容器，以簡單的Main加載Spring啓動，因爲服務通常不需要Tomcat/Jboss等Web容器的特性，沒必要用Web容器去加載服務。

 

整體上按照分層結構進行分包，與分層的不同點在於：

1. container爲服務容器，用於部署運行服務，沒有在層中劃出；
2. protocol層和proxy層都是放在rpc模塊中，這兩層是rpc的核心，在不需要集羣也就是隻有一個提供者時，可以只使用這兩層完成rpc調用。
3. transport層和exchange層 都放在Remoting模塊中，爲rpc調用的通訊基礎；
4. serialize層放在common模塊中，以便更大程度複用。  

 

依賴關係

圖例說明：

1. 圖中小方塊Protocol、Cluster、Proxy、Service、Container、Registry、Monitor代表層或模塊，藍色的表示與業務有交互，綠色的表示只對Dubbo內部交互。
2. 圖中背景方塊Consumer、Provider、Registry、Monitor代表部署邏輯拓撲節點；
3. 圖中藍色虛線爲初始化時調用，紅色虛線爲運行時異步調用，紅色實現爲運行時同步調用。
4. 圖中只包含RPC的層，不包含Remoting 的層，Remoting整體都隱含在Protocol中。

 

調用鏈

展開總設計圖的紅色調用鏈

 

 

暴露服務時序

展開總設計圖左邊服務提供方暴露服務的藍色初始化鏈，時序圖如下：

引用服務時序

展開總設計圖右邊服務消費方引用服務的藍色初始化鏈，時序圖如下：

領域模型

在Dubbo的核心領域模型中：

1. Protocol是服務域，它是Invoker暴露和引用的主要功能入口，它負責Invoker的生命週期管理。
2. Invoker是實體域，它是Dubbo的核心模型，其他模型都向它靠攏，或轉換它，它代表一個可執行體，可向它發起Invoker調用，它可能是一個本地的實現，也可能是一個遠程實現，也可能是一個集羣實現。
3. Invoker是會話域，他持有調用過程中的變量，比如方法名、參數等；

 

基本設計原則

1. 採用Microkernel+Plugin模式，Microkernel只負責組裝Plugin，Dubbo自身的功能也是通過擴展點實現的，也就是Dubbo的所有功能點都可以被用戶自定義擴展所替換。
2. 採用URL作爲配置信息的統一格式，所有擴展都可以通過傳遞URL攜帶配置信息。

官方文檔：

https://dubbo.apache.org/zh-cn/docs/user/quick-start.html