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 的逐級轉換,最後響應請求。

發佈了65 篇原創文章 · 獲贊 8 · 訪問量 4萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章