做者 | 遠雲前端
三位一體
2020年末，阿里雲提出了「三位一體」的理念，目標是但願將「自研技術」、「開源項目」、「商業產品」造成統一的技術體系，令技術的價值能夠達到最大化。 阿里集團內部的 HSF 框架在經歷了多年雙十一流量洪峯的考驗後，鍛煉出了高性能和高可用的核心競爭力。而對於 Dubbo，做爲國內外最受歡迎的服務治理框架之一，它的開源親和性就不用再多說了。編程
Dubbo 3.0 做爲三位一體架構的首推方案，在集團內被寄予厚望。它完美融合了內部 HSF 的特性，自然擁有高性能、高可用的核心能力，咱們指望用它來解決內部落地問題，作到技術棧統一。目前在考拉已經大規模落地，將來也會在衆多核心場景進行落地，並承載 61八、雙十一等複雜的業務場景。後端
Dubbo 3.0 帶來的好處
在具體說明 Dubbo 3.0 的變化細節以前，先從兩個方面說一說升級到了 Dubbo 3.0 能帶來什麼好處。架構
首先是，Dubbo 3.0 會着力提高大規模集羣實踐中的性能與穩定性，經過優化數據存儲方式來下降單機資源損耗，並基於此保證超大規模集羣的水平擴容的狀況下集羣的穩定性。同時，Dubbo 3.0 提出了柔性集羣的概念，可以在異構體系下有效保證和提升全鏈路整體的可靠性和資源的利用率。框架
第二點是 Dubbo 3.0 表明着 Dubbo 全面擁抱雲原生的里程碑。當前 Dubbo 在國內外有着基數巨大的用戶羣體，而隨着雲原生時代的到來，這些用戶上雲的需求愈來愈強烈。Dubbo 3.0 將提供一整套的解決方案、遷移路徑與最佳實踐，來幫助企業實現雲原生轉型，從而享受雲原生帶來的紅利。less
一、業務收益
那麼站在業務應⽤的視角來看，若是升級到 Dubbo 3.0，能得到哪些具體的收益呢?運維
首先，在性能與資源利用率⽅面，Dubbo 3.0 能有效下降框架帶來的額外資源消耗，從而⼤幅提高資源利用率。分佈式
從單機視⻆，Dubbo 3.0 能節省約 50% 的內存佔⽤；從集羣視角，Dubbo 3.0 能⽀持的集羣實例規模以百萬計，爲將來更大規模的業務擴容打下基礎；而 Dubbo 3.0 對 Reactive Stream 通訊模型的支持，在⼀些業務場景下能帶來總體吞吐量的⼤幅提高。ide
其次，Dubbo 3.0 給業務架構升級帶來了更多的可能性。最直觀的就是通訊協議的升級，給業務架構帶來了更多選擇。微服務
Dubbo 原來的協議其實在⼀定程度上束縛了微服務接⼊⽅式。舉個例子，移動端、前端業務要接入 Dubbo 的後端服務，須要通過網關層的協議轉換；再好比，Dubbo 只⽀持 request-response 模式的通訊，這使得⼀些須要流式傳輸或反向通訊的場景⽆法獲得很好的支持。
最後，Dubbo 3.0 給業務側的雲原生升級帶來了總體的解決方案。不管是底層基礎設施升級帶來的被動變化，仍是業務爲解決痛點問題進行的主動升級，當業務升級到雲原生，Dubbo 3.0 經過給出雲原生解決方案，能夠幫助業務產品快速接入雲原生。
Dubbo 3.0 概覽
在明確了升級到 Dubbo 3.0 可以帶來的收益以後，來看看 Dubbo 3.0 有哪些具體的改動。
一、支持全新的服務發現模型。Dubbo 3.0 嘗試從應用模型入手，對其雲原生主流設計模型優化其存儲結構，避免在模型上帶來互通問題。新模型在數據組織上高度壓縮，能有效提升性能和集羣的可伸縮性。
二、提出了下一代 RPC 協議 —— Triple。這是一個基於 HTTP/2 設計的徹底兼容 gRPC 協議的開放性新協議，因爲是基於 HTTP/2 設計的，具備極高的網關友好型和穿透性，徹底兼容 gRPC 協議使得其在多語言互通方面上自然具備優點。
三、提出了統一治理規則。這套規則面向雲原生流量治理，可以覆蓋傳統 SDK 部署、Service Mesh 化部署、VM 虛擬機部署、Container 容器部署等一系列場景。一份規則治理所有場景能夠大大下降流量治理成本，使得異構體系下的全局流量治理獲得統一。
四、提供接入 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 提出了更高的要求。
一、用戶如何在 K8s 上更方便地部署和調用 Dubbo 服務是必需要解決的問題，要解決這個問題，統一的協議和數據交換格式是必須前提。二、Mesh 化的流行帶來了多元化問題，即原生 Dubbo 和 Mesh 化 Dubbo 如何共存，多語言的場景如何支持。三、規模的增加會給整個 Dubbo 架構帶來更大的挑戰，不管是註冊中心等組件，仍是客戶端，都會有更多的數據和調用量。
如何在保持穩定的前提下，提供更高效的服務是 Dubbo 演進的重中之重。
這些雲原生時代帶來的挑戰，促成了 Dubbo 發展到下一代：新協議、K8s 基礎架構支持、多語言支持和規模化。
一、下一代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 的關係以下： 一、Dubbo 新協議是基於 GRPC 擴展的協議，這也保證了在生態系統上新協議和 GRPC 是可以互通和共享的。 二、在第一點的基礎上，Dubbo 新協議將更原生的支持 Dubbo 的服務治理，提供更大的靈活性。 三、在序列化方面，因爲目前大多數應用方尚未使用 Protobuf ，因此新協議會在序列化方面給予足夠的支持，平滑的適配現有序列化，方便遷移到 Protobuf。 四、在請求模型上，新協議將原生支持 Reactive，這也是 gRPC 協議所不具有的。
二、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 ⽅案可供選擇，⽽這進⼀步的均可以經過統⼀的控制⾯進行治理。
將來的部署
一、部署在K8s上
上圖是 Dubbo 3.0 將來指望在 Kubernetes 上的部署方案。Dubbo 3.0 將在服務發現模型上對其 Kubernetes 的原生服務，支持不須要部署獨立的註冊中心就能夠實現互相調用。
二、部署在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 將大規模落地阿里集團，承載 61八、雙十一等複雜業務場景。
社區會盡量保證一個較短的發版週期，及時對已有的問題進行修復。社區衷心地但願歡迎你們向社區提交 issue 和 PR，社區的同窗會盡快進行 review、回覆。感謝你們的支持！
﹀ ﹀ ﹀
想要討論更多與 Dubbo 相關的內容，可搜尋羣號：21976540 加入