Dubbo源碼分析(一)-----包結構的分析

Dubbo總體架構圖(來源於http://dubbo.apache.org/books/dubbo-dev-book/design.html)以下：

• 圖中左邊淡藍背景的爲服務消費方使用的接口，右邊淡綠色背景的爲服務提供方使用的接口，位於中軸線上的爲雙方都用到的接口。

• 圖中從下至上分爲十層，各層均爲單向依賴，右邊的黑色箭頭表明層之間的依賴關係，每一層均可以剝離上層被複用，其中，Service 和 Config 層爲 API，其它各層均爲 SPI

• 圖中綠色小塊的爲擴展接口 ,藍色小塊爲實現類，圖中只顯示用於關聯各層的實現類。

• 圖中藍色虛線爲初始化過程,，即啓動時組裝鏈, 紅色實線爲方法調用過程,，即運行時調時鏈，紫色三角箭頭爲繼承，能夠把子類看做父類的同一個節點，線上的文字爲調用的方法。

各層說明：

• Config配置層：對外的配置層，以ServiceConfig、ReferenceConfig爲中心，能夠直接初始化配置類，也能夠經過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、Export,。

• Exchanger 信息交換層，封裝請求響應模式，以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的, 而後在 Invoker 的主過程上 Filter 攔截點

• 圖中的Provider和Consumer是抽象的概念，只是想讓看圖者更直觀的瞭解哪些分類是分屬於客戶端於服務端，不用Client和Server的緣由是Dubbo在不少場景下都使用Provider,Register,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語義。

• Register和Monitor實際上算一層，而是一個獨立的節點，只是爲了全局的概覽，用層的方式畫在一塊兒。

模塊分包 WX20190613-184631@2x.png

模塊說明：

dubbo-common 公共邏輯模塊：包括 Util 類和通用模型。 dubbo-remoting 遠程通信模塊：至關於 Dubbo 協議的實現，若是 RPC 用 RMI協議則不須要使用此包 dubbo-rpc 遠程調用模塊：抽象各類協議，以及動態代理，只包含一對一的調用，不關心集羣的管理。 dubbo-cluster 集羣模塊：將多個服務提供方假裝爲一個提供方，包括：負載均衡, 容錯，路由等，集羣的地址列表能夠是靜態配置的，也能夠是由註冊中心 dubbo-registry 註冊中心模塊：基於註冊中心下發地址的集羣方式，以及對各類註冊中心的抽象。 dubbo-monitor 監控模塊：統計服務調用次數，調用時間的，調用鏈跟蹤的服務。 dubbo-config 配置模塊: 是 Dubbo 對外的 API，用戶經過 Config 使用D ubbo，隱藏 Dubbo 全部細節。 dubbo-container 容器模塊：是一個 Standlone 的容器，以簡單的 Main 加載 Spring 啓動，由於服務一般不須要 Tomcat/JBoss 等 Web 容器的特性，不必用Web 容器去加載服務。總體上按照分層結構進行分包，與分層的不一樣點在於： container 爲服務容器，用於部署運行服務，沒有在層中畫出。 protocol 層和 proxy 層都放在 rpc 模塊中，這兩層是 rpc 的核心，在不須要集羣也就是隻有一個提供者時，能夠只使用這兩層完成 rpc 調用。 transport 層和 exchange 層都放在 remoting 模塊中，爲 rpc 調用的通信基礎。 serialize 層放在 common 模塊中，以便更大程度複用。 依賴關係

圖例說明：

圖中小方塊 Protocol, Cluster, Proxy, Service, Container, Registry, Monitor 表明層或模塊，藍色的表示與業務有交互，綠色的表示只對 Dubbo 內部交互。 圖中背景方塊 Consumer, Provider, Registry, Monitor 表明部署邏輯拓撲節點。 圖中藍色虛線爲初始化時調用，紅色虛線爲運行時異步調用，紅色實線爲運行時同步調用。 圖中只包含 RPC 的層，不包含 Remoting 的層，Remoting 總體都隱含在 Protocol 中。 調用鏈 展開總設計圖的紅色調用鏈，以下：

暴露服務時序

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

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

領域模型

在 Dubbo 的核心領域模型中

Protocol 是服務域，它是 Invoker 暴露和引用的主功能入口，它負責 Invoker 的生命週期管理。 Invoker 是實體域，它是 Dubbo 的核心模型，其它模型都向它靠擾，或轉換成它，它表明一個可執行體，可向它發起 invoke 調用，它有多是一個本地的實現，也多是一個遠程的實現，也可能一個集羣實現。 Invocation 是會話域，它持有調用過程當中的變量，好比方法名，參數等。

基本設計原則 採用 Microkernel + Plugin 模式，Microkernel 只負責組裝 Plugin，Dubbo 自身的功能也是經過擴展點實現的，也就是 Dubbo 的全部功能點均可被用戶自定義擴展所替換。 採用 URL 做爲配置信息的統一格式，全部擴展點都經過傳遞 URL