簡介： 做過微服務開發的開發者相信對 Dubbo 都不陌生，Dubbo 是一款能幫助我們快速解決微服務開發、通信以及流量治理的框架。相比於之前只限定在 Java 語言範圍內，Dubbo 的多語言版本在這兩年呈現了良好的發展勢頭，其中，Dubbo Go 語言版本在功能、穩定性各個方面都已非常完備，其它幾種主流的多語言版本在社區也有提供。
作者 | 陸龜
來源 | 阿里巴巴雲原生公衆號
本文整理自作者在3月20日雲原生中間件 Meetup 上海站的分享。回覆關鍵字“中間件”可以獲取視頻錄播地址和 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 這樣一個和微服務實踐密切相關的框架所面臨的變革與挑戰。
微服務在讓業務開發演進更靈活、快捷的同時，也帶來了一些它獨有的特徵和需求：如微服務之後組件數量越來越多，如何解決各個組件的穩定性，如何快速的水平擴容等。
這些訴求，尤其是運維、交付相關訴求，如微服務組件的生命週期、網絡、通用服務綁定、服務狀態管理等，並不應該是開發人員關注的重點，因爲它們已經完全脫離了業務邏輯，開發人員更願意專注在有業務價值組件上，但這個層次的訴求卻是實現微服務交付的關鍵能力。開發者期望由底層基礎設施來提供此類能力支持，而處於不同階段發展的基礎設施卻不一定具備這樣的能力，因此，在微服務軟件架構和底層基礎設施之間就出現了一條鴻溝，我們需要有組件能填補這一鴻溝，讓微服務組件能更好的接入底層基礎設施。
這裏從一個更抽象的層面，嘗試用兩條發展曲線演示了軟件架構訴求與底層基礎設施能力豐富度之間的關係。總體上，兩者之間的發展關係可拆分爲兩個階段。
在第一個階段，軟件架構（這條紅色的線）從單體應用、到面向服務的軟件架構、再到微服務架構，快速演進，從而也提出了上文我們講到的對基礎設施對交付的訴求，這個時候基礎設施層還多是以定製化的方式來滿足軟件架構的訴求，如過往的集中化的 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 在阿里巴巴的開發與實踐已經在逐步鋪開：部分功能已經在阿里巴巴的部分業務線上得到了規模化驗證（考拉），並且更多的功能和業務線也將進入試點、推廣階段（餓了麼、釘釘等）。有一點是值得特別提及的是：在接下來阿里巴巴的微服務架構升級戰略中，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