*作者：Dubbo 社群*

Apache Dubbo 是一款 RPC 服務開發框架，用於解決微服務架構下的服務治理與通訊問題，官方提供了 Java、Golang 等多語言 SDK 實現。使用 Dubbo 開發的微服務原生具備相互之間的遠端地址發現與通訊能力， 利用 Dubbo 提供的豐富服務治理特性，可以實現諸如服務發現、負載均衡、流量排程等服務治理訴求。Dubbo 被設計為高度可擴充套件，使用者可以方便地實現流量攔截、選址的各種定製邏輯。

## 什麼是 Dubbo 3

Dubbo 3 保持了 Dubbo 2 的經典架構，以解決微服務程式間通訊為主要職責，透過豐富的服務治理（如地址發現、流量管理等）能力來更好地管控微服務叢集；Dubbo3 對原有框架的升級是全面的，體現在核心 Dubbo 特性的幾乎每個環節，透過升級實現了穩定性、效能、伸縮性、易用性的全面提升。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/15861f3e79e24d7f8aaa276ac1c07105~tplv-k3u1fbpfcp-zoom-1.image "1.png")

**通用的通訊協議：** 全新的 RPC 協議應摒棄私有協議棧，以更通用的 HTTP/2 協議為傳輸層載體，藉助 HTTP 協議的標準化特性，解決流量通用性、穿透性等問題，讓協議能更好地應對前後端對接、閘道器代理等場景；支援 Stream 通訊模式，滿足不同業務通訊模型訴求的同時給叢集帶來更大的吞吐量。

**面向百萬叢集例項，叢集高度可伸縮**：隨著微服務實踐的推廣，微服務叢集例項的規模也在不停地擴充套件，這得益於微服務輕量化、易於水平擴容的特性，同時也給整個叢集容量帶來了負擔，尤其是一些中心化的服務治理元件；Dubbo 3 需要解決例項規模擴充套件帶來的種種資源瓶頸問題，實現真正的無限水平擴容。

**擁抱雲原生**：在雲原生時代，底層基礎設施的變革正深刻影響應用的部署、運維甚至開發過程，往上也影響了 Dubbo 3 微服務技術方案的選型與部署模式。Dubbo 3 在服務發現模型上全面對齊雲原生基礎設施的模型，在地址、生命週期等設計可與 Kubernetes 等容器排程平臺對齊。

## 未來的 Dubbo 需要解決什麼問題

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d1feb5c6af9c4cd684e6717e013db493~tplv-k3u1fbpfcp-zoom-1.image "2.png")

在 Dubbo 3 功能基本完備的當下，我們開始重新對當前 Dubbo 的整體架構進行思考，總結出有以下幾個問題：

### 業務程式碼與各微服務元件直接耦合，升級難度高

在目前的部署形態下，如果需要整合一個元件需要在業務程式碼的環境中對該元件進行適配。舉一個簡單的例子，如果需要接入一個自定義資料格式轉換元件需要基於 Dubbo 的 SPI 在業務的程式碼中織入對應的適配實現。這種部署方式對業務的部署造成較高的侵入。如果這個轉換元件需要升級，需要推動所有部署了該元件的業務方都升級一遍。在生產環境中難度極高。

### 多語言實現複雜度高

由於目前 Dubbo 所有的計算處理邏輯都以 SDK 的形式整合進業務程式碼中，在需要跨語言進行呼叫的時候不可避免地導致了實現複雜度高的問題。對於 Dubbo 來說，除了 Java 和 Golang 的 SDK 實現較為完善，其他語言仍欠缺對應完善的實現。此外，對於一個攔截器功能，在 Java SDK 下的實現由於語言和介面設計的差異不可能直接複用到 Golang 的 SDK 上，一定程度上也給中介軟體開發帶來難度和不穩定因素。

### 治理能力下沉在資料面，中介軟體治理能力割裂

當前 Dubbo 的部署形態下在需要接入一箇中介軟體治理能力的時候，需要透過資料面業務程式碼直接接入的方式整合的，這種方式會導致各治理元件獨立工作，從全域性視角來看資料面的接入十分混亂，無法透過一個統一的視角進行統一治理。同時由於這些元件是獨立接入的，元件之間的工作在某些場景下並不能很好地結合起來。

## Dubbo Mesh

Dubbo Mesh 從架構與部署形態上明確地區分為控制面與資料面。

其中控制面作為服務治理核心，具有抽象的、統一的模型，負責與底層基礎設施的對接，提供從啟動配置、服務發現、流量管理到認證鑑權等的統一治理入口。

資料面則專注在業務程式設計模型與通訊能力上，基於多種部署形態（SDK、Sidecar、Agent）接入服務治理能力，基於動態部署能力從業務程式碼中解耦出來。

總體來說，資料面更輕量、專注，控制面更內聚、強大，只需要部署一套控制面即可使用生產級的服務治理能力。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ceed16bab1c84127a56a8118e9792659~tplv-k3u1fbpfcp-zoom-1.image "3.png")

以下分別從控制面和資料面兩個部分分別說明在 Dubbo Mesh 下各自的職責與能力：

### Dubbo 控制面

控制面是服務治理核心，具有抽象的、統一的模型，負責與底層基礎設施的對接，提供從啟動配置、服務發現、流量管理到認證鑑權等的統一治理入口。

**1. 抽象的服務治理模型**：Dubbo 控制面繼承了 Dubbo 擴充套件性高的特點，劃分了各種領域與擴充套件點供各元件使用。支援自定義增加元件，只需要元件按照標準的格式進行擴充套件就可以在 Dubbo Mesh 下進行快速部署、拉起、熱更新等行為。

**2. 遮蔽基礎設施與元件**：Dubbo 控制面將基礎設施如 Kubernetes 的接入透過元件的模式整合在內部，面向資料面遮蔽來自各基礎設施的差異，支援原生 Kubernetes 部署、VM 部署、混合部署等場景。

**3. 統一的服務治理規則**：Dubbo 控制面支援對接統一的服務治理規則，支援透過一套規則治理多種框架。

**4. 跨語言支援**：Dubbo 控制面透過通用的資料格式下發控制資料，配合資料面的多種部署方式解決跨語言的治理難題。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5ddbb201ab1a4f32a67d5915a8639118~tplv-k3u1fbpfcp-zoom-1.image "4.png")

### Dubbo 資料面

Dubbo 資料面將專注在業務程式設計模型與通訊能力上，提供多種接入方式，對接來自 Dubbo 控制面的元件管控，支援透過元件熱更新的方式動態拉取控制面下發的治理規則識別與執行能力。

**1. 專注程式設計與通訊**：Dubbo 資料面將更專注於向業務開發者提供程式設計模型的支援。使用者只需要依賴簡單的呼叫 API 即可完成對應的 RPC 遠端呼叫，而不再需要關心背後的治理能力的接入。

**2. 多種接入方式**：Dubbo 資料面在未來將支援基於 SDK 的 proxyless 模式接入、基於 Agent 的無感知接入以及基於 Sidecar 的跨語言接入方式，儘可能覆蓋更過的使用場景，提高整體功能的易用性。

**3. 元件熱更新**：Dubbo 資料面將支援動態載入、更新來自 Dubbo 控制面下發對應的治理元件能力，將治理能力的管理收口在 Dubbo 控制面進行統一管理，完善運維流程。

**4. 治理規則識別與執行**：Dubbo 資料面主要負責對應的治理規則的識別與執行，透過動態載入能力的方式載入對應的治理能力，實現對資料面流量的治理能力。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/72888ad94b2c48a3a1d43ca3add216fd~tplv-k3u1fbpfcp-zoom-1.image "5.png")

### Roadmap

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4d9fc59a982747eeb46523907cb8b821~tplv-k3u1fbpfcp-zoom-1.image "6.png")

在今年年底，Dubbo Mesh 將釋出具備有服務發現能力的版本，屆時將面向所有 Dubbo 使用者提供從低版本平滑遷移到 Mesh 架構的能力；在明年初春季的時候釋出帶有治理能力的版本；在明年年底前釋出帶外掛熱更新能力的版本。

點選[此處](https://dubbo.apache.org/zh/index.html)，直達 Dubbo 官網！

Dubbo Mesh - 從服務框架到統一服務控制平臺

相關文章