一. Dubbo 架構
Dubbo 是阿里服務化治理方案的核心框架，是一種分佈式 RPC 框架，它提供了註冊中心機制，解耦了消費方與服務方動態發現的問題。
1.1 Dubbo 架構
Dubbo 的架構主要分爲四部分：服務提供方、服務消費者、註冊中心、統計中心，這四部分也被稱爲部署邏輯拓撲節點。Dubbo 運作模式如下：
- 註冊：服務提供方 (Provider) 啓動時，把自己的元數據向註冊中心 (Registry) 上面註冊；
- 訂閱：服務消費者 (Consumer)啓動時，從註冊中心 (Registry) 訂閱服務提供方的元數據；
- 通知：註冊中心的數據發生變更，變更的數據會推送給訂閱的服務消費者；
- 調用：獲取服務提供方的元數據後，消費者可以發起 RPC 調用；
- 監控：RPC 調用發生前後，會向監控中心 (Monitor) 上報統計信息；
![Dubbo架構]()
Dubbo 的架構如上圖所示，上圖圖例說明：
- 圖中小方塊 Protocol, Cluster, Proxy, Service, Container, Registry, Monitor 代表層或模塊，藍色的表示與業務有交互，綠色的表示只對 Dubbo 內部交互；
- 圖中背景方塊 Consumer, Provider, Registry, Monitor 代表 Dubbo 架構的四個部分；
- 圖中**藍色虛線**爲初始化時調用，紅色虛線爲運行時異步調用，紅色實線爲運行時同步調用；
- 注：圖中只包含 RPC 的層，不包含 Remoting 的層，Remoting 整體都隱含在 Protocol 中；關於分層見下一節的圖示。
1.2 Dubbo 分層
上圖爲 Dubbo 的分層結構。橫向將其分爲兩部分，左邊淡藍色背景是消費者使用的接口，右邊淡綠色背景是提供者使用的接口，位於兩者中軸線上的是消費者與提供者共同使用的接口。
縱向可以將 Dubbo 分爲十層。如果按照總體功能，可以想左側的分類一樣，將 Dubbo 分爲三層：
- 業務層 (Business)：Business
- RPC 層：Config, Proxy, Registry, Cluster, Monitor, Protocol
- 遠程調用層 (Remote)：Exchange, Transport, Serialize
如果按照調用方的角度：
- API 層：Service, Config，供用戶調用；
- SPI 層：除 API 層其他所有層，這些層全部可擴展的主要提供給擴展者使用，這也是 Dubbo 擴展能力強的原因。
各層及各層的核心組件如下：
| 層次名 | 作用 |
|---|---|
| 業務層 (Service) | 業務代碼的接口與實現，即開發者實現的業務代碼 |
| 配置層 (Config) | 對外配置接口，以用來暴露服務配置的 ServiceConfig 與引用的服務配置 ReferenceConfig 爲中心 |
| 服務代理層 (Proxy) | 無論是服務提供者還是消費者，Dubbo 框架都會生成一個代理類，整個過程對上面是透明的，調用遠程接口就像調用本地方法一樣。核心爲 ServiceProxy |
| 註冊層 (Registry) | 負責 Dubbo 框架的服務註冊與發現。集羣中有服務上下線時，註冊中心通知訂閱該服務的訂閱方相應的動作 |
| 集羣容錯層 (Cluster) | 又稱路由層，負責遠程調用失敗的容錯策略，以及選擇調用節點的負載均衡策略 |
| 監控層 (Monitor) | 監控 RPC 調用次數、調用時間 |
| 遠程調用層 (Protocol) | 封裝 RPC 調用的具體過程。Dubbo 以 Invoker 爲核心模型，框架中其他所有模型向它靠攏，可以是一個本地、遠程、或者集羣的實現 |
| 信息交換層 (Exchange) | 封裝請求響應模式 |
| 網絡傳輸層 (Transport) | 把網絡傳輸抽象成統一的接口，以 Mina, Netty 爲統一接口，以 Message 爲中心 |
| 序列化層 (Serialize) | 負責管理整個框架網絡傳輸時的序列化、反序列化工作 |
1.3 Dubbo 架構關係
首先在 Dubbo 架構圖中的服務提供者 (Provider) 與服務消費者 (Consumer) 都是抽象的、相對性的概念，類似於我們平常說的服務器、客戶端結構。這樣的概念主要是爲了讓讀者更加直觀的瞭解哪些類屬於客戶端與服務端。
在 RPC 層中，Protocol 是核心層。只要有 Protocol + Invoker + Exporter，就可以完成非透明的 RPC 遠程調用。
在遠程調用層 Remote 中，基本是 Dubbo 協議的實現。Remote 層內部再劃分爲傳輸層 Transport 與信息交換層 Exchange，傳輸層只負責消息的單向傳輸，是對不同協議 Mina, Netty, Grizzly 的抽象，同時也可以擴展接口；而Exchange 層在 Transport 層之上封裝了請求-響應的模型。