作者 | 遠雲
三位一體
2020年底，阿里雲提出了“三位一體”的理念，目標是希望將“自研技術”、“開源項目”、“商業產品”形成統一的技術體系，令技術的價值可以達到最大化。
阿里集團內部的 HSF 框架在經歷了多年雙十一流量洪峯的考驗後，鍛煉出了高性能和高可用的核心競爭力。而對於 Dubbo，作爲國內外最受歡迎的服務治理框架之一，它的開源親和性就不用再多說了。
Dubbo 3.0 作爲三位一體架構的首推方案，在集團內被寄予厚望。它完美融合了內部 HSF 的特性，天然擁有高性能、高可用的核心能力，我們期望用它來解決內部落地問題，做到技術棧統一。目前在考拉已經大規模落地，未來也會在衆多核心場景進行落地，並承載 618、雙十一等複雜的業務場景。
Dubbo 3.0 帶來的好處
在具體說明 Dubbo 3.0 的變化細節之前，先從兩個方面說一說升級到了 Dubbo 3.0 能帶來什麼好處。
首先是，Dubbo 3.0 會着力提升大規模集羣實踐中的性能與穩定性，通過優化數據存儲方式來降低單機資源損耗，並基於此保證超大規模集羣的水平擴容的情況下集羣的穩定性。同時，Dubbo 3.0 提出了柔性集羣的概念，能夠在異構體系下有效保證和提高全鏈路總體的可靠性和資源的利用率。
第二點是 Dubbo 3.0 代表着 Dubbo 全面擁抱雲原生的里程碑。當前 Dubbo 在國內外有着基數巨大的用戶羣體，而隨着雲原生時代的到來，這些用戶上雲的需求越來越強烈。Dubbo 3.0 將提供一整套的解決方案、遷移路徑與最佳實踐，來幫助企業實現雲原生轉型，從而享受雲原生帶來的紅利。
1、業務收益
那麼站在業務應⽤的視角來看，如果升級到 Dubbo 3.0，能獲得哪些具體的收益呢?
首先，在性能與資源利用率⽅面，Dubbo 3.0 能有效降低框架帶來的額外資源消耗，從而⼤幅提升資源利用率。
從單機視⻆，Dubbo 3.0 能節省約 50% 的內存佔⽤；從集羣視角，Dubbo 3.0 能⽀持的集羣實例規模以百萬計，爲未來更大規模的業務擴容打下基礎；而 Dubbo 3.0 對 Reactive Stream 通信模型的支持，在⼀些業務場景下能帶來整體吞吐量的⼤幅提升。
其次，Dubbo 3.0 給業務架構升級帶來了更多的可能性。最直觀的就是通信協議的升級，給業務架構帶來了更多選擇。
Dubbo 原來的協議其實在⼀定程度上束縛了微服務接⼊⽅式。舉個例子，移動端、前端業務要接入 Dubbo 的後端服務，需要經過網關層的協議轉換；再比如，Dubbo 只⽀持 request-response 模式的通信，這使得⼀些需要流式傳輸或反向通信的場景⽆法得到很好的支持。
最後，Dubbo 3.0 給業務側的雲原生升級帶來了整體的解決方案。不論是底層基礎設施升級帶來的被動變化，還是業務爲解決痛點問題進行的主動升級，當業務升級到雲原生，Dubbo 3.0 通過給出雲原生解決方案，可以幫助業務產品快速接入雲原生。
Dubbo 3.0 概覽
在明確了升級到 Dubbo 3.0 能夠帶來的收益之後，來看看 Dubbo 3.0 有哪些具體的改動。
1、支持全新的服務發現模型。Dubbo 3.0 嘗試從應用模型入手，對其雲原生主流設計模型優化其存儲結構，避免在模型上帶來互通問題。新模型在數據組織上高度壓縮，能有效提高性能和集羣的可伸縮性。
2、提出了下一代 RPC 協議 —— Triple。這是一個基於 HTTP/2 設計的完全兼容 gRPC 協議的開放性新協議，由於是基於 HTTP/2 設計的，具有極高的網關友好型和穿透性，完全兼容 gRPC 協議使得其在多語言互通方面上天然具有優勢。
3、提出了統一治理規則。這套規則面向雲原生流量治理，能夠覆蓋傳統 SDK 部署、Service Mesh 化部署、VM 虛擬機部署、Container 容器部署等一系列場景。一份規則治理全部場景可以大大降低流量治理成本，使得異構體系下的全局流量治理得到統一。
4、提供接入 Service Mesh 的解決方案。面向 Mesh 場景，Dubbo 3.0 提出了兩種接入方式：一種是 Thin SDK 模式，部署模型和當前 Service Mesh 主流部署場景完全一樣，而 Dubbo 將進行瘦身，屏蔽掉與 Mesh 相同的治理功能，僅保留核心的 RPC 能力；第二種是 Proxyless 模式，Dubbo 將接替 Sidecar 的工作職責，主動與控制面進行通信，基於 Dubbo 3.0 的統一治理規則，應用雲原生流量治理功能。
應用級服務註冊發現
應用級服務發現模型
應用級服務發現模型的原型其實最早在 Dubbo 2.7.6 版本中已經提出來了，經過一段時間的迭代，最終形成了 Dubbo 3.0 中一個較爲穩定的模型。
在 Dubbo 2.7 及以前版本中，應用進行服務註冊和發現時，都是以接口爲粒度，每個接口都會對應在註冊中心上的一條數據，不同的機器會註冊上屬於當前機器的元數據信息或者接口級別的配置信息，如序列化、機房、單元、超時配置等。
所有提供此服務的服務端在進行重啓或者發佈時，都會在接口粒度獨立地變更。舉個例子，一個網關類應用依賴了上游應用的 30 個接口，當上遊應用在發佈時，就有 30 個對應的地址列表在進行機器的上線和下線。
以接口作爲註冊發現的第一公民的方式是最早的 SOA 或微服務的拆分方式，提供了單一服務、單一節點的獨立和動態變更能力。隨着業務的發展，單一應用依賴的服務數在不斷增多，每個服務提供方的機器數量也由於業務或容量原因不斷增長，從客戶端整體上看，依賴的總服務地址數迅速上漲。根據這種情況，可以考慮從註冊發現的流程設計上優化。
這裏注意有兩個特徵：
- 隨着單體應用拆分爲多微服務應用的基本完成，大規模的服務拆分和重組已經不再是痛點，大部分接口都只被一個應用提供或者固定幾個應用提供。
- 大量用於標誌地址信息的 URL 都是存在極大冗餘的，如超時時間、序列化等。這些配置變更頻率極低，卻在每個 URL 中都出現。
結合以上特徵，最終應用級註冊發現被提出了，即以應用作爲註冊發現的基本維度。和接口級的主要區別是，原來一個應用如果提供了 100 個接口，需要在註冊中心上註冊 100 個節點；如果這個應用有 100 臺機器，那每次發佈，對於它的客戶端來說都是 10000 個虛擬節點的變更。而應用級註冊發現則只需要 1 個節點， 每次發佈只變更 100 個虛擬節點。對於依賴服務數多、機器多的應用而言，是幾十到上百分之一數量級的規模下降，內存佔用上也將至少下降一半。
然而，技術方案的設計不僅僅需要考慮功能正確，還需要考慮現有業務的升級。因此，升級到應用級註冊發現的基礎，是在其功能上需要對齊接口級註冊發現的能力。而無論客戶端是否升級或是否開啓應用級註冊發現，前提都是不影響正確的業務調用。
爲了提供這個保證，我們設計了一個新的組件，元數據中心，用於管理兩部分數據：
- 接口應用映射關係：上報和查詢接口到應用的映射，可以決定客戶端是否啓用應用級，避免業務代碼變更；
- 應用級元數據快照：當一個應用不同接口之間使用的配置不同就會出現數據的分化，因此在應用級方案裏，提出了元數據快照的概念，即每個應用在每次發佈時都會統一生成一份元數據快照，這個快照包含當前應用的元數據版本以及當前應用提供的所有接口的配置。這個快照 ID 會存儲在 URL 中，這樣既提供了動態變更能力， 又在量級上減少了數據存儲對內存的壓力。
最後，由於這個新的服務發現與 Spring Cloud、Service Mesh 等體系下的服務發現模型是高度相似的，因此 Dubbo 可以從註冊中心層面與其他體系下的節點實現互發現。
Dubbo 3.0-雲原生&阿里背書、易用
Dubbo 3.0 的定位是成爲雲原生時代的最佳微服務框架。目前可以看到的幾個趨勢有 K8s 成爲資源調度的事實標準、Mesh 化成爲主流以及規模上的急速增長等。這些趨勢的存在都對 Dubbo 提出了更高的要求。
1、用戶如何在 K8s 上更方便地部署和調用 Dubbo 服務是必須要解決的問題，要解決這個問題，統一的協議和數據交換格式是必須前提。2、Mesh 化的流行帶來了多元化問題，即原生 Dubbo 和 Mesh 化 Dubbo 如何共存，多語言的場景如何支持。3、規模的增長會給整個 Dubbo 架構帶來更大的挑戰，無論是註冊中心等組件，還是客戶端，都會有更多的數據和調用量。
如何在保持穩定的前提下，提供更高效的服務是 Dubbo 演進的重中之重。
這些雲原生時代帶來的挑戰，促成了 Dubbo 發展到下一代：新協議、K8s 基礎架構支持、多語言支持和規模化。
1、下一代RPC協議
作爲 RPC 框架最基礎的能力是完成跨業務進程的服務調用，將服務組成鏈、組成網，這其中最核心的載體就是 RPC 協議。
同時，由於與業務數據的緊密耦合，RPC 協議的設計與實現，也在一些方面直接決定了業務架構，比如從終端設備到後端的交互、微服務架構中多語言的採用、服務間的數據傳輸模型等。
Dubbo 2 提供了 RPC 的核心語義，包括協議頭、標誌位、請求 ID 以及請求/響應數據。但在雲原生時代，Dubbo 2 協議主要面臨兩個挑戰：一是生態不互通，用戶很難直接理解二進制的協議；二是對 Mesh 等網關型組件不夠友好，需要完整的解析協議才能獲取到所需要的調用元數據，如一些 RPC 上下文，從性能到易用性方面都會面臨挑戰。
Dubbo 作爲服務框架，其最重要的還是提供遠程通信能力。⽼版本 Dubbo 2 RPC 協議的設計與實現，已在實踐中被證實在⼀些⽅面限制了業務架構的發展，⽐如從終端設備到後端服務的交互、微服務架構中多語言的採⽤用、服務間的數據傳輸模型等。
在支持已有的功能和解決存在的問題的前提下，下一代的協議需要有以下特性：
- 協議需要解決跨語言互通的問題。傳統的多語言多 SDK 模式和 Mesh 化跨語言模式都需要一種更通用易擴展的數據傳輸格式。
- 協議應該提供更完善的請求模型，除了 Request/Response 模型，還應該支持 Streaming 和 Bidirectional。
- 在性能上保留 request Id 機制，以避免隊頭阻塞帶來的性能損耗。
- 易擴展，包括但不限於 Tracing/ Monitoring 等支持，也應該能被各層設備識別，降低用戶理解難度。
基於這些需求，HTTP2/protobuf 的組合是最符合的。提到這兩個的組合，可能很容易就會想到 gRPC 協議。新一代的協議和 gRPC 的關係如下：
1、Dubbo 新協議是基於 GRPC 擴展的協議，這也保證了在生態系統上新協議和 GRPC 是能夠互通和共享的。
2、在第一點的基礎上，Dubbo 新協議將更原生的支持 Dubbo 的服務治理，提供更大的靈活性。
3、在序列化方面，由於目前大多數應用方還沒有使用 Protobuf ，所以新協議會在序列化方面給予足夠的支持，平滑的適配現有序列化，方便遷移到 Protobuf。
4、在請求模型上，新協議將原生支持 Reactive，這也是 gRPC 協議所不具備的。
2、Service Mesh
爲了使 Dubbo 在 Service Mesh 體系下落地，在參考了衆多的方案之後，最終確定了最適合 Dubbo 3.0 的兩種形態的 Mesh 方案。⼀種是經典的基於 Sidecar 的 Service Mesh，另⼀種是無 Sidecar 的 Proxyless Mesh。
對於 Sidecar Mesh 方案，其部署方式和當前主流 Service Mesh 部署方案一致。Dubbo 3.0 的重點是儘量給業務應用提供完全透明的升級體驗，不止是編程視角的無感升級，還包括通過 Dubbo 3.0 輕量化、Triple 協議等，讓整個調用鏈路上的損耗與運維成本也降低到最低。這個方案也被稱爲 Thin SDK 方案，而 Thin 的地方就是在於去除了所有不需要的組件。
Proxyless Mesh 部署方案則是 Dubbo 3.0 規劃的另⼀種 Mesh 形態，目標是不需要啓動 Sidecar，由傳統 SDK 直接與控制面交互。
設想一下針對以下⼏種場景會⾮常適用 Proxyless Mesh 部署方案：
- 業務方期望升級 Mesh 方案，但卻無法接受由於 Sidecar 進行流量劫持所帶來的性能損耗，這種情況常見於核心業務場景
- 期望降低 Sidecar 運維成本，降低系統複雜度
- 遺留系統升級緩慢，遷移過程漫長，多種部署架構⻓期共存
- 多種部署環境，這裏的多種部署環境包括瞭如 VM 虛擬機、Container 容器等多種部署方式，也包括了多種類型應用混合部署，例如 Thin SDK 與 Proxyless 方案混合部署，對性能敏感應用部署 Proxyless 模式，對於周邊應用採用 Thin SDK 部署方案，多種數據面共同由統一控制面進行調度。
將這兩種形態統籌來看，在不同的業務場景、不同的遷移階段、不同的基礎設施保障情況下， Dubbo 都會有 Mesh ⽅案可供選擇，⽽這進⼀步的都可以通過統⼀的控制⾯進行治理。
未來的部署
1、部署在K8s上
上圖是 Dubbo 3.0 未來期望在 Kubernetes 上的部署方案。Dubbo 3.0 將在服務發現模型上對其 Kubernetes 的原生服務，支持不需要部署獨立的註冊中心就可以實現互相調用。
2、部署在Istio上
上圖是 Dubbo 3.0 未來期望在 Istio 上的部署方案。這裏採用的是 Thin SDK 與 Proxyless 混合部署模式，如圖中的 Pod 1 和 Pod 3，數據流量由 Dubbo Service 直接發出，而 Pod 2 部署的是 Thin SDK 模式，流量由 Sidecar 進行攔截後流出。
柔性增強規劃
雲原生帶來了技術標準化的重大變革。如何讓應用在雲上更簡單地創建和運行，並具備可彈性擴展的能力，是所有云原生基礎組件的核心目標。藉助雲原生技術帶來的彈性能力，應用可以在極短時間內擴容出一大批機器以支撐業務需要。
比如爲了應對零點秒殺場景或者突發事件，應用本身往往需要數千甚至數萬的機器數來提升性能以滿足用戶的需要，但是在擴容的同時也帶來了諸如集羣節點極多導致的節點異常頻發、服務容量受多種客觀因素影響導致節點服務能力不均等一系列的問題，這些都是在雲原生場景下集羣大規模部署時會遇到的問題。
Dubbo 期待基於一種柔性的集羣調度機制來解決這些問題。這種機制主要解決的問題有兩個方面，一是在節點異常的情況下，分佈式服務能夠保持穩定，不出現雪崩等問題；二是對於大規模的應用，能夠以最佳態運行，提供較高的吞吐量和性能。
- 從單一服務視角看，Dubbo 期望的目標是對外提供一種壓不垮的服務，即是在請求數特別高的情況下，可以通過選擇性地拒絕一些的請求來保證總體業務的正確性、時效性。
- 從分佈式視角看，要儘可能降低因爲複雜的拓撲、不同節點性能不一導致總體性能的下降，柔性調度機制能夠以最優的方式動態分配流量，使異構系統能夠根據運行時的準確服務容量合理分配請求，從而達到性能最優。
Dubbo 3.0 路線圖
Apache Dubbo 3.0.0 作爲捐給 Apache 後的一個里程碑版本已經在今年 6 月份正式發佈了，這代表着 Apache Dubbo 全面擁抱雲原生的一個節點。
在 2021 年 11 月我們會發布 Apache Dubbo 3.1 版本，屆時我們會帶來 Apache Dubbo 在 Mesh 場景下部署的實現與實踐。
在 2022 年 3 月我們會發布 Apache Dubbo 3.2 版本，在這個版本中我們將帶來全新的大規模應用部署下智能流量調度機制，提高系統穩定性與資源利用率。
最後，Apache Dubbo 3.0 已經和阿里巴巴集團內部的 RPC 框架實現了融合，期望用它來解決內部落地問題，做到技術棧統一。未來，Apache Dubbo 3.0 將大規模落地阿里集團，承載 618、雙十一等複雜業務場景。
本文爲阿里雲原創內容，未經允許不得轉載。