【51CTO.com原創稿件】分布式應用場景有高并發，高可擴展和高性能的要求。還涉及到，序列化/反序列化，網絡，多線程以及設計模式的問題。幸好 Dubbo 框架將上述知識進行了封裝，讓程序員能夠把注意力放到業務上。

[[284227]] 

圖片來自 Pexels

為了更好地了解和使用 Dubbo，今天來介紹一下 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 的逐級轉換，最后響應請求。

由于篇幅有限很多功能例如 SPI，Merger 等沒有介紹到，有時間再和大家細聊。

作者：崔皓

簡介：十六年開發和架構經驗，曾擔任過惠普武漢交付中心技術專家，需求分析師，項目經理，后在創業公司擔任技術/產品經理。善于學習，樂于分享。目前專注于技術架構與研發管理。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】