Apache Dubbo 是一款 RPC 服務開發架構，用于解決微服務架構下的服務治理與通信問題，官方提供了 Java、Golang 等多語言 SDK 實作。使用 Dubbo 開發的微服務原生具備互相之間的遠端位址發現與通信能力， 利用 Dubbo 提供的豐富服務治理特性，可以實作諸如服務發現、負載均衡、流量排程等服務治理訴求。Dubbo 被設計為高度可擴充，使用者可以友善地實作流量攔截、選址的各種定制邏輯。
什麼是 Dubbo 3
Cloud Native
Dubbo 3 保持了 Dubbo 2 的經典架構，以解決微服務程序間通信為主要職責，通過豐富的服務治理（如位址發現、流量管理等）能力來更好地管控微服務叢集； Dubbo3 對原有架構的更新是全面的，展現在核心 Dubbo 特性的幾乎每個環節，通過更新實作了穩定性、性能、伸縮性、易用性的全面提升。
通用的通信協定： 全新的 RPC 協定應摒棄私有協定棧，以更通用的 HTTP/2 協定為傳輸層載體，借助 HTTP 協定的标準化特性，解決流量通用性、穿透性等問題，讓協定能更好地應對前後端對接、網關代理等場景；支援 Stream 通信模式，滿足不同業務通信模型訴求的同時給叢集帶來更大的吞吐量。
面向百萬叢集執行個體，叢集高度可伸縮 ：随着微服務實踐的推廣，微服務叢集執行個體的規模也在不停地擴充，這得益于微服務輕量化、易于水準擴容的特性，同時也給整個叢集容量帶來了負擔，尤其是一些中心化的服務治理元件；Dubbo 3 需要解決執行個體規模擴充帶來的種種資源瓶頸問題，實作真正的無限水準擴容。
擁抱雲原生 ：在雲原生時代，底層基礎設施的變革正深刻影響應用的部署、運維甚至開發過程，往上也影響了 Dubbo 3 微服務技術方案的選型與部署模式。Dubbo 3 在服務發現模型上全面對齊雲原生基礎設施的模型，在位址、生命周期等設計可與 Kubernetes 等容器排程平台對齊。
未來的 Dubbo 需要解決什麼問題
Cloud Native
在 Dubbo 3 功能基本完備的當下，我們開始重新對目前 Dubbo 的整體架構進行思考，總結出有以下幾個問題：
業務代碼與各微服務元件直接耦合，更新難度高
在目前的部署形态下，如果需要內建一個元件需要在業務代碼的環境中對該元件進行适配。舉一個簡單的例子，如果需要接入一個自定義資料格式轉換元件需要基于 Dubbo 的 SPI 在業務的代碼中織入對應的适配實作。這種部署方式對業務的部署造成較高的侵入。如果這個轉換元件需要更新，需要推動所有部署了該元件的業務方都更新一遍。在生産環境中難度極高。
多語言實作複雜度高
由于目前 Dubbo 所有的計算處理邏輯都以 SDK 的形式內建進業務代碼中，在需要跨語言進行調用的時候不可避免地導緻了實作複雜度高的問題。 對于 Dubbo 來說，除了 Java 和 Golang 的 SDK 實作較為完善，其他語言仍欠缺對應完善的實作。 此外，對于一個攔截器功能，在 Java SDK 下的實作由于語言和接口設計的差異不可能直接複用到 Golang 的 SDK 上，一定程度上也給中間件開發帶來難度和不穩定因素。
治理能力下沉在資料面，中間件治理能力割裂
目前 Dubbo 的部署形态下在需要接入一個中間件治理能力的時候，需要通過資料面業務代碼直接接入的方式內建的，這種方式會導緻各治理元件獨立工作，從全局視角來看資料面的接入十分混亂，無法通過一個統一的視角進行統一治理。 同時由于這些元件是獨立接入的，元件之間的工作在某些場景下并不能很好地結合起來。
Dubbo Mesh
Cloud Native
Dubbo Mesh 從架構與部署形态上明确地區分為控制面與資料面。
其中控制面作為服務治理核心，具有抽象的、統一的模型，負責與底層基礎設施的對接，提供從啟動配置、服務發現、流量管理到認證鑒權等的統一治理入口。
資料面則專注在業務程式設計模型與通信能力上，基于多種部署形态（SDK、Sidecar、Agent）接入服務治理能力，基于動态部署能力從業務代碼中解耦出來。
總體來說，資料面更輕量、專注，控制面更内聚、強大，隻需要部署一套控制面即可使用生産級的服務治理能力。
以下分别從控制面和資料面兩個部分分别說明在 Dubbo Mesh 下各自的職責與能力：
Dubbo 控制面
控制面是服務治理核心，具有抽象的、統一的模型，負責與底層基礎設施的對接，提供從啟動配置、服務發現、流量管理到認證鑒權等的統一治理入口。
1. 抽象的服務治理模型 ：Dubbo 控制面繼承了 Dubbo 擴充性高的特點，劃分了各種領域與擴充點供各元件使用。支援自定義增加元件，隻需要元件按照标準的格式進行擴充就可以在 Dubbo Mesh 下進行快速部署、拉起、熱更新等行為。
2. 屏蔽基礎設施與元件 ：Dubbo 控制面将基礎設施如 Kubernetes 的接入通過元件的模式內建在内部，面向資料面屏蔽來自各基礎設施的差異，支援原生 Kubernetes 部署、VM 部署、混合部署等場景。
3. 統一的服務治理規則 ：Dubbo 控制面支援對接統一的服務治理規則，支援通過一套規則治理多種架構。
4. 跨語言支援 ：Dubbo 控制面通過通用的資料格式下發控制資料，配合資料面的多種部署方式解決跨語言的治理難題。
Dubbo 資料面
Dubbo 資料面将專注在業務程式設計模型與通信能力上，提供多種接入方式，對接來自 Dubbo 控制面的元件管控，支援通過元件熱更新的方式動态拉取控制面下發的治理規則識别與執行能力。
1. 專注程式設計與通信 ：Dubbo 資料面将更專注于向業務開發者提供程式設計模型的支援。使用者隻需要依賴簡單的調用 API 即可完成對應的 RPC 遠端調用，而不再需要關心背後的治理能力的接入。
2. 多種接入方式 ：Dubbo 資料面在未來将支援基于 SDK 的 proxyless 模式接入、基于 Agent 的無感覺接入以及基于 Sidecar 的跨語言接入方式，盡可能覆寫更過的使用場景，提高整體功能的易用性。
3. 元件熱更新 ：Dubbo 資料面将支援動态加載、更新來自 Dubbo 控制面下發對應的治理元件能力，将治理能力的管理收口在 Dubbo 控制面進行統一管理，完善運維流程。
4. 治理規則識别與執行 ：Dubbo 資料面主要負責對應的治理規則的識别與執行，通過動态加載能力的方式加載對應的治理能力，實作對資料面流量的治理能力。
Roadmap
在今年年底，Dubbo Mesh 将釋出具備有服務發現能力的版本，屆時将面向所有 Dubbo 使用者提供從低版本平滑遷移到 Mesh 架構的能力；在明年初春季的時候釋出帶有治理能力的版本；在明年年底前釋出帶插件熱更新能力的版本。