透過 3.0 Preview 看 Dubbo 的雲原生變革

時間 2021-04-11

標籤 git github apache 編程網絡架構併發負載均衡框架 less 欄目 Dubbo 简体版

原文原文鏈接

本文整理自做者在3月20日雲原生中間件 Meetup 上海站的分享。回覆關鍵字「中間件」能夠獲取視頻錄播地址和 PPT。github

就在今天，Dubbo 社區剛剛發佈了 3.0 的首個預覽版本 - 3.0.0.preview。apache

https://github.com/apache/dubbo/releases/tag/3.0.0.preview編程

本文將和讀者一塊兒解讀 Dubbo3 的首個 preview 版本：一方面，咱們將深刻分析 Dubbo3 雲原生變革的核心理念；另外一方面，咱們將逐個解讀 preview 版本的核心功能。網絡

作過微服務開發的開發者相信對 Dubbo 都不陌生，Dubbo 是一款能幫助咱們快速解決微服務開發、通訊以及流量治理的框架。相比於以前只限定在 Java 語言範圍內，Dubbo 的多語言版本在這兩年呈現了良好的發展勢頭，其中，Dubbo Go 語言版本在功能、穩定性各個方面都已很是完備，其它幾種主流的多語言版本在社區也有提供。架構

雲原生視角的微服務變革

Dubbo 主要解決微服務開發、運行域問題，它和微服務的編程、通訊、流量治理等密切關聯，所以，在探尋 Dubbo3 的雲原生變革以前，咱們先嚐試從雲原生視角觀察雲原生基礎設施帶給微服務架構和實踐的變革，進而總結出 Dubbo 這樣一個和微服務實踐密切相關的框架所面臨的變革與挑戰。併發

微服務在讓業務開發演進更靈活、快捷的同時，也帶來了一些它獨有的特徵和需求：如微服務以後組件數量愈來愈多，如何解決各個組件的穩定性，如何快速的水平擴容等。負載均衡

這些訴求，尤爲是運維、交付相關訴求，如微服務組件的生命週期、網絡、通用服務綁定、服務狀態管理等，並不該該是開發人員關注的重點，由於它們已經徹底脫離了業務邏輯，開發人員更願意專一在有業務價值組件上，但這個層次的訴求倒是實現微服務交付的關鍵能力。開發者指望由底層基礎設施來提供此類能力支持，而處於不一樣階段發展的基礎設施卻不必定具有這樣的能力，所以，在微服務軟件架構和底層基礎設施之間就出現了一條鴻溝，咱們須要有組件能填補這一鴻溝，讓微服務組件能更好的接入底層基礎設施。框架

這裏從一個更抽象的層面，嘗試用兩條發展曲線演示了軟件架構訴求與底層基礎設施能力豐富度之間的關係。整體上，二者之間的發展關係可拆分爲兩個階段。less

在第一個階段，軟件架構（這條紅色的線）從單體應用、到面向服務的軟件架構、再到微服務架構，快速演進，從而也提出了上文咱們講到的對基礎設施對交付的訴求，這個時候基礎設施層還可能是以定製化的方式來知足軟件架構的訴求，如過往的集中化的 ESB、各個不一樣的 PaaS 平臺等。

第二個階段，是從容器、Kubernetes 爲表明的基礎產品的出現開始，藍線與紅線之間的增加速度被快速拉近，以雲原生技術爲表明的底層基礎設施豐富度獲得了極大改善，它們再也不只是被動的知足微服務開發的訴求，而是開始抽象更多的軟件訴求到底層的基礎設施，將它們下沉爲基礎能力，並開始以統一的、標準化的形式向上輸出以知足微服務對交付、運維等的訴求，不只如此，經過更深刻的主動創新、持續的向上釋放能力，底層基礎設施還開始反過來影響微服務的開發、接入方式，如 sidecar、dapr 等模型。

Dubbo3 的雲原生變革

經過上文雲對原生基礎設施演進給傳統微服務帶來變革的分析，咱們得出，以 Dubbo 爲表明的微服務開發框架，應重點在如下方向突破與變革。

更多的微服務組件及能力正下沉到以 Kubernetes 爲表明的基礎設施層。傳統微服務開發框架應剔除一些冗餘機制，積極的適配到基礎設施層以作到能力複用；微服務框架生命週期、服務治理等能力應更好地與 Kubernetes 服務編排機制融合。
以 Service Mesh 爲表明微服務架構給微服務開發帶來的新的選擇，但因爲 Mesh 架構自己的複雜性，其距離大規模生產落地還有一段距離。咱們相信，基於 ServiceMesh 的體系會逐步從孵化器走向成熟期，會有愈來愈多的企業採用 Service Mesh技術，但在將來在很長一段時間內，基於服務框架的傳統微服務體系還將是主流，長期仍將佔據半壁江山。

咱們不妨回想一下，在雲原生基礎設施能力被充分釋放前，圍繞 Dubbo 構建微服務時，它給微服務開發提供了哪些能力？或者咱們指望它提供哪些能力？

Dubbo2 提供了包括服務註冊、服務發現、負載均衡、流量治理等至關豐富的能力，固然還包括微服務最須要的遠程通訊能力，這些能力很好地解決了微服務的訴求。

而在雲原生架構之下，咱們須要從新審視，Dubbo2 的哪些能力是冗餘的，是須要接入基礎設施的？哪些能力是已經不適合雲原生時代的，須要被重構的？

首先，是接入雲原生基礎設施後，一些能力出現了重複，像服務定義、服務註冊、甚至是服務治理能力在不一樣層面基礎設施中出現了重複，須要 Dubbo3 做出適配與調整，以更好的解放業務開發效率，利用好這些基礎能力。

其次，是 Dubbo 在微服務架構中的最基本的能力：RPC 遠程通訊。通訊協議和數據傳輸格式的標準化應該算是 Dubbo2 面臨的又一重要挑戰，在雲原生背影下，協議、數據定義、傳輸格式的標準化和穿透能力成爲更須要優先考慮的指標，縱然私有協議具備更高效、靈活的潛力，但考慮到雲原生下多語言、組件間互通、網關等代理設備友好性、避免廠商鎖定等訴求，在 Dubbo3 中私有協議都應該被摒棄，轉而擁抱基於 HTTP/2 的更通用的協議，採用跨語言的更通用的數據定義和傳輸格式。

最後，是關於服務治理能力，Dubbo 的服務治理能力應該充分結合底層基礎設施的特色，好比以前綁定 ip 的流量過濾方案在地址不固定的 Kubernetes 平臺就已再也不適用，另外，流量治理也要充分的與調度平臺的灰度發佈、動態擴縮容能力整合起來；考慮到將來微服務可能會有多種不一樣的部署形態（下文會講到），Dubbo3 應該制定一種能適用於各類部署形態的路由規則。

從雲原生視角來講，Dubbo3 的核心能力基本上也就成圍繞以上幾點分析展開的，主要涉及：抽象全新的服務發現模型、定義下一代的更能用的 RPC 協議與數據傳輸格式、服務治理能力重構等。接下來，咱們就看看 3.0 preview 中這些能力的具體實現。

Preview 版本功能速覽

就在今天，Dubbo 3.0.0.preview 版本正式經過了 Apache 社區投票並完成了正式發佈，做爲 3.0 的首個發佈版本，表明了社區 3.0 版本的全面啓動，也展現了將來 3.0 的發展方向。固然，咱們要意識到 preview 版本還遠未達到生產可用，它只是爲了讓你們快速、方便了解 Dubbo3 的一個預覽版本，離正式版本甚至 alpha 版本還有一段時間要走，具體你們可關注文後的 Dubbo Roadmap。

如下 preview 版本發佈的幾個核心特性：

全新的服務發現模型
下一代基於 HTTP/2 的 RPC 協議：Triple
服務治理重構：全新路由規則
性能提高
- 百萬節點級水平擴容
- 調用鏈路 QPS 性能提高

在 preview 以上能力中，特別值得注意的是得益於 Dubbo3 與 HSF 的融合，Dubbo3 的總體性能也有望獲得大幅提高。

Preview 版本是從架構層面對 Dubbo 的一次全面升級，接下來，社區一方面會從功能完善度、穩定性等幾個方面繼續加強 3.0 版本，並將在 6 月份發佈首個穩定版本，另外一方面社區將兌現更多新的功能。首先，接下來即將交付的是 Kubernetes Service 集成，而 Proxyless Mesh、基於反壓的智能流量調度等功能正在前期的調研或開發階段。

下面，咱們就選取以上三個核心功能，深刻了解它們的實現機制。

1. 全新服務發現模型

下圖是 Dubbo2 的服務發現模型：Provider 註冊服務地址，Consumer 通過註冊中心協調並發現服務地址，進而對地址發起通訊，這是被絕大多數微服務框架的經典服務發現流程。而 Dubbo2 的特殊之處在於，它把「RPC 接口」的信息也融合在了地址發現過程當中，而這部分信息每每是和具體的業務定義密切相關的。

而在接入雲原生基礎設施後，基礎設施融入了微服務概念的抽象，容器化微服務被編排、調度的過程即完成了在基礎設施層面的註冊。以下圖所示，基礎設施即承擔了註冊中心的職責，又完成了服務註冊的動做，而「RPC 接口」這部分信息，因爲與具體的業務相關，不可能也不適合被基礎設施託管。

在這樣的場景下，對 Dubbo3 的服務註冊發現機制提出了兩個要求：

Dubbo3 須要在原有服務發現流程中抽象出通用的、與業務邏輯無關的地址映射模型，並確保這部分模型足夠合理，以支持將地址的註冊行爲和存儲委託給下層基礎設施；
Dubbo3 特有的業務接口同步機制，是 Dubbo3 須要保留的優點，須要在 1 中定義的新地址模型之上，經過框架內的自有機制予以解決。

這樣設計的全新的服務發現模型，在架構兼容性、可伸縮性上都給 Dubbo3 帶來了更大的優點。

在架構兼容性上，如上文所述，Dubbo3 複用下層基礎設施的服務抽象能力成爲了可能；另外一方面，如 Spring Cloud 等業界其它微服務解決方案也沿用這種模型，在打通了地址發現以後，使得用戶探索用 Dubbo 鏈接異構的微服務體系成爲了一種可能。

Dubbo3 服務發現模型更適合構建可伸縮的服務體系，這點要如何理解？這裏先舉個簡單的例子，來直觀的對比 Dubbo2 與 Dubbo3 在地址發現流程上的數據流量變化：假設一個微服務應用定義了 100 個接口（Dubbo 中的服務），則須要往註冊中心中註冊 100 個服務，若是這個應用被部署在了 100 臺機器上，那這 100 個服務總共會產生 100 100 = 10000 個虛擬節點；而一樣的應用，對於 Dubbo3 來講，新的註冊發現模型只須要 1 個服務（只和應用有關和接口無關），只註冊和機器實例數相等的 1 100 = 100 個虛擬節點到註冊中心。在這個簡單的示例中，Dubbo 所註冊的地址數量降低到了原來的 1 / 100，對於註冊中心、訂閱方的存儲壓力都是一個極大的釋放。更重要的是，地址發現容量完全與業務 RPC 定義解藕開來，整個集羣的容量評估對運維來講將變得更加透明：部署多少臺機器就會有多大負載，不會像 Dubbo2 同樣，由於業務 RPC 重構就會影響到整個集羣服務發現的穩定性。

2. 下一代通訊協議：Triple

咱們將 Dubbo3 的新協議命名爲 Triple，有表明第 3 代協議的意思。在雲原生背景下，Triple 協議須要解決兩大問題：

通訊協議和數據傳輸格式的標準化問題。這涉及到 RPC 協議、數據定義、數據傳輸等環節，將來可移植性、不被廠商鎖定會成爲每一個上雲企業用戶的訴求，組件內的私有協議和特有數據格式，必然會成爲不少用戶選型的顧慮。
穿透性、通用性問題。在 Mesh 等架構設想下，微服務甚至全部組件的通訊都要通過 sidecar 代理轉發，理論上，Sidecar 是要透明的轉發流量的（收到什麼就轉發什麼），起碼 payload 不該該是 Sidecar 關注的；而 Sidecar 在某些時候也須要感知流量內容的，由於它要基於些作流量的調度，這個時候，Triple 就要作到足夠通用 -- 讓全部的 Sidecar 都能在預期的地方取到其關注的元數據，而不用解析整個 payload。

除了以上兩個核心問題，Triple 協議還須要被設計用來支持更多的業務語義。

協議應該提供更完善的請求模型，除了 Request/Response 模型，還應該支持 Streaming 和 Bidirectional。
在性能上，新的協議應該保留 request Id 機制，以免 HOL 帶來的性能損耗。
新協議應該易於擴展，包括但不限於 Tracing、Monitoring、BackPressure 等支持。

基於以上需求，Triple 協議是徹底基於 HTTP/2 之上構建的，另外，Triple 協議將會作到徹底兼容 gRPC 協議；在服務定義、數據格式定義以及傳輸格式上，Triple 將更增長對 Protobuf 的支持。

3. 統一的路由規則

Dubbo3 會對服務治理規則進行全面的重構，以更好的適應雲原生基礎設施的變革。

當前的 3.0 preview 版本提供了一個重構後的路由規則機制原型，雖然當前版本的實現還須要繼續加強，但從設計理念上，咱們能夠解讀出：Dubbo3 指望提供一種跨平臺、跨語言、跨多種部署架構的通用路由規則。

隨着微服務對治理需求的挖掘，Dubbo2 路由規則除了在語義表達上不能涵蓋全部場景以外，更爲重要的是，其基於特定語言、特定主機 ip 的過濾機制，已再也不適應底層調度平臺的工做機制，Dubbo3 須要引入一種全新設計的路由規則。而對於「跨多種部署架構」這個點，咱們設想將來以 Dubbo 構建的微服務會有三種部署架構：傳統 SDK、基於 Sidecar 的 Service Mesh以及脫離 Sidecar 的 Service Mesh，這三種部署形態都將由 Dubbo3 統一的路由規則進行治理。

基於 Sidecar 的 Service Mesh，經典的 Mesh 架構，獨立的 sidecar 運行時接管全部的流量。
脫離 Sidecar 的 Service Mesh，變種 Mesh 架構，沒有 sidecar 運行時，富 SDK 直接經過 xDS 與控制面通訊，咱們將在後續發佈關於 Proxyless 模式更詳細的解讀。

實踐中的 Dubbo3

雲原生微服務變革在各大廠商內部早已展開，相比於當前開源社區的 preview 版本，Dubbo3 在阿里巴巴的開發與實踐已經在逐步鋪開：部分功能已經在阿里巴巴的部分業務線上獲得了規模化驗證（考拉），而且更多的功能和業務線也將進入試點、推廣階段（餓了麼、釘釘等）。有一點是值得特別說起的是：在接下來阿里巴巴的微服務架構升級戰略中，Dubbo3 將成爲阿里巴巴經濟體將來惟一的標準服務框架，它將逐步在全部業務線取代 HSF 和 Dubbo2，而且咱們期待在接下來的 1-2 年 Dubbo3 內能覆蓋大多數重要的業務線。

說在這裏，有必要提一下阿里巴巴的微服務框架演進歷程。大概在 2011 年，阿里巴巴開源了 Dubbo2 這一款服務框架並得到極大成功，在 Dubbo2 開源不久，在阿里巴巴內部又發展出了一款全新的服務框架 -- HSF，二者在設計理念上是高度類似的，而通過這麼些年的發展，HSF 得以跟隨阿里巴巴的業務系統更快速的成長，由其是在大集羣、大流量治理下展示出了更好的性能和穩定性。在阿里雲原生微服務戰略下，整合各個優秀的框架並發展統一品牌的 Dubbo3 被歸入發展規劃，在此背景下，Dubbo3 實現了Dubbo2 與 HSF 的融合，並將推進實現內、外技術棧的統一。

除了阿里以外，工商銀行等標杆用戶也已啓動了對 Dubbo3 項目的試點。從社區角度來講，preview 預覽版本的發佈只是開始，將來隨着阿里巴巴、工商銀行等更多標杆用戶的全面落地，將推進項目更快、更高質量的發展，助力項目保持持續的創新能力和社區生命力。