簡介： 阿里云在 2020年底提出了“三位一體”理念，目標(biāo)是希望將“自研技術(shù)”、“開源項目”、“商業(yè)產(chǎn)品”形成統(tǒng)一的技術(shù)體系，令技術(shù)的價值可以達到最大化。Dubbo 3.0 作為三位一體架構(gòu)的首推方案，在集團內(nèi)被寄予了厚望。它完美融合了內(nèi)部 HSF 的特性，天然擁有高性能、高可用的核心能力，我們期望用它來解決內(nèi)部落地問題，做到技術(shù)棧統(tǒng)一。本文將分享Dubbo 3.0的演進思路以及如何幫助用戶享受云原生帶來的技術(shù)紅利。

作者 | 遠云

三位一體

2020年底，阿里云提出了“三位一體”的理念，目標(biāo)是希望將“自研技術(shù)”、“開源項目”、“商業(yè)產(chǎn)品”形成統(tǒng)一的技術(shù)體系，令技術(shù)的價值可以達到最大化。

阿里集團內(nèi)部的 HSF 框架在經(jīng)歷了多年雙十一流量洪峰的考驗后，鍛煉出了高性能和高可用的核心競爭力。而對于 Dubbo，作為國內(nèi)外最受歡迎的服務(wù)治理框架之一，它的開源親和性就不用再多說了。

Dubbo 3.0 作為三位一體架構(gòu)的首推方案，在集團內(nèi)被寄予厚望。它完美融合了內(nèi)部 HSF 的特性，天然擁有高性能、高可用的核心能力，我們期望用它來解決內(nèi)部落地問題，做到技術(shù)棧統(tǒng)一。目前在考拉已經(jīng)大規(guī)模落地，未來也會在眾多核心場景進行落地，并承載 618、雙十一等復(fù)雜的業(yè)務(wù)場景。

Dubbo 3.0 帶來的好處

在具體說明 Dubbo 3.0 的變化細節(jié)之前，先從兩個方面說一說升級到了 Dubbo 3.0 能帶來什么好處。

首先是，Dubbo 3.0 會著力提升大規(guī)模集群實踐中的性能與穩(wěn)定性，通過優(yōu)化數(shù)據(jù)存儲方式來降低單機資源損耗，并基于此保證超大規(guī)模集群的水平擴容的情況下集群的穩(wěn)定性。同時，Dubbo 3.0 提出了柔性集群的概念，能夠在異構(gòu)體系下有效保證和提高全鏈路總體的可靠性和資源的利用率。

第二點是 Dubbo 3.0 代表著 Dubbo 全面擁抱云原生的里程碑。當(dāng)前 Dubbo 在國內(nèi)外有著基數(shù)巨大的用戶群體，而隨著云原生時代的到來，這些用戶上云的需求越來越強烈。Dubbo 3.0 將提供一整套的解決方案、遷移路徑與最佳實踐，來幫助企業(yè)實現(xiàn)云原生轉(zhuǎn)型，從而享受云原生帶來的紅利。

1、業(yè)務(wù)收益

那么站在業(yè)務(wù)應(yīng)?的視角來看，如果升級到 Dubbo 3.0，能獲得哪些具體的收益呢?

首先，在性能與資源利用率?面，Dubbo 3.0 能有效降低框架帶來的額外資源消耗，從而?幅提升資源利用率。

從單機視?，Dubbo 3.0 能節(jié)省約 50% 的內(nèi)存占?；從集群視角，Dubbo 3.0 能?持的集群實例規(guī)模以百萬計，為未來更大規(guī)模的業(yè)務(wù)擴容打下基礎(chǔ)；而 Dubbo 3.0 對 Reactive Stream 通信模型的支持，在?些業(yè)務(wù)場景下能帶來整體吞吐量的?幅提升。

其次，Dubbo 3.0 給業(yè)務(wù)架構(gòu)升級帶來了更多的可能性。最直觀的就是通信協(xié)議的升級，給業(yè)務(wù)架構(gòu)帶來了更多選擇。

Dubbo 原來的協(xié)議其實在?定程度上束縛了微服務(wù)接??式。舉個例子，移動端、前端業(yè)務(wù)要接入 Dubbo 的后端服務(wù)，需要經(jīng)過網(wǎng)關(guān)層的協(xié)議轉(zhuǎn)換；再比如，Dubbo 只?持 request-response 模式的通信，這使得?些需要流式傳輸或反向通信的場景?法得到很好的支持。

最后，Dubbo 3.0 給業(yè)務(wù)側(cè)的云原生升級帶來了整體的解決方案。不論是底層基礎(chǔ)設(shè)施升級帶來的被動變化，還是業(yè)務(wù)為解決痛點問題進行的主動升級，當(dāng)業(yè)務(wù)升級到云原生，Dubbo 3.0 通過給出云原生解決方案，可以幫助業(yè)務(wù)產(chǎn)品快速接入云原生。

Dubbo 3.0 概覽

在明確了升級到 Dubbo 3.0 能夠帶來的收益之后，來看看 Dubbo 3.0 有哪些具體的改動。

1、支持全新的服務(wù)發(fā)現(xiàn)模型。Dubbo 3.0 嘗試從應(yīng)用模型入手，對其云原生主流設(shè)計模型優(yōu)化其存儲結(jié)構(gòu)，避免在模型上帶來互通問題。新模型在數(shù)據(jù)組織上高度壓縮，能有效提高性能和集群的可伸縮性。

2、提出了下一代 RPC 協(xié)議 —— Triple。這是一個基于 HTTP/2 設(shè)計的完全兼容 gRPC 協(xié)議的開放性新協(xié)議，由于是基于 HTTP/2 設(shè)計的，具有極高的網(wǎng)關(guān)友好型和穿透性，完全兼容 gRPC 協(xié)議使得其在多語言互通方面上天然具有優(yōu)勢。

3、提出了統(tǒng)一治理規(guī)則。這套規(guī)則面向云原生流量治理，能夠覆蓋傳統(tǒng) SDK 部署、Service Mesh 化部署、VM 虛擬機部署、Container 容器部署等一系列場景。一份規(guī)則治理全部場景可以大大降低流量治理成本，使得異構(gòu)體系下的全局流量治理得到統(tǒng)一。

4、提供接入 Service Mesh 的解決方案。面向 Mesh 場景，Dubbo 3.0 提出了兩種接入方式：一種是 Thin SDK 模式，部署模型和當(dāng)前 Service Mesh 主流部署場景完全一樣，而 Dubbo 將進行瘦身，屏蔽掉與 Mesh 相同的治理功能，僅保留核心的 RPC 能力；第二種是 Proxyless 模式，Dubbo 將接替 Sidecar 的工作職責(zé)，主動與控制面進行通信，基于 Dubbo 3.0 的統(tǒng)一治理規(guī)則，應(yīng)用云原生流量治理功能。

應(yīng)用級服務(wù)注冊發(fā)現(xiàn)

應(yīng)用級服務(wù)發(fā)現(xiàn)模型

應(yīng)用級服務(wù)發(fā)現(xiàn)模型的原型其實最早在 Dubbo 2.7.6 版本中已經(jīng)提出來了，經(jīng)過一段時間的迭代，最終形成了 Dubbo 3.0 中一個較為穩(wěn)定的模型。

在 Dubbo 2.7 及以前版本中，應(yīng)用進行服務(wù)注冊和發(fā)現(xiàn)時，都是以接口為粒度，每個接口都會對應(yīng)在注冊中心上的一條數(shù)據(jù)，不同的機器會注冊上屬于當(dāng)前機器的元數(shù)據(jù)信息或者接口級別的配置信息，如序列化、機房、單元、超時配置等。

所有提供此服務(wù)的服務(wù)端在進行重啟或者發(fā)布時，都會在接口粒度獨立地變更。舉個例子，一個網(wǎng)關(guān)類應(yīng)用依賴了上游應(yīng)用的 30 個接口，當(dāng)上游應(yīng)用在發(fā)布時，就有 30 個對應(yīng)的地址列表在進行機器的上線和下線。

以接口作為注冊發(fā)現(xiàn)的第一公民的方式是最早的 SOA 或微服務(wù)的拆分方式，提供了單一服務(wù)、單一節(jié)點的獨立和動態(tài)變更能力。隨著業(yè)務(wù)的發(fā)展，單一應(yīng)用依賴的服務(wù)數(shù)在不斷增多，每個服務(wù)提供方的機器數(shù)量也由于業(yè)務(wù)或容量原因不斷增長，從客戶端整體上看，依賴的總服務(wù)地址數(shù)迅速上漲。根據(jù)這種情況，可以考慮從注冊發(fā)現(xiàn)的流程設(shè)計上優(yōu)化。

這里注意有兩個特征：

• 隨著單體應(yīng)用拆分為多微服務(wù)應(yīng)用的基本完成，大規(guī)模的服務(wù)拆分和重組已經(jīng)不再是痛點，大部分接口都只被一個應(yīng)用提供或者固定幾個應(yīng)用提供。
• 大量用于標(biāo)志地址信息的 URL 都是存在極大冗余的，如超時時間、序列化等。這些配置變更頻率極低，卻在每個 URL 中都出現(xiàn)。

結(jié)合以上特征，最終應(yīng)用級注冊發(fā)現(xiàn)被提出了，即以應(yīng)用作為注冊發(fā)現(xiàn)的基本維度。和接口級的主要區(qū)別是，原來一個應(yīng)用如果提供了 100 個接口，需要在注冊中心上注冊 100 個節(jié)點；如果這個應(yīng)用有 100 臺機器，那每次發(fā)布，對于它的客戶端來說都是 10000 個虛擬節(jié)點的變更。而應(yīng)用級注冊發(fā)現(xiàn)則只需要 1 個節(jié)點， 每次發(fā)布只變更 100 個虛擬節(jié)點。對于依賴服務(wù)數(shù)多、機器多的應(yīng)用而言，是幾十到上百分之一數(shù)量級的規(guī)模下降，內(nèi)存占用上也將至少下降一半。

然而，技術(shù)方案的設(shè)計不僅僅需要考慮功能正確，還需要考慮現(xiàn)有業(yè)務(wù)的升級。因此，升級到應(yīng)用級注冊發(fā)現(xiàn)的基礎(chǔ)，是在其功能上需要對齊接口級注冊發(fā)現(xiàn)的能力。而無論客戶端是否升級或是否開啟應(yīng)用級注冊發(fā)現(xiàn)，前提都是不影響正確的業(yè)務(wù)調(diào)用。

為了提供這個保證，我們設(shè)計了一個新的組件，元數(shù)據(jù)中心，用于管理兩部分數(shù)據(jù)：

• 接口應(yīng)用映射關(guān)系：上報和查詢接口到應(yīng)用的映射，可以決定客戶端是否啟用應(yīng)用級，避免業(yè)務(wù)代碼變更；
• 應(yīng)用級元數(shù)據(jù)快照：當(dāng)一個應(yīng)用不同接口之間使用的配置不同就會出現(xiàn)數(shù)據(jù)的分化，因此在應(yīng)用級方案里，提出了元數(shù)據(jù)快照的概念，即每個應(yīng)用在每次發(fā)布時都會統(tǒng)一生成一份元數(shù)據(jù)快照，這個快照包含當(dāng)前應(yīng)用的元數(shù)據(jù)版本以及當(dāng)前應(yīng)用提供的所有接口的配置。這個快照 ID 會存儲在 URL 中，這樣既提供了動態(tài)變更能力， 又在量級上減少了數(shù)據(jù)存儲對內(nèi)存的壓力。

最后，由于這個新的服務(wù)發(fā)現(xiàn)與 Spring Cloud、Service Mesh 等體系下的服務(wù)發(fā)現(xiàn)模型是高度相似的，因此 Dubbo 可以從注冊中心層面與其他體系下的節(jié)點實現(xiàn)互發(fā)現(xiàn)。

Dubbo 3.0-云原生&阿里背書、易用

Dubbo 3.0 的定位是成為云原生時代的最佳微服務(wù)框架。目前可以看到的幾個趨勢有 K8s 成為資源調(diào)度的事實標(biāo)準(zhǔn)、Mesh 化成為主流以及規(guī)模上的急速增長等。這些趨勢的存在都對 Dubbo 提出了更高的要求。

1、用戶如何在 K8s 上更方便地部署和調(diào)用 Dubbo 服務(wù)是必須要解決的問題，要解決這個問題，統(tǒng)一的協(xié)議和數(shù)據(jù)交換格式是必須前提。2、Mesh 化的流行帶來了多元化問題，即原生 Dubbo 和 Mesh 化 Dubbo 如何共存，多語言的場景如何支持。3、規(guī)模的增長會給整個 Dubbo 架構(gòu)帶來更大的挑戰(zhàn)，無論是注冊中心等組件，還是客戶端，都會有更多的數(shù)據(jù)和調(diào)用量。

如何在保持穩(wěn)定的前提下，提供更高效的服務(wù)是 Dubbo 演進的重中之重。

這些云原生時代帶來的挑戰(zhàn)，促成了 Dubbo 發(fā)展到下一代：新協(xié)議、K8s 基礎(chǔ)架構(gòu)支持、多語言支持和規(guī)模化。

1、下一代RPC協(xié)議

作為 RPC 框架最基礎(chǔ)的能力是完成跨業(yè)務(wù)進程的服務(wù)調(diào)用，將服務(wù)組成鏈、組成網(wǎng)，這其中最核心的載體就是 RPC 協(xié)議。

同時，由于與業(yè)務(wù)數(shù)據(jù)的緊密耦合，RPC 協(xié)議的設(shè)計與實現(xiàn)，也在一些方面直接決定了業(yè)務(wù)架構(gòu)，比如從終端設(shè)備到后端的交互、微服務(wù)架構(gòu)中多語言的采用、服務(wù)間的數(shù)據(jù)傳輸模型等。

Dubbo 2 提供了 RPC 的核心語義，包括協(xié)議頭、標(biāo)志位、請求 ID 以及請求/響應(yīng)數(shù)據(jù)。但在云原生時代，Dubbo 2 協(xié)議主要面臨兩個挑戰(zhàn)：一是生態(tài)不互通，用戶很難直接理解二進制的協(xié)議；二是對 Mesh 等網(wǎng)關(guān)型組件不夠友好，需要完整的解析協(xié)議才能獲取到所需要的調(diào)用元數(shù)據(jù)，如一些 RPC 上下文，從性能到易用性方面都會面臨挑戰(zhàn)。

Dubbo 作為服務(wù)框架，其最重要的還是提供遠程通信能力。?版本 Dubbo 2 RPC 協(xié)議的設(shè)計與實現(xiàn)，已在實踐中被證實在?些?面限制了業(yè)務(wù)架構(gòu)的發(fā)展，?如從終端設(shè)備到后端服務(wù)的交互、微服務(wù)架構(gòu)中多語言的采?用、服務(wù)間的數(shù)據(jù)傳輸模型等。

在支持已有的功能和解決存在的問題的前提下，下一代的協(xié)議需要有以下特性：

• 協(xié)議需要解決跨語言互通的問題。傳統(tǒng)的多語言多 SDK 模式和 Mesh 化跨語言模式都需要一種更通用易擴展的數(shù)據(jù)傳輸格式。
• 協(xié)議應(yīng)該提供更完善的請求模型，除了 Request/Response 模型，還應(yīng)該支持 Streaming 和 Bidirectional。
• 在性能上保留 request Id 機制，以避免隊頭阻塞帶來的性能損耗。
• 易擴展，包括但不限于 Tracing/ Monitoring 等支持，也應(yīng)該能被各層設(shè)備識別，降低用戶理解難度。

基于這些需求，HTTP2/protobuf 的組合是最符合的。提到這兩個的組合，可能很容易就會想到 gRPC 協(xié)議。新一代的協(xié)議和 gRPC 的關(guān)系如下：

1、Dubbo 新協(xié)議是基于 GRPC 擴展的協(xié)議，這也保證了在生態(tài)系統(tǒng)上新協(xié)議和 GRPC 是能夠互通和共享的。

2、在第一點的基礎(chǔ)上，Dubbo 新協(xié)議將更原生的支持 Dubbo 的服務(wù)治理，提供更大的靈活性。

3、在序列化方面，由于目前大多數(shù)應(yīng)用方還沒有使用 Protobuf ，所以新協(xié)議會在序列化方面給予足夠的支持，平滑的適配現(xiàn)有序列化，方便遷移到 Protobuf。

4、在請求模型上，新協(xié)議將原生支持 Reactive，這也是 gRPC 協(xié)議所不具備的。

2、Service Mesh

為了使 Dubbo 在 Service Mesh 體系下落地，在參考了眾多的方案之后，最終確定了最適合 Dubbo 3.0 的兩種形態(tài)的 Mesh 方案。?種是經(jīng)典的基于 Sidecar 的 Service Mesh，另?種是無 Sidecar 的 Proxyless Mesh。

對于 Sidecar Mesh 方案，其部署方式和當(dāng)前主流 Service Mesh 部署方案一致。Dubbo 3.0 的重點是盡量給業(yè)務(wù)應(yīng)用提供完全透明的升級體驗，不止是編程視角的無感升級，還包括通過 Dubbo 3.0 輕量化、Triple 協(xié)議等，讓整個調(diào)用鏈路上的損耗與運維成本也降低到最低。這個方案也被稱為 Thin SDK 方案，而 Thin 的地方就是在于去除了所有不需要的組件。

Proxyless Mesh 部署方案則是 Dubbo 3.0 規(guī)劃的另?種 Mesh 形態(tài)，目標(biāo)是不需要啟動 Sidecar，由傳統(tǒng) SDK 直接與控制面交互。

設(shè)想一下針對以下?種場景會?常適用 Proxyless Mesh 部署方案：

• 業(yè)務(wù)方期望升級 Mesh 方案，但卻無法接受由于 Sidecar 進行流量劫持所帶來的性能損耗，這種情況常見于核心業(yè)務(wù)場景
• 期望降低 Sidecar 運維成本，降低系統(tǒng)復(fù)雜度
• 遺留系統(tǒng)升級緩慢，遷移過程漫長，多種部署架構(gòu)?期共存
• 多種部署環(huán)境，這里的多種部署環(huán)境包括了如 VM 虛擬機、Container 容器等多種部署方式，也包括了多種類型應(yīng)用混合部署，例如 Thin SDK 與 Proxyless 方案混合部署，對性能敏感應(yīng)用部署 Proxyless 模式，對于周邊應(yīng)用采用 Thin SDK 部署方案，多種數(shù)據(jù)面共同由統(tǒng)一控制面進行調(diào)度。

將這兩種形態(tài)統(tǒng)籌來看，在不同的業(yè)務(wù)場景、不同的遷移階段、不同的基礎(chǔ)設(shè)施保障情況下， Dubbo 都會有 Mesh ?案可供選擇，?這進?步的都可以通過統(tǒng)?的控制?進行治理。

未來的部署

1、部署在K8s上

上圖是 Dubbo 3.0 未來期望在 Kubernetes 上的部署方案。Dubbo 3.0 將在服務(wù)發(fā)現(xiàn)模型上對其 Kubernetes 的原生服務(wù)，支持不需要部署獨立的注冊中心就可以實現(xiàn)互相調(diào)用。

2、部署在Istio上

上圖是 Dubbo 3.0 未來期望在 Istio 上的部署方案。這里采用的是 Thin SDK 與 Proxyless 混合部署模式，如圖中的 Pod 1 和 Pod 3，數(shù)據(jù)流量由 Dubbo Service 直接發(fā)出，而 Pod 2 部署的是 Thin SDK 模式，流量由 Sidecar 進行攔截后流出。

柔性增強規(guī)劃

云原生帶來了技術(shù)標(biāo)準(zhǔn)化的重大變革。如何讓應(yīng)用在云上更簡單地創(chuàng)建和運行，并具備可彈性擴展的能力，是所有云原生基礎(chǔ)組件的核心目標(biāo)。借助云原生技術(shù)帶來的彈性能力，應(yīng)用可以在極短時間內(nèi)擴容出一大批機器以支撐業(yè)務(wù)需要。

比如為了應(yīng)對零點秒殺場景或者突發(fā)事件，應(yīng)用本身往往需要數(shù)千甚至數(shù)萬的機器數(shù)來提升性能以滿足用戶的需要，但是在擴容的同時也帶來了諸如集群節(jié)點極多導(dǎo)致的節(jié)點異常頻發(fā)、服務(wù)容量受多種客觀因素影響導(dǎo)致節(jié)點服務(wù)能力不均等一系列的問題，這些都是在云原生場景下集群大規(guī)模部署時會遇到的問題。

Dubbo 期待基于一種柔性的集群調(diào)度機制來解決這些問題。這種機制主要解決的問題有兩個方面，一是在節(jié)點異常的情況下，分布式服務(wù)能夠保持穩(wěn)定，不出現(xiàn)雪崩等問題；二是對于大規(guī)模的應(yīng)用，能夠以最佳態(tài)運行，提供較高的吞吐量和性能。

• 從單一服務(wù)視角看，Dubbo 期望的目標(biāo)是對外提供一種壓不垮的服務(wù)，即是在請求數(shù)特別高的情況下，可以通過選擇性地拒絕一些的請求來保證總體業(yè)務(wù)的正確性、時效性。
• 從分布式視角看，要盡可能降低因為復(fù)雜的拓撲、不同節(jié)點性能不一導(dǎo)致總體性能的下降，柔性調(diào)度機制能夠以最優(yōu)的方式動態(tài)分配流量，使異構(gòu)系統(tǒng)能夠根據(jù)運行時的準(zhǔn)確服務(wù)容量合理分配請求，從而達到性能最優(yōu)。

Dubbo 3.0 路線圖

Apache Dubbo 3.0.0 作為捐給 Apache 后的一個里程碑版本已經(jīng)在今年 6 月份正式發(fā)布了，這代表著 Apache Dubbo 全面擁抱云原生的一個節(jié)點。

在 2021 年 11 月我們會發(fā)布 Apache Dubbo 3.1 版本，屆時我們會帶來 Apache Dubbo 在 Mesh 場景下部署的實現(xiàn)與實踐。

在 2022 年 3 月我們會發(fā)布 Apache Dubbo 3.2 版本，在這個版本中我們將帶來全新的大規(guī)模應(yīng)用部署下智能流量調(diào)度機制，提高系統(tǒng)穩(wěn)定性與資源利用率。

最后，Apache Dubbo 3.0 已經(jīng)和阿里巴巴集團內(nèi)部的 RPC 框架實現(xiàn)了融合，期望用它來解決內(nèi)部落地問題，做到技術(shù)棧統(tǒng)一。未來，Apache Dubbo 3.0 將大規(guī)模落地阿里集團，承載 618、雙十一等復(fù)雜業(yè)務(wù)場景。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的阿里集团业务驱动的升级 —— 聊一聊Dubbo 3.0 的演进思路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。