一文速覽 Dubbo 3.0

ApacheDubbo發表於2022-12-17

本文將帶你快速瞭解 Dubbo3 的設計背景、總體架構與核心特性、與典型使用者如阿里巴巴 HSF2 的關係等。也可以透過如下部分了解更多：

背景

Dubbo3 的設計與開發有兩個大的背景。

首先，如何更好的滿足企業實踐訴求。 Dubbo 自 2011 由阿里巴巴捐獻開源以來，一直是眾多大型企業微服務實踐的首選開源服務框架。在此期間，企業架構經歷了從 SOA 架構到微服務架構變遷，Dubbo 社群自身也在不斷的更新迭代以更好的滿足企業訴求。然而 Dubbo2 架構上的侷限逐漸在實踐中凸顯：

  • 協議，Dubbo2 協議以效能、簡潔著稱，但卻在雲原生時代遇到越來越多的通用性、穿透性問題；
  • 可伸縮性，Dubbo2 在可伸縮性上依舊遠超很多其他框架，但隨著微服務帶來更多應用與例項我們不得不思考如何應對更大規模叢集的實戰；
  • 服務治理易用性，如更豐富的流量治理、可觀測性、智慧負載均衡等。

其次，適配雲原生技術棧的發展。 微服務讓業務開發演進更靈活、快捷的同時，也帶來了一些它獨有的特徵和需求：如微服務之後元件數量越來越多，如何解決各個元件的穩定性，如何快速的水平擴容等，以 Docker、Kubernetes、Service Mesh 為代表的雲原生基礎設施為解決這些問題帶來了一些新的選擇。隨著更多的微服務元件及能力正下沉到以 Kubernetes 為代表的基礎設施層，傳統微服務開發框架應剔除一些冗餘機制，積極的適配到基礎設施層以做到能力複用，微服務框架生命週期、服務治理等能力應更好地與 Kubernetes 服務編排機制融合； 以 Service Mesh 為代表微服務架構給微服務開發帶來的新的選擇，Sidecar 給多語言、透明升級、流量管控等帶來的優勢，但同時也帶來運維複雜性、效能損耗等弊端，因此基於服務框架的傳統微服務體系還將是主流，長期仍將佔據半壁江山，在長時間內將會維持混合部署狀態。

總體目標

Dubbo3 依舊保持了 2.x 的經典架構，以解決微服務程式間通訊為主要職責，透過豐富的服務治理（如地址發現、流量管理等）能力來更好的管控微服務叢集；Dubbo3 對原有框架的升級是全面的，體現在核心 Dubbo 特性的幾乎每個環節，透過升級實現了穩定性、效能、伸縮性、易用性的全面提升。

architecture-1

  • 通用的通訊協議。 全新的 RPC 協議應摒棄私有協議棧，以更通用的 HTTP/2 協議為傳輸層載體，藉助 HTTP 協議的標準化特性，解決流量通用性、穿透性等問題，讓協議能更好的應對前後端對接、閘道器代理等場景；支援 Stream 通訊模式，滿足不同業務通訊模型訴求的同時給叢集帶來更大的吞吐量。
  • 面向百萬叢集例項，叢集高度可伸縮。 隨著微服務實踐的推廣，微服務叢集例項的規模也在不停的擴充套件，這得益於微服務輕量化、易於水平擴容的特性，同時也給整個叢集容量帶來了負擔，尤其是一些中心化的服務治理元件；Dubbo3 需要解決例項規模擴充套件帶來的種種資源瓶頸問題，實現真正的無限水平擴容。
  • 更豐富的程式設計模型，更小的業務侵入。 在開發態業務應用面向 Dubbo SDK 程式設計，在執行態 SDK 與業務應用執行在同一個程式，SDK 的易用性、穩定性與資源消耗將在很大程度上影響業務應用；因此 3.0 應該具備更抽象的 API、更友好的配置模式、更少的侵佔業務應用資源、具備更高的可用性。
  • 更易用、更豐富的服務治理能力。 微服務的動態特性給治理工作帶來了很高的複雜性，而 Dubbo 這方面一直做的不錯，是最早的一批治理能力定義者與實踐者；3.0 需面向更豐富的場景化，提供諸如可觀測性、安全性、灰度釋出、錯誤注入、外部化配置、統一的治理規則等能力。
  • 全面擁抱雲原生。

面向企業生產實踐痛點

Dubbo2 仍舊是國內首選開源服務框架，被廣泛應用在網際網路、金融保險、軟體企業、傳統企業等幾乎所有數字化轉型企業中，久經規模化生產環境檢驗。以 Dubbo2 的貢獻者和典型使用者阿里巴巴為例，阿里巴巴基於 Dubbo2 在內部維護的 HSF2 框架經歷了歷次雙十一峰值考驗，每天數十億次的 RPC 呼叫，治理著超過千萬的服務例項。在長期的最佳化和實踐積累中，阿里巴巴有了對下一代服務框架的設想與方案，在內部開始了快速演進，並快速的被貢獻到 Apache 社群，如同阿里巴巴一樣，其他使用者的實踐訴求與痛點也在開源社群快速的積累，形成了一致的方向和技術方案，可以說 Dubbo3 的誕生就來自於超大基數的企業使用者積累，為了更好的滿足他們的實踐訴求。

dubbo3-hsf

Dubbo3 融合了阿里巴巴 HSF2 及其他社群企業的大量服務治理經驗，當前 Dubbo3 已經被全面應用到生產實踐環境，使用者包括阿里巴巴電商、餓了麼、釘釘、考拉、阿里雲、小米、工商銀行、風火遞、平安健康等。社群與使用者的合作形成的良性迴圈極大的促進了 Dubbo3 的發展，阿里巴巴已經以社群版 Dubbo3 完全取代了內部維護的 HSF2 框架，他們的實踐經驗一方面推動 Dubbo3 的穩定性，另一方面正夠源源不斷的將服務治理實踐經驗輸出到開源社群。

面向百萬叢集例項，橫向可擴容

隨著微服務實踐經驗的積累，微服務被拆分成更細粒度，部署到越來越多的機器例項，以支撐不斷增長的業務規模。在眾多的 Dubbo2 企業使用者中，尤其是以金融保險、網際網路為代表的規模化企業開始遇到叢集容量瓶頸問題（典型的請參照 工商銀行實踐案例 ）：

  • 服務發現過程
    • 註冊中心資料儲存規模達到容量瓶頸
    • 資料註冊&推送效率嚴重下降
  • Dubbo 程式
    • 侵佔更多機器資源，導致業務資源利用率降低
    • 頻繁 GC 影響業務穩定性

Dubbo3 在設計上很好的解決了這些問題，透過全新設計實現的服務治理（服務發現）模型，可以實現服務發現鏈路上的資料傳輸、資料儲存量平均下降 90% 左右；同時 Dubbo3 自身在業務程式中變得更輕量、更穩定，實現提升資源利用率 50%。

Dubbo3 一個更大的優勢在於其對整體架構穩定性的提升，新的服務發現架構使得對於整個叢集容量、可伸縮性評估變得更容易、更準確。

capacity

如果將應用開發粗略劃分為業務開發、運維部署兩個層次，其中變化比較頻繁的因素包括服務（介面）、應用、機器例項。在 2.x 時代，所有這三個因素的增長都會影響微服務叢集的總體容量，尤其是介面增減帶來的波動，對整體容量評估是非常不透明的。而在 3.0 中叢集容量變化僅與應用名、機器例項兩個因素相關，而容量評估的物件往往都是應用與例項，因此整個叢集變的更穩定透明。

雲原生

在雲原生時代，底層基礎設施的變革正深刻影響應用的部署、運維甚至開發過程，往上也影響了 Dubbo3 微服務技術方案的選型與部署模式。

下一代 RPC 協議

新一代的 Triple 協議基於 HTTP/2 作為傳輸層，具備更好的閘道器、代理穿透性，原生支援 Stream 通訊語義，相容 gRPC 協議。

多語言友好

Dubbo3 從服務定義、RPC 協議、序列化、服務治理等多個方面都已經將多語言友好性作為重點考量因素，目前提供了 Java、Golang 穩定的多語言版本，更多語言版本的 3.0 實現如 Rust、Javascript、C/C++、C# 等在開發建設中。

Kubernetes

Dubbo3 開發的應用可以原生部署到 Kubernetes 平臺，Dubbo3 在地址、生命週期等已設計可與 Kubernetes 等容器排程平臺對齊；對於要進一步複用 Kubernetes 底層基礎設施能力的使用者來說，Dubbo3 也已對接到了原生的 Kubernetes Service 體系。

Service Mesh

Service Mesh 強調控制面在微服務治理中的作用，在一定程度上推動了控制面通訊協議、職責範圍的擴充套件與標準化；傳統 Mesh 架構下的 Sidecar 模型強調旁路代理對於流量的統一管控，以實現透明升級、多語言無感、無業務侵入等特性。

Dubbo3 提供了基於自身思考的 Dubbo Mesh 解決方案，強調了控制面對微服務叢集的統一管控，而在部署架構上，同時支援 sicecar 與無 sidecar 的 proxyless 部署架構，使用 Dubbo Mesh 的使用者基於自身的業務特點將有更多的部署架構選擇。

異構體系互通

我們正看到越來越多的異構微服務體系互通的訴求，典型如 Dubbo、Spring Cloud、gRPC 等。有些是因為技術棧遷移，有些是組織合併後需要實現業務互調，Dubbo3 藉助於新的服務發現模型以及可靈活擴充套件的 RPC 協議，可以成為 Dubbo3 未來的發展目標。

原文首於 Dubbo 官網：https://cn.dubbo.apache.org/zh/overview/what/dubbo3/

歡迎在 https://github.com/apache/dubbo 給 Dubbo Star。
搜尋關注官方微信公眾號：Apache Dubbo，瞭解更多業界最新動態，掌握大廠面試必備 Dubbo 技能

相關文章