作者 | 陸龜
來源 |
阿裡巴巴雲原生公衆号本文整理自作者在3月20日雲原生中間件 Meetup 上海站的分享。回複關鍵字“中間件”可以擷取視訊錄播位址和 PPT。
就在今天，Dubbo 社群剛剛釋出了 3.0 的首個預覽版本 - 3.0.0.preview。
本文将和讀者一起解讀 Dubbo3 的首個 preview 版本：一方面，我們将深入分析 Dubbo3 雲原生變革的核心理念；另一方面，我們将逐個解讀 preview 版本的核心功能。
做過微服務開發的開發者相信對 Dubbo 都不陌生，Dubbo 是一款能幫助我們快速解決微服務開發、通信以及流量治理的架構。相比于之前隻限定在 Java 語言範圍内，Dubbo 的多語言版本在這兩年呈現了良好的發展勢頭，其中，Dubbo Go 語言版本在功能、穩定性各個方面都已非常完備，其它幾種主流的多語言版本在社群也有提供。
雲原生視角的微服務變革
Dubbo 主要解決微服務開發、運作域問題，它和微服務的程式設計、通信、流量治理等密切關聯，是以，在探尋 Dubbo3 的雲原生變革之前，我們先嘗試從雲原生視角觀察雲原生基礎設施帶給微服務架構和實踐的變革，進而總結出 Dubbo 這樣一個和微服務實踐密切相關的架構所面臨的變革與挑戰。
微服務在讓業務開發演進更靈活、快捷的同時，也帶來了一些它獨有的特征和需求：如微服務之後元件數量越來越多，如何解決各個元件的穩定性，如何快速的水準擴容等。
這些訴求，尤其是運維、傳遞相關訴求，如微服務元件的生命周期、網絡、通用服務綁定、服務狀态管理等，并不應該是開發人員關注的重點，因為它們已經完全脫離了業務邏輯，開發人員更願意專注在有業務價值元件上，但這個層次的訴求卻是實作微服務傳遞的關鍵能力。開發者期望由底層基礎設施來提供此類能力支援，而處于不同階段發展的基礎設施卻不一定具備這樣的能力，是以，在微服務軟體架構和底層基礎設施之間就出現了一條鴻溝，我們需要有元件能填補這一鴻溝，讓微服務元件能更好的接入底層基礎設施。
這裡從一個更抽象的層面，嘗試用兩條發展曲線示範了軟體架構訴求與底層基礎設施能力豐富度之間的關系。總體上，兩者之間的發展關系可拆分為兩個階段。
在第一個階段，軟體架構（這條紅色的線）從單體應用、到面向服務的軟體架構、再到微服務架構，快速演進，進而也提出了上文我們講到的對基礎設施對傳遞的訴求，這個時候基礎設施層還多是以定制化的方式來滿足軟體架構的訴求，如過往的集中化的 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 預覽版本的釋出隻是開始，未來随着阿裡巴巴、工商銀行等更多标杆使用者的全面落地，将推動項目更快、更高品質的發展，助力項目保持持續的創新能力和社群生命力。
未來規劃（Roadmap）
以下是 Dubbo3 的 Roadmap，截止此文發稿，社群已經完成了 3.0 preview 版本的釋出。
在 6 月份，我們期望能迎來 Dubbo3 的首個社群正式版本。
随後，一直到下半年的 11 月份，我們将重點投入在對 Kubernetes、ServiceMesh 架構的支援上，中間當然也包括了對服務治理規則的全面重構。
在此之後，我們将開始在服務柔性上的嘗試，以期提供一種能更高效的利用資源且能提高系統穩定性的流量高度機制。
本文開篇關于雲原生微服務變革部分思想引自阿裡雲進階技術專家、CNCF TOC 張磊 《Microservices - A Cloud Native View》一文分享。
點選直達GitHub 檢視 Dubbo 3.0.0.preview：