這篇文檔是關于 Dubbo 的簡單介紹，涵蓋 Dubbo 的核心概念、基本使用方式以及 Dubbo3 核心功能，無論你是 Dubbo 的老用戶還是新用戶，都可以通過這篇 文檔快速了解 Dubbo 及新版本帶來的變化。

Apache Dubbo 是一款微服務開發(fā)框架，它提供了 RPC通信 與 微服務治理 兩大關鍵能力。這意味著，使用 Dubbo 開發(fā)的微服務，將具備相互之間的遠程發(fā)現與通信能力， 同時利用 Dubbo 提供的豐富服務治理能力，可以實現諸如服務發(fā)現、負載均衡、流量調度等服務治理訴求。同時 Dubbo 是高度可擴展的，用戶幾乎可以在任意功能點去定制自己的實現，以改變框架的默認行為來滿足自己的業(yè)務需求。

Dubbo3 基于 Dubbo2 演進而來，在保持原有核心功能特性的同時， Dubbo3 在易用性、超大規(guī)模微服務實踐、云原生基礎設施適配、安全設計等幾大方向上進行了全面升級。 以下文檔都將基于 Dubbo3 展開。

什么是Dubbo3？

如開篇所述，Dubbo 提供了構建云原生微服務業(yè)務的一站式解決方案，可以使用 Dubbo 快速定義并發(fā)布微服務組件，同時基于 Dubbo 開箱即用的豐富特性及超強的擴展能力，構建運維整個微服務體系所需的各項服務治理能力，如 Tracing（追蹤）、Transaction（事務） 等，Dubbo 提供的基礎能力包括：

• 服務發(fā)現
• 流式通信
• 負載均衡
• 流量治理
• …..

Dubbo 計劃提供豐富的多語言客戶端實現，其中 Java、Golang 版本是當前穩(wěn)定性、活躍度最好的版本，其他多語言客戶端正在持續(xù)建設中。

自開源以來，Dubbo 就被一眾大規(guī)模互聯網、IT公司選型，經過多年企業(yè)實踐積累了大量經驗。Dubbo3 是站在巨人肩膀上的下一代產品，它汲取了上一代的優(yōu)點并針對已知問題做了大量優(yōu)化，因此，Dubbo 在解決業(yè)務落地與規(guī)?；瘜嵺`方面有著無可比擬的優(yōu)勢：

• 開箱即用易用性高，如 Java 版本的面向接口代理特性能實現本地透明調用功能豐富，基于原生庫或輕量擴展即可實現絕大多數的微服務治理能力
• 超大規(guī)模微服務集群實踐高性能的跨進程通信協議地址發(fā)現、流量治理層面，輕松支持百萬規(guī)模集群實例
• 企業(yè)級微服務治理能力服務測試服務Mock（模擬）

Dubbo3 是在云原生背景下誕生的，使用 Dubbo 構建的微服務遵循云原生思想，能更好的復用底層云原生基礎設施、貼合云原生微服務架構。這體現在：

• 服務支持部署在容器、Kubernetes（K8S）平臺，服務生命周期可實現與平臺調度周期對齊；
• 支持經典 Service Mesh （服務網格）微服務架構，引入了 Proxyless Mesh 架構，進一步簡化 Mesh 的落地與遷移成本，提供更靈活的選擇；
• 作為橋接層，支持與 SpringCloud、gRPC 等異構微服務體系的互調互通

一站式微服務解決方案

Dubbo 提供了從服務定義、服務發(fā)現、服務通信到流量管控等幾乎所有的服務治理能力，并且嘗試從使用上對用戶屏蔽底層細節(jié)，以提供更好的易用性。

定義服務在 Dubbo 中非常簡單與直觀，可以選擇使用與某種語言綁定的方式（如 Java 中可直接定義Interface），也可以使用 Protobuf IDL 語言中立的方式。無論選擇哪種方式，站在服務消費方的視角，都可以通過 Dubbo 提供的透明代理直接編碼。

需要注意的是，在 Dubbo 中，我們提到服務時，通常是指 RPC 粒度的、提供某個具體業(yè)務增刪改功能的接口或方法，與一些微服務概念書籍中泛指的服務并不是一個概念。

點對點的服務通信是 Dubbo 提供的另一項基本能力，Dubbo 以 RPC 的方式將請求數據（Request）發(fā)送給后端服務，并接收服務端返回的計算結果（Response）。RPC 通信對用戶來說是完全透明的，使用者無需關心請求是如何發(fā)出去的、發(fā)到了哪里，每次調用只需要拿到正確的調用結果就行。同步的 Request-Response 是默認的通信模型，它最簡單但卻不能覆蓋所有的場景，因此，Dubbo 提供更豐富的通信模型：

• 消費端異步請求(Client Side Asynchronous Request-Response)
• 提供端異步執(zhí)行（Server Side Asynchronous Request-Response）
• 消費端請求流（Request Streaming）
• 提供端響應流（Response Streaming）
• 雙向流式通信（Bidirectional Streaming）

Dubbo 的服務發(fā)現機制，讓微服務組件之間可以獨立演進并任意部署，消費端可以在無需感知對端部署位置與 IP 地址的情況下完成通信。Dubbo 提供的是 Client-Based 的服務發(fā)現機制，使用者可以有多種方式啟用服務發(fā)現：

• 使用獨立的注冊中心組件，如 Nacos、Zookeeper、Consul、Etcd 等。
• 將服務的組織與注冊交給底層容器平臺，如 Kubernetes，這被理解是一種更云原生的方式

透明地址發(fā)現讓 Dubbo 請求可以被發(fā)送到任意 IP 實例上，這個過程中流量被隨機分配。當需要對流量進行更豐富、更細粒度的管控時，就可以用到 Dubbo 的流量管控策略，Dubbo 提供了包括負載均衡、流量路由、請求超時、流量降級、重試等策略，基于這些基礎能力可以輕松的實現更多場景化的路由方案，包括金絲雀發(fā)布、A/B測試、權重路由、同區(qū)域優(yōu)先等，更酷的是，Dubbo 支持流控策略在運行態(tài)動態(tài)生效，無需重新部署。

Dubbo 強大的服務治理能力不僅體現在核心框架上，還包括其優(yōu)秀的擴展能力以及周邊配套設施的支持。通過 Filter、Router、Protocol 等幾乎存在于每一個關鍵流程上的擴展點定義，我們可以豐富 Dubbo 的功能或實現與其他微服務配套系統(tǒng)的對接，包括 Transaction、Tracing 目前都有通過 SPI 擴展的實現方案，具體可以參見 Dubbo 擴展性的詳情，也可以在 apache/dubbo-spi-extensions 項目中發(fā)現與更多的擴展實現。

大規(guī)模企業(yè)微服務實踐沉淀

Dubbo 最早誕生于阿里巴巴，隨后加入 Apache 軟件基金會，項目從設計之初就是為了解決企業(yè)的服務化問題，因此充分考慮了大規(guī)模集群場景下的服務開發(fā)與治理問題，如易用性、性能、流量管理、集群可伸縮性等。在 Dubbo 開源的將近 10 年時間內，Dubbo 幾乎成為了國內微服務框架選型的首選框架，尤其受到大規(guī)?；ヂ摼W、IT企業(yè)的認可，可以說作為開源服務框架，Dubbo 在支持微服務集群方面有著非常大的規(guī)模與非常久的實踐經驗積累，是最具有企業(yè)規(guī)?；⒎諏嵺`話語權的框架之一。采用 Dubbo 的企業(yè)涵蓋互聯網、傳統(tǒng)IT、金融、生產制造業(yè)多個領域，一些典型用戶包括阿里巴巴、攜程、工商銀行、中國人壽、海爾、金蝶等。

在企業(yè)大規(guī)模實踐的過程中，Dubbo 的穩(wěn)定性得到了驗證，服務治理的易用性與豐富度也在不斷提升，而也就是在這樣的背景下催生了下一代的產品 - Dubbo3。Dubbo3 的整個設計與開發(fā)過程，始終有來自社區(qū)團隊與眾多企業(yè)用戶的共同參與，因此 Dubbo3 的許多核心架構與功能都充分考慮了大規(guī)模微服務實踐訴求。阿里巴巴是參與在 Dubbo3 中的核心力量之一，作為企業(yè)用戶其主導了該版本許多核心功能的設計與開發(fā)，阿里巴巴把 Dubbo3 社區(qū)版本確定為其未來內部主推的服務框架，并選擇將內部 HSF 通過 Dubbo3 的形式貢獻到開源社區(qū)，在阿里巴巴內部，眾多業(yè)務線包括電商系統(tǒng)的考拉、交易平臺，以及餓了么、釘釘等都已經成功遷移到 Dubbo3 版本。同樣全程參與在 Dubbo3 開發(fā)與驗證試點過程中的企業(yè)用戶包括工商銀行、攜程、斗魚、小米等。

Dubbo 的大規(guī)模實踐經驗主要體現在：

• 高性能通信
• 高可擴展性
• 超大規(guī)模集群實例水平擴展
• 豐富的服務治理能力

關于 Dubbo 調用性能、支持超大規(guī)模集群地址方面的評測數據，將在隨后發(fā)布，敬請期待。

云原生友好

Dubbo 從設計上是完全遵循云原生微服務開發(fā)理念的，這體現在多個方面，首先是對云原生基礎設施與部署架構的支持，包括 Kubernetes、Service Mesh 等，另一方面，Dubbo 眾多核心組件都已面向云原生升級，包括 Triple 協議、統(tǒng)一路由規(guī)則、對多語言支持。值得一提的是，如何使用 Dubbo 支持彈性伸縮的服務如 Serverless 也在未來計劃之中，這包括利用 Native Image 提高 Dubbo 的啟動速度與資源消耗等。

結合當前版本，本節(jié)主要從以下兩點展開 Dubbo 的云原生特性

• 容器調度平臺（Kubernetes）
• Service Mesh

Kubernetes

Dubbo 微服務要支持 Kubernetes 平臺調度，最基礎的就是實現 dubbo 服務生命周期與容器生命周期的對齊，這包括 Dubbo 的啟動、銷毀、服務注冊等生命周期事件。相比于以往 Dubbo 自行定義生命周期事件，并要求開發(fā)人員在運維實踐過程中遵守約定，Kubernetes 底層基礎設施定義了嚴格的組件生命周期事件(probe)，轉而要求 Dubbo 去按約定適配。

Kubernetes Service 是另一個層面的適配，這體現了服務定義與注冊向云原生底層基礎設施下沉的趨勢。在這種模式下，用戶不再需要搭建額外的注冊中心組件，Dubbo 消費端節(jié)點能自動對接到 Kubernetes（API-Server 或 DNS），根據服務名（Kubernetes Service Name） 查詢到實例列表（Kubernetes endpoints）。 此時服務是通過標準的 Kubernetes Service API 定義，并被調度到各個節(jié)點。

Service Mesh

Service Mesh 在業(yè)界得到了廣泛的傳播與認可，并被認為是下一代的微服務架構，這主要是因為它解決了很多棘手的問題，包括透明升級、多語言、依賴沖突、流量治理等。Service Mesh 的典型架構是通過部署獨立的 Sidecar 組件來攔截所有的出口與入口流量，并在 Sidecar 中集成豐富的流量治理策略如負載均衡、路由等，除此之外，Service Mesh 還需要一個控制面（Control Panel）來實現對 Sidecar 流量的管控，即各種策略下發(fā)。我們在這里稱這種架構為經典 Mesh。

然而任何技術架構都不是完美的，經典 Mesh 在實施層面也面臨成本過高的問題

1. 需要運維控制面（Control Panel）
2. 需要運維 Sidecar
3. 需要考慮如何從原有 SDK 遷移到 Sidecar
4. 需要考慮引入 Sidecar 后整個鏈路的性能損耗

為了解決 Sidecar 引入的相關成本問題，Dubbo 引入了另一種變相的 Mesh 架構 - Proxyless Mesh，顧名思義，Proxyless Mesh 就是指沒有 Sidecar 的部署，轉而由 Dubbo SDK 直接與控制面交互，其架構圖如下：

可以設想，在不同的組織、不同的發(fā)展階段，未來以 Dubbo 構建的微服務將會允許有三種部署架構：傳統(tǒng) SDK、基于 Sidecar 的 Service Mesh、脫離 Sidecar 的 Proxyless Mesh?；?Sidecar 的 Service Mesh，即經典的 Mesh 架構，獨立的 sidecar 運行時接管所有的流量，脫離 Sidecar 的 Proxyless Mesh，富 SDK 直接通過 xDS 與控制面通信。Dubbo 微服務允許部署在物理機、容器、Kubernetes 平臺之上，能做到以 Admin 為控制面，以統(tǒng)一的流量治理規(guī)則進行治理。

了解更多

What’s New in Dubbo3

體驗 Dubbo3

遷移到 Dubbo3