Dubbo 詳解

Dubbo 分層

Dubbo 是一款高性能 Java RPC 架構。它實現了面向接口代理的 RPC 調用，服務註冊和發現，負載均衡，容錯，擴展性等等功能。

Dubbo 大致上分爲三層，分別是：

• 業務層

• RPC 層

• Remoting 層

Dubbo 的三層結構

 

從上圖中可以看到，三層結構中包含了 Dubbo 的核心組件。他們的基本功能如下，對於比較常用的組件，會在後面的篇幅中詳細講解。

組件功能列表

 

這裏將這些組件羅列出來，能有一個感性的認識。具體開發的時候，知道運用哪些組件。

 

Dubbo 調用工作流

 

Dubbo 框架是用來處理分佈式系統中，服務發現與註冊以及調用問題的，並且管理調用過程。

上面介紹了 Dubbo 的框架分層，下圖的工作流就展示了他們是如何工作的。

Dubbo 服務調用流程圖

 

工作流涉及到服務提供者（Provider），註冊中心（Registration），網絡（Network）和服務消費者（Consumer）：

• 服務提供者在啓動的時候，會通過讀取一些配置將服務實例化。

• Proxy 封裝服務調用接口，方便調用者調用。客戶端獲取 Proxy 時，可以像調用本地服務一樣，調用遠程服務。

• Proxy 在封裝時，需要調用 Protocol 定義協議格式，例如：Dubbo Protocol。

• 將 Proxy 封裝成 Invoker，它是真實服務調用的實例。

• 將 Invoker 轉化成 Exporter，Exporter 只是把 Invoker 包裝了一層，是爲了在註冊中心中暴露自己，方便消費者使用。

• 將包裝好的 Exporter 註冊到註冊中心。

• 服務消費者建立好實例，會到服務註冊中心訂閱服務提供者的元數據。元數據包括服務 IP 和端口以及調用方式（Proxy）。

• 消費者會通過獲取的 Proxy 進行調用。通過服務提供方包裝過程可以知道，Proxy 實際包裝了 Invoker 實體，因此需要使用 Invoker 進行調用

• 在 Invoker 調用之前，通過 Directory 獲取服務提供者的 Invoker 列表。在分佈式的服務中有可能出現同一個服務，分佈在不同的節點上。

• 通過路由規則瞭解，服務需要從哪些節點獲取。

• Invoker 調用過程中，通過 Cluster 進行容錯，如果遇到失敗策略進行重試。

• 調用中，由於多個服務可能會分佈到不同的節點，就要通過 LoadBalance 來實現負載均衡。

• Invoker 調用之前還需要經過 Filter，它是一個過濾鏈，用來處理上下文，限流和計數的工作。

• 生成過濾以後的 Invoker。

• 用 Client 進行數據傳輸。

• Codec 會根據 Protocol 定義的協議，進行協議的構造。

• 構造完成的數據，通過序列化 Serialization 傳輸給服務提供者。

• Request 已經到達了服務提供者，它會被分配到線程池（ThreadPool）中進行處理。

• Server 拿到請求以後查找對應的 Exporter（包含有 Invoker）。

• 由於 Export 也會被 Filter 層層包裹

• 通過 Filter 以後獲得 Invoker

• 最後，對服務提供者實體進行調用。

 

上面調用步驟經歷了這麼多過程，其中出現了 Proxy，Invoker，Exporter，Filter。

 

實際上都是調用實體在不同階段的不同表現形式，本質是一樣的，在不同的使用場景使用不同的實體。

 

例如 Proxy 是用來方便調用者調用的。Invoker 是在調用具體實體時使用的。Exporter 用來註冊到註冊中心的等等。

 

後面我們會對具體流程進行解析。如果時間不夠無法閱讀完全文，可以把上面的圖保存。

 

服務暴露實現原理

 

上面講到的服務調用流程中，開始服務提供者會進行初始化，將暴露給其他服務調用。服務消費者也需要初始化，並且在註冊中心註冊自己。

服務提供者和服務消費者暴露服務

 

首先來看看服務提供者暴露服務的整體機制：

服務提供者暴露服務流程

 

開篇的大圖中列舉了 Config 核心組件，在服務提供者初始化的時候，會通過 Config 組件中的 ServiceConfig 讀取服務的配置信息。

 

這個配置信息有三種形式，分別是 XML 文件，註解（Annoation）和屬性文件（Properties 和 yaml）。

 

在讀取配置文件生成服務實體以後，會通過 ProxyFactory 將 Proxy 轉換成 Invoker。

 

此時，Invoker 會被定義 Protocol，之後會被包裝成 Exporter。最後，Exporter 會發送到註冊中心，作爲服務的註冊信息。上述流程主要通過 ServiceConfig 中的 doExport 完成。

 

下面是針對多協議多註冊中心進行源代碼分析：

doExportUrls 方法

doExportUrlsFor1Protocol 方法-1

doExportUrlsFor1Protocol 方法-2

 

上面截取了服務提供者暴露服務的代碼片段，從註釋上看整個暴露過程分爲七個步驟：

• 讀取其他配置信息到 map 中，用來後面構造 URL。

• 讀取全局配置信息。

• 配置不是 remote，也就是暴露本地服務。

• 如果配置了監控地址，則服務調用信息會上報。

• 通過 Proxy 轉化成 Invoker，RegistryURL 存放的是註冊中心的地址。

• 暴露服務以後，向註冊中心註冊服務信息。

• 沒有註冊中心直接暴露服務。

 

一旦服務註冊到註冊中心以後，註冊中心會通過 RegistryProtocol 中的 Export 方法將服務暴露出去，並依次做以下操作：

• 委託具體協議進行服務暴露，創建 NettyServer 監聽端口，並保持服務實例。

• 創建註冊中心對象，創建對應的 TCP 連接。

• 註冊元數據到註冊中心。

• 訂閱 Configurators 節點。

• 如果需要銷燬服務，需要關閉端口，註銷服務信息。

 

說完了服務提供者的暴露再來看看服務消費者。

服務消費者消費服務機制

 

服務消費者首先持有遠程服務實例生成的 Invoker，然後把 Invoker 轉換成用戶接口的動態代理引用。

 

框架進行服務引用的入口點在 ReferenceBean 中的 getObject 方法，會將實體轉換成 ReferenceBean，它是集成與 ReferenceConfig 類的。

 

這裏一起來看看 createProxy 的源代碼：

getProxy 代碼片段 1

getProxy 代碼片段 2

 

從上面代碼片段可以看出，消費者服務在調用服務提供者時，做了以下動作：

• 檢查是否是同一個 JVM 內部引用。

• 如果是同一個 JVM 的引用，直接使用 injvm 協議從內存中獲取實例。

• 註冊中心地址後，添加 refer 存儲服務消費元數據信息。

• 單註冊中心消費。

• 依次獲取註冊中心的服務，並且添加到 Invokers 列表中。

• 通過 Cluster 將多個 Invoker 轉換成一個 Invoker。

• 把 Invoker 轉換成接口代理。

註冊中心

說完服務暴露，再回頭來看看註冊中心。Dubbo 通過註冊中心實現了分佈式環境中服務的註冊和發現。

配置中心

 

其主要作用如下：

• 動態載入服務。服務提供者通過註冊中心，把自己暴露給消費者，無須消費者逐個更新配置文件。

• 動態發現服務。消費者動態感知新的配置，路由規則和新的服務提供者。

• 參數動態調整。支持參數的動態調整，新參數自動更新到所有服務節點。

• 服務統一配置。統一連接到註冊中心的服務配置。

 

配置中心工作流

 

註冊調用流程圖

 

先看看註冊中心調用的流程圖：

• 提供者（Provider）啓動時，會向註冊中心寫入自己的元數據信息（調用方式）。

• 消費者（Consumer）啓動時，也會在註冊中心寫入自己的元數據信息，並且訂閱服務提供者，路由和配置元數據的信息。

• 服務治理中心（duubo-admin）啓動時，會同時訂閱所有消費者，提供者，路由和配置元數據的信息。

• 當提供者離開或者新提供者加入時，註冊中心發現變化會通知消費者和服務治理中心。

 

註冊中心工作原理

 

Dubbo 有四種註冊中心的實現，分別是 ZooKeeper，Redis，Simple 和 Multicast。

 

這裏着重介紹一下 ZooKeeper 的實現。ZooKeeper 是負責協調服務式應用的。

 

它通過樹形文件存儲的 ZNode 在 /dubbo/Service 目錄下面建立了四個目錄，分別是：

• Providers 目錄下面，存放服務提供者 URL 和元數據。

• Consumers 目錄下面，存放消費者的 URL 和元數據。

• Routers 目錄下面，存放消費者的路由策略。

• Configurators 目錄下面，存放多個用於服務提供者動態配置 URL 元數據信息。

 

      客戶端第一次連接註冊中心的時候，會獲取全量的服務元數據，包括服務提供者和服務消費者以及路由和配置的信息。

      根據 ZooKeeper 客戶端的特性，會在對應 ZNode 的目錄上註冊一個 Watcher，同時讓客戶端和註冊中心保持 TCP 長連接。

      如果服務的元數據信息發生變化，客戶端會接受到變更通知，然後去註冊中心更新元數據信息。變更時根據 ZNode 節點中版本變化進行。

 

Dubbo 集羣容錯

 

Cluster，Directory，Router，LoadBalance 核心接口

 

分佈式服務多以集羣形式出現，Dubbo 也不例外。在消費服務發起調用的時候，會涉及到 Cluster，Directory，Router，LoadBalance 幾個核心組件。

Cluster，Directory，Router，LoadBalance 調用流程

 

先看看他們是如何工作的：

①生成 Invoker 對象。根據 Cluster 實現的不同，生成不同類型的 ClusterInvoker 對象。通過 ClusertInvoker 中的 Invoker 方法啓動調用流程。

②獲取可調用的服務列表，可以通過 Directory 的 List 方法獲取。這裏有兩類服務列表的獲取方式。

 

分別是 RegistryDirectory 和 StaticDirectory：

• RegistryDirectory：屬於動態 Directory 實現，會自動從註冊中心更新 Invoker 列表，配置信息，路由列表。

• StaticDirectory：它是 Directory 的靜態列表實現，將傳入的 Invoker 列表封裝成靜態的 Directory 對象。

       在 Directory 獲取所有 Invoker 列表之後，會調用路由接口（Router）。其會根據用戶配置的不同策略對 Invoker 列表進行過濾，只返回符合規則的 Invoker。

假設用戶配置接口 A 的調用，都使用了 IP 爲 192.168.1.1 的節點，則 Router 會自動過濾掉其他的 Invoker，只返回 192.168.1.1 的 Invoker。

 

這裏介紹一下 RegistryDirectory 的實現，它通過 Subscribe 和 Notify 方法，訂閱和監聽註冊中心的元數據。

Subscribe，訂閱某個 URL 的更新信息。Notify，根據訂閱的信息進行監聽。包括三類信息，配置 Configurators，路由 Router，以及 Invoker 列表。

管理員會通過 dubbo-admin 修改 Configurators 的內容，Notify 監聽到該信息，就更新本地服務的 Configurators 信息。

同理，路由信息更新了，也會更新服務本地路由信息。如果 Invoker 的調用信息變更了（服務提供者調用信息），會根據具體情況更新本地的 Invoker 信息。

Notify 監聽三類信息

 

通過前面三步生成的 Invoker 需要調用最終的服務，但是服務有可能分佈在不同的節點上面。所以，需要經過 LoadBalance。

Dubbo 的負載均衡策略有四種：

• Random LoadBalance，隨機，按照權重設置隨機概率做負載均衡。

• RoundRobinLoadBalance，輪詢，按照公約後的權重設置輪詢比例。

• LeastActiveLoadBalance，按照活躍數調用，活躍度差的被調用的次數多。活躍度相同的 Invoker 進行隨機調用。

• ConsistentHashLoadBalance，一致性 Hash，相同參數的請求總是發到同一個提供者。

 

       最後進行 RPC 調用。如果調用出現異常，針對不同的異常提供不同的容錯策略。Cluster 接口定義了 9 種容錯策略，這些策略對用戶是完全透明的。

用戶可以在，，， 標籤上通過 Cluster 屬性設置：

• Failover，出現失敗，立即重試其他服務器。可以設置重試次數。

• Failfast，請求失敗以後，返回異常結果，不進行重試。

• Failsafe，出現異常，直接忽略。

• Failback，請求失敗後，將失敗記錄放到失敗隊列中，通過定時線程掃描該隊列，並定時重試。

• Forking，嘗試調用多個相同的服務，其中任意一個服務返回，就立即返回結果。

• Broadcast，廣播調用所有可以連接的服務，任意一個服務返回錯誤，就任務調用失敗。

• Mock，響應失敗時返回僞造的響應結果。

• Available，通過遍歷的方式查找所有服務列表，找到第一個可以返回結果的節點，並且返回結果。

• Mergable，將多個節點請求合併進行返回。

 

Dubbo 遠程調用

服務消費者經過容錯，Invoker 列表，路由和負載均衡以後，會對 Invoker 進行過濾，之後通過 Client 編碼，序列化發給服務提供者。

過濾，發送請求，編碼，序列化發送給服務提供者

 

從上圖可以看出在服務消費者調用服務提供者的前後，都會調用 Filter（過濾器）。

        可以針對消費者和提供者配置對應的過濾器，由於過濾器在 RPC 執行過程中都會被調用，所以爲了提高性能需要根據具體情況配置。

       Dubbo 系統有自帶的系統過濾器，服務提供者有 11 個，服務消費者有 5 個。過濾器的使用可以通過 @Activate 的註釋，或者配置文件實現。

配置文件實現過濾器

 

過濾器的使用遵循以下幾個規則：

• 過濾器順序，過濾器執行是有順序的。例如，用戶定義的過濾器的過濾順序默認會在系統過濾器之後。

  又例如，上圖中 filter=“filter01, filter02”，filter01 過濾器執行就在 filter02 之前。

• 過濾器失效，如果針對某些服務或者方法不希望使用某些過濾器，可以通過“-”（減號）的方式使該過濾器失效。例如，filter=“-filter01”。

• 過濾器疊加，如果服務提供者和服務消費者都配置了過濾器，那麼兩個過濾器會被疊加生效。

 

       由於，每個服務都支持多個過濾器，而且過濾器之間有先後順序。因此在設計上 Dubbo 採用了裝飾器模式，將 Invoker 進行層層包裝，每包裝一層就加入一層過濾條件。在執行過濾器的時候就好像拆開一個一個包裝一樣。

       調用請求經過過濾以後，會以 Invoker 的形式對 Client 進行調用。Client 會交由底層 I/O 線程池處理，其包括處理消息讀寫，序列化，反序列化等邏輯。

同時會對 Dubbo 協議進行編碼和解碼操作。Dubbo 協議基於 TCP/IP 協議，包括協議頭和協議體。

協議體包含了傳輸的主要內容，其意義不言而喻，它是由 16 字節長的報文組成，每個字節包括 8 個二進制位。

 

內容如下：

• 0-7 位，“魔法數”高位。

• 8-15 位，“魔法數”低位。前面兩個字節的“魔法數”，是用來區別兩個不同請求。好像編程中使用的“；”“/”之類的符號將兩條記錄分開。PS：魔法數用固定的“0xdabb”表示，

• 16 位，數據包的類型，因爲 RPC 調用是雙向的，0 表示 Response，1 表示 Request。

• 17 位，調用方式，0 表示單項，1 表示雙向。

• 18 位，時間標識，0 表示請求/響應，1 表示心跳包。

• 19-23 位，序列化器編號，就是告訴協議用什麼樣的方式進行序列化。例如：Hessian2Serialization 等等。

• 24-31 位，狀態位。20 表示 OK，30 表示 CLIENT_TIMEOUT 客戶端超時，31 表示 SERVER_TIMEOUT 服務端超時，40 表示 BAD_REQUEST 錯誤的請求，50 表示 BAD_RESPONSE 錯誤的響應。

• 32-95 位，請求的唯一編號，也就是 RPC 的唯一 ID。

• 96-127，消息體包括 Dubbo 版本號，服務接口名，服務接口版本，方法名，參數類型，方法名，參數類型，方法參數值和請求額外參數。

 

     服務消費者在調用之前會將上述服務消息體，根據 Dubbo 協議打包好。框架內部會調用 DefaultFuture 對象的 get 方法進行等待。

      在準備發送請求的時候，才創建 Request 對象，這個對象會保存在一個靜態的 HashMap 中，當服務提供者處理完 Request 之後，將返回的 Response 放回到 Futures 的 HashMap 中。

 

在 HashMap 中會找到對應的 Request 對象，並且返回給服務消費者。

服務消費者請求和響應圖

 

協議打包好以後就需要給協議編碼和序列化。這裏需要用到 Dubbo 的編碼器，其過程是將信息傳化成字節流。

       Dubbo 協議編碼請求對象分爲使用 ExchangeCodec 中的兩個方法，encodeRequest 負責編碼協議頭和 encodeRequestData 編碼協議體。同樣通過 encodeResponse 編碼協議頭，encodeResponseData 編碼協議體。

       服務消費者和提供者都通過 decode 和 decodeBody 兩個方法進行解碼，不同的是解碼有可能在 IO 線程或者 Dubbo 線程池中完成。

雖然，編碼和解碼的細節在這裏不做展開，但是以下幾點需要注意：

• 構造 16 字節的協議頭，特別是需要創建前面兩個字節的魔法數，也就是“0xdabb”，它是用來分割兩個不同請求的。

• 生成唯一的請求/響應 ID，並且根據這個 ID 識別請求和響應協議包。

• 通過協議頭中的 19-23 位的描述，進行序列化/反序列化操作。

• 爲了提高處理效率，每個協議都會放到 Buffer 中處理。

 

當服務提供者收到請求協議包以後，先將其放到 ThreadPool 中，然後依次處理。

由於服務提供者在註冊中心是通過 Exporter 的方式暴露服務的，服務消費者也是通過 Exporter 作爲接口進行調用的。

Exporter 是將 Invoker 進行了包裝，將拆開的 Invoker 進行 Filter 過濾鏈條進行過濾以後，再去調用服務實體。最後，將信息返回給服務消費者。

 

總結

       我們首先了解 Dubbo 的分層和幾個核心模塊，分別介紹他們的職責。然後通過一個簡單的例子，服務消費者調用服務提供者，用 Dubbo 的工作流程將各個模塊串起來。

在這 22 步的流程中，以服務提供者和服務消費者的初始化爲起點，用到了 Config 和 Proxy 以及 Protocol，Invoker。

註冊中心作爲兩者的連接橋樑，起到了服務發現和註冊的作用，並且着重講了如何通過 ZooKeeper 實現註冊中心的原理。

在服務消費者調用提供者之前，需要通過 Cluster 容錯機制，Directory 獲取 Invoker 列表，Router 找到路由信息，再使用 LoadBalance 知道具體服務。

在調用服務提供者之間還不忘通過 Filter 進行過濾，通過裝飾者模式實現的 Filter 可以形成過濾鏈條，依次對條件進行過濾。

對於遠程調用，需要調用打包協議，針對 Dubbo 協議進行了描述，並且針對該協議進行了編碼/解碼和序列化/反序列化的操作。

服務提供者收到請求以後，會將請求放到 ThreadPool 中逐一處理。通過 Exporter，Invoker，Filter 的逐級轉換，最後響應請求。