簡介

Dubbo是阿里巴巴公司開源的一個高性能優秀的服務框架，使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能，可以和Spring框架無縫集成。它提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動注冊和發現。相信國內用dubbo的互聯網公司還是很多的，springcloud雖然是掛靠在鼎鼎大名的spring團隊下，但是感覺國內使用的公司沒有使用dubbo的多，而且現在dubbo重新啟動維護，加上捐給了apache基金會，以后的發展前途也是一片敞亮，dubbo與springcloud的區別和各自的優缺點可以參看這篇Dubbo和Spring Cloud微服務架構對比，感覺分析的還是挺到位的。總的來說，可以概括為，springcloud涵蓋的微服務概念和組件更廣泛，是一整套的解決方案；而dubbo只是完成了微服務中某些部分的功能，但是兩者也都是各有所長的，具體用哪個框架還是仁者見仁智者見智。

整體設計

既然能夠開源出來，那源代碼一定是有著很深的功力的，不然不是丟臉么，dubbo的整體設計也是深刻貫徹了分層的思想，每一層各司其職。盜用官網的一張圖：

其實剛開始看到這么一張圖的時候，我是一臉懵逼的，這講的啥啊，紅紅藍藍綠綠的，一個完整的方塊愣是被橫一刀豎一刀劃得亂七八糟，還有各種箭頭指向來指向去的。但是對于一個比較復雜的系統或者框架來講，分層是一個重要的概念。這就跟我們搞web應用一樣，為什么要搞ssh，ssm呢？就是要把每一層負責的任務或者功能從整體中抽象出來，然后各自干各自的，這樣自己內部的事情可以內部消化，不對外部的其他層產生影響，整個系統就會變得可維護也易理解。接著來分析這張圖

官網圖例說明：

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

各層說明

• service 服務層：這一層是用戶自己編寫的，不管是服務的接口還是服務的實現。從整體設計圖可以看到，接口是提供方和消費方共同使用的，而實現則只在提供方，并不暴露給消費方。這也與我們平時的使用認知相符，服務提供方將接口單獨打成一個jar包讓消費方使用。

• config 配置層：對外配置接口，以 ServiceConfig, ReferenceConfig 為中心，可以直接初始化配置類，也可以通過 spring 解析配置生成配置類。dubbo-config下面包含了config-api和config-spring兩個子模塊，分別對應了兩種配置生成方式。配置類會包含協議、url等信息，是一個比較重的對象。

• proxy 服務代理層：服務接口透明代理，生成服務的客戶端 Stub 和服務器端 Skeleton, 以 ServiceProxy 為中心，擴展接口為 ProxyFactory。可以看整體設計圖，Invoker其實就是負責調用服務提供方真實服務的一個代理，而Proxy則是在消費方負責調用提供方服務的一個代理。

• registry 注冊中心層：封裝服務地址的注冊與發現，以服務 URL 為中心，擴展接口為 RegistryFactory, Registry, RegistryService。

• cluster 路由層：封裝多個提供者的路由及負載均衡，并橋接注冊中心，以 Invoker 為中心，擴展接口為 Cluster, Directory, Router, LoadBalance。相當于將集群封裝為單個節點，這樣外部就可以像單體調用一樣處理，不需要考慮集群的情況(比如多個提供方的情況)

• monitor 監控層：RPC 調用次數和調用時間監控，以 Statistics 為中心，擴展接口為 MonitorFactory, Monitor, MonitorService。會有一些服務調用信息的統計。

• protocol 遠程調用層：封裝 RPC 調用，以 Invocation, Result 為中心，擴展接口為 Protocol, Invoker, Exporter。對協議的封裝，dubbo支持多種協議，默認是dubbo協議。

• exchange 信息交換層：封裝請求響應模式，同步轉異步，以 Request, Response 為中心，擴展接口為 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer。

• transport 網絡傳輸層：抽象 mina 和 netty 為統一接口，以 Message 為中心，擴展接口為 Channel, Transporter, Client, Server, Codec。

• serialize 數據序列化層：可復用的一些工具，擴展接口為 Serialization, ObjectInput, ObjectOutput, ThreadPool。dubbo的序列化也支持多種協議。

官網關系說明

• 在 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 實際上不算一層，而是一個獨立的節點，只是為了全局概覽，用層的方式畫在一起。

模塊說明

這里官網的模塊說明應該是基于較早的版本，現在dubbo最新的版本是2.7.1，模塊的劃分更細了。

• dubbo-compatible 兼容以前版本的模塊：捐給apache后dubbo的包路徑變了，這個模塊還保留了以前路徑的類，但都不建議使用了。

• dubbo-common 公共邏輯模塊：包括 Util 類和通用模型。

• dubbo-remoting 遠程通訊模塊：相當于 Dubbo 協議的實現，如果 RPC 用 RMI協議則不需要使用此包。

  • dubbo-remoting-api
  • dubbo-remoting-etcd3
  • dubbo-remoting-grizzly
  • dubbo-remoting-http
  • dubbo-remoting-mina
  • dubbo-remoting-netty
  • dubbo-remoting-netty4
  • dubbo-remoting-p2p
  • dubbo-remoting-zookeeper

• dubbo-rpc 遠程調用模塊：抽象各種協議，以及動態代理，只包含一對一的調用，不關心集群的管理。

  • dubbo-rpc-api
  • dubbo-rpc-dubbo
  • dubbo-rpc-hessian
  • dubbo-rpc-http
  • dubbo-rpc-injvm
  • dubbo-rpc-memcached
  • dubbo-rpc-redis
  • dubbo-rpc-rest
  • dubbo-rpc-rmi
  • dubbo-rpc-thrift
  • dubbo-rpc-webservice

• dubbo-cluster 集群模塊：將多個服務提供方偽裝為一個提供方，包括：負載均衡, 容錯，路由等，集群的地址列表可以是靜態配置的，也可以是由注冊中心下發。

• dubbo-registry 注冊中心模塊：基于注冊中心下發地址的集群方式，以及對各種注冊中心的抽象。

  • dubbo-registry-api
  • dubbo-registry-consul
  • dubbo-registry-default
  • dubbo-registry-etcd3
  • dubbo-registry-multicast
  • dubbo-registry-nacos
  • dubbo-registry-redis
  • dubbo-registry-zookeeper

• dubbo-monitor 監控模塊：統計服務調用次數，調用時間的，調用鏈跟蹤的服務。

  • dubbo-monitor-api
  • dubbo-monitor-default

• dubbo-config 配置模塊：是 Dubbo 對外的 API，用戶通過 Config 使用Dubbo，隱藏 Dubbo 所有細節。

  • dubbo-config-api
  • dubbo-config-spring：與spring集成的配置

• dubbo-container 容器模塊：是一個 Standlone 的容器，以簡單的 Main 加載 Spring 啟動，因為服務通常不需要 Tomcat/JBoss 等 Web 容器的特性，沒必要用 Web 容器去加載服務。

  • dubbo-container-api：啟動容器的主模塊
  • dubbo-container-log4j
  • dubbo-container-logback
  • dubbo-container-spring

• dubbo-configcenter 配置中心模塊：dubbo支持多種配置中心

  • dubbo-configcenter-api：相當于不用配置中心，不使用動態配置
  • dubbo-configcenter-etcd：使用Raft算法的分布式KV存儲系統
  • dubbo-configcenter-consul
  • dubbo-configcenter-apollo
  • dubbo-configcenter-zookeeper

• dubbo-filter 過濾器模塊：從整體設計圖可以看到，dubbo服務的調用在提供方和消費方都支持filter

  • dubbo-filter-cache：支持對服務調用返回值的緩存
  • dubbo-filter-validation：校驗器邏輯

• dubbo-metadata-report 元數據上報模塊

  • dubbo-metadata-definition
  • dubbo-metadata-report-api
  • dubbo-metadata-report-consul
  • dubbo-metadata-report-redis
  • dubbo-metadata-report-zookeeper

• dubbo-plugin 插件模塊

  • dubbo-plugin

• dubbo-serialization 序列化模塊

  • dubbo-serialization-api
  • dubbo-serialization-fastjson
  • dubbo-serialization-fst
  • dubbo-serialization-hessian2
  • dubbo-serialization-jdk
  • dubbo-serialization-kryo
  • dubbo-serialization-protostuff

依賴關系

調用鏈

領域模型

在 Dubbo 的核心領域模型中：

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