Dubbo 源碼分析系列之三 —— 架構原理

1 核心功能

首先要了解Dubbo提供的三大核心功能:html

  • Remoting:遠程通信
    • 提供對多種NIO框架抽象封裝,包括「同步轉異步」和「請求-響應」模式的信息交換方式。
  • Cluster: 服務框架
    • 提供基於接口方法的透明遠程過程調用,包括多協議支持,以及軟負載均衡,失敗容錯,地址路由,動態配置等集羣支持。
  • Registry: 服務註冊中心
    • 基於註冊中心目錄服務,使服務消費方能動態的查找服務提供方,使地址透明,使服務提供方能夠平滑增長或減小機器。

2 Dubbo各個組件之間的關係結構

2.1 調用關係

dubbo-architucture

節點角色說明
節點 角色說明
Provider 暴露服務的服務提供方
Consumer 調用遠程服務的服務消費方
Registry 服務註冊與發現的註冊中心
Monitor 統計服務的調用次數和調用時間的監控中心
Container 服務運行容器

2.2 依賴關係

/dev-guide/images/dubbo-relation.jpg

圖例說明:spring

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

調用鏈

展開總設計圖的紅色調用鏈,以下:apache

/dev-guide/images/dubbo-extension.jpg

暴露服務時序

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

/dev-guide/images/dubbo-export.jpg

引用服務時序

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

/dev-guide/images/dubbo-refer.jpg

3 Dubbo 的水平分層結構

Dubbo最大的特色是按照分層的方式來架構,使用這種方式可使各個層之間解耦合(或者最大限度地鬆耦合)。因此,咱們橫向以分層的方式來看下Dubbo的架構架構

總體設計

/dev-guide/images/dubbo-framework.jpg

圖例說明:負載均衡

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

參考文章框架

https://dubbo.incubator.apache.org/zh-cn/docs/dev/design.html異步

http://svip.iocoder.cn/Dubbo/implementation-intro/ide

http://www.javashuo.com/article/p-xcxsqjbv-cb.html

http://www.javashuo.com/article/p-fafgtkek-ga.html

https://my.oschina.net/ywbrj042/blog/702521

相關文章
相關標籤/搜索