作者 | 遠雲
三位一體
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、雙十一等複雜業務場景。
社群會盡可能保證一個較短的發版周期，及時對已有的問題進行修複。社群衷心地希望歡迎大家向社群送出 issue 和 PR，社群的同學會盡快進行 review、回複。感謝大家的支援！
﹀
想要讨論更多與 Dubbo 相關的内容，可搜尋群号：21976540 加入