作者 | 陸龜
來源 | 阿里巴巴云原生公眾號

本文整理自作者在3月20日云原生中間件 Meetup 上海站的分享?；貜完P鍵字“中間件”可以獲取視頻錄播地址和 PPT。

就在今天，Dubbo 社區剛剛發布了 3.0 的首個預覽版本 - 3.0.0.preview。

https://github.com/apache/dubbo/releases/tag/3.0.0.preview

本文將和讀者一起解讀 Dubbo3 的首個 preview 版本：一方面，我們將深入分析 ?Dubbo3 云原生變革的核心理念；另一方面，我們將逐個解讀 preview 版本的核心功能。

做過微服務開發的開發者相信對 Dubbo 都不陌生，Dubbo 是一款能幫助我們快速解決微服務開發、通信以及流量治理的框架。相比于之前只限定在 Java 語言范圍內，Dubbo 的多語言版本在這兩年呈現了良好的發展勢頭，其中，Dubbo Go 語言版本在功能、穩定性各個方面都已非常完備，其它幾種主流的多語言版本在社區也有提供。

云原生視角的微服務變革

Dubbo 主要解決微服務開發、運行域問題，它和微服務的編程、通信、流量治理等密切關聯，因此，在探尋 Dubbo3 的云原生變革之前，我們先嘗試從云原生視角觀察云原生基礎設施帶給微服務架構和實踐的變革，進而總結出 Dubbo 這樣一個和微服務實踐密切相關的框架所面臨的變革與挑戰。

微服務在讓業務開發演進更靈活、快捷的同時，也帶來了一些它獨有的特征和需求：如微服務之后組件數量越來越多，如何解決各個組件的穩定性，如何快速的水平擴容等。

這些訴求，尤其是運維、交付相關訴求，如微服務組件的生命周期、網絡、通用服務綁定、服務狀態管理等，并不應該是開發人員關注的重點，因為它們已經完全脫離了業務邏輯，開發人員更愿意專注在有業務價值組件上，但這個層次的訴求卻是實現微服務交付的關鍵能力。開發者期望由底層基礎設施來提供此類能力支持，而處于不同階段發展的基礎設施卻不一定具備這樣的能力，因此，在微服務軟件架構和底層基礎設施之間就出現了一條鴻溝，我們需要有組件能填補這一鴻溝，讓微服務組件能更好的接入底層基礎設施。

這里從一個更抽象的層面，嘗試用兩條發展曲線演示了軟件架構訴求與底層基礎設施能力豐富度之間的關系?？傮w上，兩者之間的發展關系可拆分為兩個階段。

在第一個階段，軟件架構（這條紅色的線）從單體應用、到面向服務的軟件架構、再到微服務架構，快速演進，從而也提出了上文我們講到的對基礎設施對交付的訴求，這個時候基礎設施層還多是以定制化的方式來滿足軟件架構的訴求，如過往的集中化的 ESB、各個不同的 PaaS 平臺等。

第二個階段，是從容器、Kubernetes 為代表的基礎產品的出現開始，藍線與紅線之間的增長速度被快速拉近，以云原生技術為代表的底層基礎設施豐富度得到了極大改善，它們不再只是被動的滿足微服務開發的訴求，而是開始抽象更多的軟件訴求到底層的基礎設施，將它們下沉為基礎能力，并開始以統一的、標準化的形式向上輸出以滿足微服務對交付、運維等的訴求，不僅如此，通過更深入的主動創新、持續的向上釋放能力，底層基礎設施還開始反過來影響微服務的開發、接入方式，如 sidecar、dapr 等模型。

Dubbo3 的云原生變革

通過上文云對原生基礎設施演進給傳統微服務帶來變革的分析，我們得出，以 Dubbo 為代表的微服務開發框架，應重點在以下方向突破與變革。

• 更多的微服務組件及能力正下沉到以 Kubernetes 為代表的基礎設施層。傳統微服務開發框架應剔除一些冗余機制，積極的適配到基礎設施層以做到能力復用；微服務框架生命周期、服務治理等能力應更好地與 Kubernetes 服務編排機制融合。

• 以 Service Mesh 為代表微服務架構給微服務開發帶來的新的選擇，但由于 Mesh 架構本身的復雜性，其距離大規模生產落地還有一段距離。我們相信，基于 ServiceMesh 的體系會逐步從孵化器走向成熟期，會有越來越多的企業采用 Service Mesh技術，但在未來在很長一段時間內，基于服務框架的傳統微服務體系還將是主流，長期仍將占據半壁江山。

我們不妨回想一下，在云原生基礎設施能力被充分釋放前，圍繞 Dubbo 構建微服務時，它給微服務開發提供了哪些能力？或者我們期望它提供哪些能力？

Dubbo2 提供了包括服務注冊、服務發現、負載均衡、流量治理等相當豐富的能力，當然還包括微服務最需要的遠程通信能力，這些能力很好地解決了微服務的訴求。

而在云原生架構之下，我們需要重新審視，Dubbo2 的哪些能力是冗余的，是需要接入基礎設施的？哪些能力是已經不適合云原生時代的，需要被重構的？

首先，是接入云原生基礎設施后，一些能力出現了重復，像服務定義、服務注冊、甚至是服務治理能力在不同層面基礎設施中出現了重復，需要 Dubbo3 作出適配與調整，以更好的解放業務開發效率，利用好這些基礎能力。

其次，是 Dubbo 在微服務架構中的最基本的能力：RPC 遠程通信。通信協議和數據傳輸格式的標準化應該算是 Dubbo2 面臨的又一重要挑戰，在云原生背影下，協議、數據定義、傳輸格式的標準化和穿透能力成為更需要優先考慮的指標，縱然私有協議具有更高效、靈活的潛力，但考慮到云原生下多語言、組件間互通、網關等代理設備友好性、避免廠商鎖定等訴求，在 Dubbo3 中私有協議都應該被摒棄，轉而擁抱基于 HTTP/2 的更通用的協議，采用跨語言的更通用的數據定義和傳輸格式。

最后，是關于服務治理能力，Dubbo 的服務治理能力應該充分結合底層基礎設施的特點，比如之前綁定 ip 的流量過濾方案在地址不固定的 Kubernetes 平臺就已不再適用，另外，流量治理也要充分的與調度平臺的灰度發布、動態擴縮容能力整合起來；考慮到未來微服務可能會有多種不同的部署形態（下文會講到），Dubbo3 應該制定一種能適用于各種部署形態的路由規則。

從云原生視角來說，Dubbo3 的核心能力基本上也就成圍繞以上幾點分析展開的，主要涉及：抽象全新的服務發現模型、定義下一代的更能用的 RPC 協議與數據傳輸格式、服務治理能力重構等。接下來，我們就看看 3.0 preview 中這些能力的具體實現。

Preview 版本功能速覽

就在今天，Dubbo?3.0.0.preview?版本正式通過了?Apache?社區投票并完成了正式發布，作為?3.0?的首個發布版本，代表了社區 3.0 版本的全面啟動，也展示了未來 3.0 的發展方向。當然，我們要意識到?preview?版本還遠未達到生產可用，它只是為了讓大家快速、方便了解?Dubbo3?的一個預覽版本，離正式版本甚至?alpha?版本還有一段時間要走，具體大家可關注文后的 Dubbo Roadmap。

以下 preview 版本發布的幾個核心特性：

• 全新的服務發現模型

• 下一代基于 HTTP/2 的 RPC 協議：Triple

• 服務治理重構：全新路由規則

• 性能提升

  • 百萬節點級水平擴容

  • 調用鏈路 QPS 性能提升

在 preview 以上能力中，特別值得注意的是得益于 Dubbo3 與 HSF 的融合，Dubbo3 的整體性能也有望得到大幅提升。

Preview 版本是從架構層面對 Dubbo 的一次全面升級，接下來，社區一方面會從功能完善度、穩定性等幾個方面繼續增強 3.0 版本，并將在 6 月份發布首個穩定版本，另一方面社區將兌現更多新的功能。首先，接下來即將交付的是 Kubernetes Service 集成，而 Proxyless Mesh、基于反壓的智能流量調度等功能正在前期的調研或開發階段。

下面，我們就選取以上三個核心功能，深入了解它們的實現機制。

1. 全新服務發現模型

下圖是 Dubbo2 的服務發現模型：Provider 注冊服務地址，Consumer 經過注冊中心協調并發現服務地址，進而對地址發起通信，這是被絕大多數微服務框架的經典服務發現流程。而 Dubbo2 的特殊之處在于，它把 “RPC 接口”的信息也融合在了地址發現過程中，而這部分信息往往是和具體的業務定義密切相關的。

而在接入云原生基礎設施后，基礎設施融入了微服務概念的抽象，容器化微服務被編排、調度的過程即完成了在基礎設施層面的注冊。如下圖所示，基礎設施即承擔了注冊中心的職責，又完成了服務注冊的動作，而 “RPC 接口”這部分信息，由于與具體的業務相關，不可能也不適合被基礎設施托管。

在這樣的場景下，對 Dubbo3 的服務注冊發現機制提出了兩個要求：

Dubbo3 需要在原有服務發現流程中抽象出通用的、與業務邏輯無關的地址映射模型，并確保這部分模型足夠合理，以支持將地址的注冊行為和存儲委托給下層基礎設施；

Dubbo3 特有的業務接口同步機制，是 Dubbo3 需要保留的優勢，需要在 1 中定義的新地址模型之上，通過框架內的自有機制予以解決。

這樣設計的全新的服務發現模型，在架構兼容性、可伸縮性上都給 Dubbo3 帶來了更大的優勢。

在架構兼容性上，如上文所述，Dubbo3 復用下層基礎設施的服務抽象能力成為了可能；另一方面，如 Spring Cloud 等業界其它微服務解決方案也沿用這種模型，在打通了地址發現之后，使得用戶探索用 Dubbo 連接異構的微服務體系成為了一種可能。

Dubbo3 服務發現模型更適合構建可伸縮的服務體系，這點要如何理解？這里先舉個簡單的例子，來直觀的對比 Dubbo2 與 Dubbo3 在地址發現流程上的數據流量變化：假設一個微服務應用定義了 100 個接口（Dubbo 中的服務），則需要往注冊中心中注冊 100 個服務，如果這個應用被部署在了 100 臺機器上，那這 100 個服務總共會產生 100 * 100 = 10000 個虛擬節點；而同樣的應用，對于 Dubbo3 來說，新的注冊發現模型只需要 1 個服務（只和應用有關和接口無關）， 只注冊和機器實例數相等的 1 * 100 = 100 個虛擬節點到注冊中心。在這個簡單的示例中，Dubbo 所注冊的地址數量下降到了原來的 1 / 100，對于注冊中心、訂閱方的存儲壓力都是一個極大的釋放。更重要的是，地址發現容量徹底與業務 RPC 定義解藕開來，整個集群的容量評估對運維來說將變得更加透明：部署多少臺機器就會有多大負載，不會像 Dubbo2 一樣，因為業務 RPC 重構就會影響到整個集群服務發現的穩定性。

2. 下一代通信協議：Triple

我們將 Dubbo3 的新協議命名為 Triple，有代表第 3 代協議的意思。在云原生背景下，Triple 協議需要解決兩大問題：

• 通信協議和數據傳輸格式的標準化問題。這涉及到 RPC 協議、數據定義、數據傳輸等環節，未來可移植性、不被廠商鎖定會成為每個上云企業用戶的訴求，組件內的私有協議和特有數據格式，必然會成為很多用戶選型的顧慮。

• 穿透性、通用性問題。在 Mesh 等架構設想下，微服務甚至所有組件的通信都要經過 sidecar 代理轉發，理論上，Sidecar 是要透明的轉發流量的（收到什么就轉發什么），起碼 payload 不應該是 Sidecar 關注的；而 Sidecar 在某些時候也需要感知流量內容的，因為它要基于些做流量的調度，這個時候，Triple 就要做到足夠通用 – 讓所有的 Sidecar 都能在預期的地方取到其關注的元數據，而不用解析整個 payload。

除了以上兩個核心問題，Triple 協議還需要被設計用來支持更多的業務語義。

• 協議應該提供更完善的請求模型，除了 Request/Response 模型，還應該支持 Streaming 和 Bidirectional。

• 在性能上，新的協議應該保留 request Id 機制，以避免 HOL 帶來的性能損耗。

• 新協議應該易于擴展，包括但不限于 Tracing、Monitoring、BackPressure 等支持。

基于以上需求，Triple 協議是完全基于 HTTP/2 之上構建的，另外，Triple 協議將會做到完全兼容 gRPC 協議；在服務定義、數據格式定義以及傳輸格式上，Triple 將更增加對 Protobuf 的支持。

3. 統一的路由規則

Dubbo3 會對服務治理規則進行全面的重構，以更好的適應云原生基礎設施的變革。

當前的 3.0 preview 版本提供了一個重構后的路由規則機制原型，雖然當前版本的實現還需要繼續增強，但從設計理念上，我們可以解讀出：Dubbo3 期望提供一種跨平臺、跨語言、跨多種部署架構的通用路由規則。

隨著微服務對治理需求的挖掘，Dubbo2 路由規則除了在語義表達上不能涵蓋所有場景之外，更為重要的是，其基于特定語言、特定主機 ip 的過濾機制，已不再適應底層調度平臺的工作機制，Dubbo3 需要引入一種全新設計的路由規則。而對于“跨多種部署架構” 這個點，我們設想未來以 Dubbo 構建的微服務會有三種部署架構：傳統 SDK、基于 Sidecar 的 Service Mesh以及脫離 Sidecar 的 Service Mesh，這三種部署形態都將由 Dubbo3 統一的路由規則進行治理。

• 基于 Sidecar 的 Service Mesh，經典的 Mesh 架構，獨立的 sidecar 運行時接管所有的流量。

• 脫離 Sidecar 的 Service Mesh，變種 Mesh 架構，沒有 sidecar 運行時，富 SDK 直接通過 xDS 與控制面通信，我們將在后續發布關于 Proxyless 模式更詳細的解讀。

實踐中的 Dubbo3

云原生微服務變革在各大廠商內部早已展開，相比于當前開源社區的?preview?版本，Dubbo3 在阿里巴巴的開發與實踐已經在逐步鋪開：部分功能已經在阿里巴巴的部分業務線上得到了規?；炞C（考拉），并且更多的功能和業務線也將進入試點、推廣階段（餓了么、釘釘等）。有一點是值得特別提及的是：在接下來阿里巴巴的微服務架構升級戰略中，Dubbo3 將成為阿里巴巴經濟體未來唯一的標準服務框架，它將逐步在所有業務線取代 HSF 和 Dubbo2，并且我們期待在接下來的 1-2 年 Dubbo3 內能覆蓋大多數重要的業務線。

說在這里，有必要提一下阿里巴巴的微服務框架演進歷程。大概在 2011 年，阿里巴巴開源了 Dubbo2 這一款服務框架并獲得極大成功，在 Dubbo2 開源不久，在阿里巴巴內部又發展出了一款全新的服務框架 – HSF，兩者在設計理念上是高度相似的，而經過這么些年的發展，HSF 得以跟隨阿里巴巴的業務系統更快速的成長，由其是在大集群、大流量治理下展現出了更好的性能和穩定性。在阿里云原生微服務戰略下，整合各個優秀的框架并發展統一品牌的 Dubbo3 被納入發展規劃，在此背景下，Dubbo3 實現了Dubbo2 與 HSF 的融合，并將推動實現內、外技術棧的統一。

除了阿里之外，工商銀行等標桿用戶也已啟動了對 Dubbo3 項目的試點。從社區角度來說，preview 預覽版本的發布只是開始，未來隨著阿里巴巴、工商銀行等更多標桿用戶的全面落地，將推動項目更快、更高質量的發展，助力項目保持持續的創新能力和社區生命力。

未來規劃（Roadmap）

以下是 Dubbo3 的 Roadmap，截止此文發稿，社區已經完成了 3.0 preview 版本的發布。

在 6 月份，我們期望能迎來 Dubbo3 的首個社區正式版本。

隨后，一直到下半年的 11 月份，我們將重點投入在對 Kubernetes、ServiceMesh 架構的支持上，中間當然也包括了對服務治理規則的全面重構。

在此之后，我們將開始在服務柔性上的嘗試，以期提供一種能更高效的利用資源且能提高系統穩定性的流量高度機制。

本文開篇關于云原生微服務變革部分思想引自阿里云高級技術專家、CNCF TOC 張磊 《Microservices - A Cloud Native View》一文分享。

點擊直達GitHub 查看 Dubbo 3.0.0.preview：https://github.com/apache/dubbo/releases/tag/3.0.0.preview

總結

以上是生活随笔為你收集整理的透过 3.0 Preview 看 Dubbo 的云原生变革的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。