Dubbo 底層原理剖析

閱讀指南

本文會通過 圖文 + 案例，對 Dubbo 的底層原理進行剖析 - 探索 Dubbo 分層的意義。閱讀之前，要求對 Dubbo 有所瞭解，並且會簡單使用。

正文

先來看一張摘自官網的 令人頭大 的 Dubbo 框架設計圖，另外還有幾張圖，就不一一貼出了，詳細請參考 Dubbo 框架設計 

其實 Dubbo 官網關於框架設計的部分已經講得很詳細了，但是對於我們這種沒工作多久的菜鳥，仍然需要花費大量的時間去理解。

框架設計的簡要說明

Dubbo 的框架設計圖中從下至上分爲十層，其中，Service 和 Config 層爲 API，其它各層均爲 SPI。也就是除了 Service 和 Config 層，其餘各層都至少有一種替代品。

比如 Protocol 層：

• org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol

• org.apache.dubbo.rpc.protocol.rmi.RmiProtocol

• org.apache.dubbo.rpc.protocol.http.HttpProtocol

Dubbo 的這種高擴展性全部基於 Dubbo SPI 機制，前面花費了多篇文章去講解 Dubbo SPI 使用，這是研究 Dubbo 源碼的關鍵。

官網 Demo 案例

篇幅原因，具體使用方法和代碼還是到官網 Dubbo - 快速啓動，下面的內容全部基於這個案例。

圖解服務調用過程

官網給出了非常詳細的服務調用過程，都是從架構層面，還有整個流程會經歷哪個類，哪個方法，下面就基於官網的圖文，再結合案例給出自己的理解。

從 main 函數的代碼來看，整個流程看着很簡單

當我們加上註冊中心後

結合 xml 配置 和 Dubbo - 架構, 圖解如下：

結合框架設計

服務引用過程

• 4.1 Proxy 層 對服務消費端使用的 DemoService接口進行代理，把本地調用透明地轉換爲遠程調用， 該層默認使用的是 JavassistProxyFactory, 對該層的理解，可以參考之前的文章 基於 Java 實現最初級版的 RPC

• 4.2 Cluster 層 從圖中可以看出，服務提供者有 2 個實例，那麼消費者最終會調用哪個實例，就是由 Cluster 層決定的，該層還會橋連註冊中心 zookeeper，獲取 2 個服務提供者的註冊信息，比如 ip，port。當然該層還有其他功能。

• 4.3 Protocol 層 要實現圖中的遠程調用，其實本質就是通過網絡通信，來傳輸信息。Dubbo 爲此提供了多種通信協議，默認爲 DubboProtocol。

// 有刪減
dubbo://LOCALHOST:20880/org.apache.dubbo.demo.DemoService
?anyhost=true&application=demo-provider&bind.ip=192.168.31.87&bind.port=20880&
interface=org.apache.dubbo.demo.DemoService
&methods=sayHello,sayHello1×tamp=1586693904645

• 4.4 Exchanger 層 封裝請求響應內容爲 Request / Response 對象。做 web 接口開發的都知道，我們會把一些參數或者響應內容封裝到 XXXRequest/YYYResponse 對象中。

• 4.5 Transport 層 該層爲網絡傳輸層，基於 Netty ，Mina 等通信框架實現。

• 4.6 Serialize 既然涉及到網絡傳輸，必然會把請求對象進行序列化操作。

服務暴露過程

• 5.1 開啓 Server 並監聽指定端口

• 5.2 將請求數據進行反序列化

• 5.3 Exchanger 負責解析 Request 對象

• 5.4 通過 Protocol 層, 根據具體協議解析 Request 對象

• 5.5 對服務提供者的服務實現類進行代理

總結

本文結合官網的 Demo 案例, 通過畫圖的方式, 對 Dubbo 的框架設計圖進行了簡化, 目的是瞭解 Dubbo 框架分層的作用。一個簡單的 RPC 就是基於動態代理 + 網絡通信,

• 動態代理 (Proxy) 就是把本地調用透明轉換爲遠程調用

• 遠程調用就要涉及到網絡通信 (Transport) - 基於 socket

• 在 socket 基礎上, 我們可以自定義我們的協議 (Protocol) , 也可以複用現有的協議, 比如 http

• 基於上面的過程, 我們可以封裝 Request / Response 對象 (Exchanger)

• 既然要網絡傳輸, 就要想辦法進行序列化 / 反序列化 (Serialize)

• 當提供多個服務提供者實例時, 就應該有一個地方 (註冊中心 Register) 負責管理服務提供者的元數據信息,

• 當消費者從上面的多個服務提供者 選取一個 調用服務 (Cluster) 時, 就要選取某種策略 (比如輪詢, hash)

• 最後需要一個監控中心 (Monitor) , 負責一些統計功能, 比如服務調用次數

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/MTmbLCC1cwlnt5bBjO44IA