出處:http://dubbo.apache.org/books/dubbo-dev-book/design.htmlhtml
總體設計

圖例說明:spring
- 圖中左邊淡藍背景的爲服務消費方使用的接口,右邊淡綠色背景的爲服務提供方使用的接口,位於中軸線上的爲雙方都用到的接口。
- 圖中從下至上分爲十層,各層均爲單向依賴,右邊的黑色箭頭表明層之間的依賴關係,每一層均可以剝離上層被複用,其中,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
, Exporter
- 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 實際上不算一層,而是一個獨立的節點,只是爲了全局概覽,用層的方式畫在一塊兒。
模塊分包

模塊說明:apache
- 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 中。
調用鏈
展開總設計圖的紅色調用鏈,以下:負載均衡

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

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

領域模型
在 Dubbo 的核心領域模型中:工具
- Protocol 是服務域,它是 Invoker 暴露和引用的主功能入口,它負責 Invoker 的生命週期管理。
- Invoker 是實體域,它是 Dubbo 的核心模型,其它模型都向它靠擾,或轉換成它,它表明一個可執行體,可向它發起 invoke 調用,它有多是一個本地的實現,也多是一個遠程的實現,也可能一個集羣實現。
- Invocation 是會話域,它持有調用過程當中的變量,好比方法名,參數等。
基本設計原則
- 採用 Microkernel + Plugin 模式,Microkernel 只負責組裝 Plugin,Dubbo 自身的功能也是經過擴展點實現的,也就是 Dubbo 的全部功能點均可被用戶自定義擴展所替換。
- 採用 URL 做爲配置信息的統一格式,全部擴展點都經過傳遞 URL 攜帶配置信息。