Dubbo 雲原生之路

 【Dubbo 雲原生之路】系列開篇

做者：劉軍

花名陸龜，Github 帳號 Chickenlj，Apache Dubbo PMC，項目核心開發，見證了 Dubbo 重啓開源，到從 Apache 基金會畢業的整個過程。現任職阿里云云原生應用平臺團隊，參與服務框架、微服務相關工做，目前主要在推進 Dubbo 3.0 - Dubbo 雲原生。

縱觀中國開源歷史，你真的無法找到第二個像 Dubbo 同樣自帶爭議和討論熱度的開源項目。

一方面，2011年，它的開源填補了當時生產環境使用的 RPC 框架的空白，一發布就被普遍採用；另外一方面，它經歷了中止維護、重啓維護後捐獻給 Apache 基金會、接着又以頂級項目的身份畢業。即使阿里努力對外展現開源投入的決心，在面對廣受歡迎的後起之秀 Spring Cloud，和新生兒 Service Mesh 的夾擊下，Dubbo 的路將怎麼走下去？在雲原生時代，它如何延續當前光芒？

今年是 Dubbo 從 Apache 基金會畢業的一週年，同時也是推動 Dubbo 3.0，即全面擁抱雲原生的重要一年。

Dubbo 與開源中國共同策劃【Dubbo 雲原生之路】系列文章，和你們一塊兒回顧 Apache Dubbo 社區的發展。系列文章主要涵蓋 Dubbo 技術解讀、社區運營、應用案例解析三大部分，以後每週都會和你們見面。

在這裏，咱們也向全部的 Dubbo 用戶和開發者發出投稿邀請，若是你正在使用 Dubbo，或是正在爲 Dubbo 貢獻力量，歡迎和咱們分享你的開發使用經驗，優質文章也會收錄進【Dubbo 雲原生之路】系列。

投稿地址：xuyijun@oschina.cn

【Dubbo 雲原生之路】系列第一篇：3.0全面鋪開、ASF 畢業一週年

本篇做爲整個系列的開篇，將總體回顧並展望 Dubbo 項目發展，同時簡要歸納後續文章。

從2019年到如今，在 Dubbo 畢業的這一年時間裏，Dubbo 社區和產品都取得長足進步，同時 Dubbo 雲原生版本 - Dubbo 3.0的開發工做也已經全面鋪開。

社區方面。須要重點說起的有兩點：一個是落地與貢獻的企業用戶進一步增長，主動與社區取得聯繫的中、大規模公司達200多家，如攜程、工商銀行、瓜子二手車、網聯清算、中通等；另外一個是以 Dubbo-go 爲表明的子社區蓬勃發展。

產品技術演進方面。Dubbo Java 版發佈10個版本，在多語言、協議、性能、服務治理模型等方面都有深度探索。Dubbo go 發佈超過8個版本，在功能基本對齊 Java 版本的基礎上，一些方向上也已經走在了 Java 版本前面。值得一提的是，阿里巴巴內部也正在積極推進 Dubbo 社區版本在內部的落地，從今年開始逐步實現以 Dubbo 替換其內部的 HSF 框架。這一方面有利於阿里將其在 HSF 上的豐富服務治理經驗回饋輸出到社區，另外一方面阿里官方的落地也將直接加速 Dubbo 雲原生的發展。

在雲原生大潮下，3.0已被正式列爲今年 Dubbo 產品建設的核心目標，涉及下一代 RPC 協議、服務治理模型、雲原生基礎設施適配等多方面的內容。其中，不少方面已經在當前的2.7版本中作了前置性探索，如近期發佈的基於 HTTP/2的協議支持、應用級服務發現等，後續工做將以此爲基礎展開。系列文章也會有對 Dubbo 3.0 Roadmap 及技術方案的詳細解析。

Dubbo 畢業一週年回顧

2017年7月，Dubbo 開源項目被從新激活，2018年捐獻到 Apache 基金會，2019年5月，Dubbo 正式從 Apache 基金會孵化畢業，成爲 Apache 頂級項目。接下來，文章分別從社區、子社區、產品三方面介紹 Dubbo 過去一年的成績。

社區一年發佈24個版本，貢獻者已超300

若是說最開始從新激活是以阿里巴巴爲主導的項目維護投入，那自 Dubbo 加入 Apache 起，它就已經開始成爲一個社區主導、社區貢獻爲主的徹底開放的基金會項目。

到今天，這一趨勢正變得更明顯。包括阿里巴巴、攜程、工商銀行、瓜子二手車、網聯清算、中通等在內的互聯網、傳統企業公司，在 Dubbo 的使用與社區代碼貢獻上都有投入。Dubbo 社區正變得很是活躍和多樣化。

過去一年，Dubbo 社區項目總共發佈24個版本，發展 Committer/PMC 27人，其中有20%的貢獻者是來自於阿里巴巴，80%以上來自不一樣組織的開發者或愛好者。

Dubbo 社區組織了超過10場線下 meetup 活動，基本覆蓋了國內開發者彙集的城市。經過線下或線上直播活動，分享超過100個 topic 的演講，深度講解 Dubbo 社區最新動態、功能模塊開發和近期規劃等。主題演講大可能是社區採集方式，由 Dubbo 的深度企業分享實踐經驗，其中典型的表明包括攜程、工商銀行、考拉、信用算力等。

從 Github 統計數據來看，Dubbo Star 數取得新的里程碑，已超過3萬，相比重啓開源時增加了近5倍；貢獻者由最初的幾十個增加到如今的300多個，而這其中有60多人已經被提名爲 committer，不管是貢獻者數量仍是 committer 比例都獲得很大的提高；Dubbo Java 發佈的有65個。

上述主要是對 Dubbo Java 項目社區發展的總結，下面將介紹 Dubbo Java 產品方面的進展。

Dubbo Java 迭代，目前主要維護3個大版本

當前社區維護的 Dubbo Java 大版本主要有3個，分別是2.5.x、2.6.x 和2.7.x。

• 2.7.x 是社區的主要開發版本，在過去的一年共發佈了8個版本（2.7.0 - 2.7.7），每一個版本都有一些值得關注的特性或功能升級，涵蓋從編程模型、服務治理、性能到協議的多個方面的加強。
• 2.6.x 版本則定位爲 bugfix 版本，過去一年共發佈了3個版本，主要以修復問題和安全漏洞爲主，並無增長太多新的 feature。
• 2.5.x 版本從2019年初開始已宣佈 EOF，只作安全修復；而到了下半年已經徹底中止了維護。

下面經過一個簡要分層模塊圖，回顧過去一段時間 Dubbo 的技術架構演進，從編程模型、服務治理、傳輸協議、性能優化等角度切入：

以上不少功能都已被各大廠商落地，用於解決具體的業務問題。咱們也期待，接下來這些廠商帶來更多關於 Dubbo 實踐經驗的深度總結。

Dubbo-go 發展的第五年，正與 Dubbo 齊頭並進

除 Dubbo Java 以外，Dubbo 周邊也發展出了不少優秀的子項目（子社區），其中包括 Dubbo-spring-boot-project、Dubbo-go 等，這裏先着重介紹 Dubbo-go 子社區。

Dubbo-go 項目最先由於雨在2016年5月構建，同年9月發佈並開源，以下時間軸圖清晰記錄了 Dubbo-go 的前世此生。

秉承 "bridge the gap between Java and Go" 自然使命的 Dubbo-go，已經進入第五個年頭，也走出了本身獨特的發展路徑：

• 當前的 v1.4.0 版本已對齊2.6.x 版本，即將發佈的版本將與 v2.7.x【對標 v2.7.5】對齊，然後將會發布對標 Dubbo 3.x 的 v1.6.0版本；
• 獨立維護從底層的 hessian2協議庫 Dubbo-go-hessian2、網絡庫 getty 到上層對標 Dubbo 的 Dubbo-go 的全套實現；
• 獨立的 TCP + Protobuf 和 gRPC + JSON 通訊方案也已開發完成【將包含着在版本 v1.5.0中】；
• 已與 Dubbo/gRPC/Spring Boot 實現互聯互通；
• 經過接入 Opentracing 和 Promethus，Dubbo-go 在可觀測性等微服務方向的進行了本身獨特的探索；
• 已實現了基於 HTTPS 的可信 RPC 調用；
• 已經實現了本身獨特的把 kubernetes 做爲註冊中心的微服務方案；

Dubbo-go 從最開始 Dubbo 的 Go 語言實現，已發展成爲目前 Dubbo 多語言版本中功能最強大者，它的發展離不開背後強大的 Dubbo-go 社區。除了上述 Dubbo-go 的自身特性外，經過跨社區合做，取得了以下成績：

• 經過與 MOSN 社區合做，已經實現 Dubbo/Dubbo-go 應用能夠零成本接入基於 MOSN 實現 Dubbo Mesh，實現微服務和雲原生共存的 「雙模微服務」；
• 與 sentinel 社區合做，在 Dubbo/Dubbo-go 完整接入 sentinel 的降級和限流方案；
• 與 Apollo 社區合做，在 Dubbo-go 中實現遠程配置下發；
• 與 Nacos 社區合做，實現基於 Nacos 的服務發現； 

Dubbo-go 社區2020年 Q2主要目標有：

• 發佈徹底對齊 Dubbo 2.7.x 的 v1.5.0版本；
• 發佈對標 Dubbo 3.0的 v1.6.0版本；
• 在雲原生方面繼續本身的探索；
• 繼續與兄弟社區保持合做共進態勢，擴大自身使用範圍；
• 生產實踐上推動在阿里集團，以及更多廠家的落地。

項目（包括子項目）目前已前後在攜程、塗鴉智能和螞蟻金服等公司生產落地。

今年阿里集團完成 HSF 和 Dubbo 的融合後，項目也將在阿里集團雙十一戰場經受考驗。

雲原生 Dubbo - Dubbo 3.0

3.0是下一代 Dubbo 架構的代號。一年前，最開始探索 Reactive Stream 之時，社區也曾有過對 Dubbo 3.0的普遍討論。而這一次，在雲原生大背景下，3.0表明了更全面的 Dubbo 架構升級，涉及到下一代 RPC 協議、全新的服務治理模型和雲原生基礎設施適配等。

阿里巴巴是參與 Dubbo 3.0開發建設的主要力量之一，這款始於阿里的開源項目正從新迴歸阿里內部落地。

去年開始，阿里巴巴就已經在逐步推進以 Dubbo 替換其內部的 HSF 框架的工做，經過將 Dubbo 與 HSF 兩個框架融爲一體，並在此基礎上發展出適應雲原生架構的 Dubbo 版本。Dubbo 重回阿里巴巴的落地是擁抱社區、擁抱雲原生、擁抱標準化的一次很好的實踐。阿里巴巴內部 Dubbo 3.0的落地，對社區也是一個重大利好，這一方面有利於阿里巴巴將其在 HSF 上的豐富服務治理經驗回饋輸出到社區，另外一方面也將直接推進 Dubbo 雲原生架構的快速演進。除了阿里巴巴以外，包括鬥魚、工商銀行、愛奇藝、鬥魚等廠商也都在參與下一代 Dubbo 3.0的建設。

下面列出了 Dubbo 3.0中的三個重要方向，具體的 Roadmap 將在接下來文章中單獨說明：

• 下一代 RPC 協議。新協議將提供更豐富的如 Stream、Flow Control 等內置語義，同時將具備更好的擴展性、網關的友好性等；
• 基於應用粒度的服務發現機制。在兼顧 Dubbo 面向接口的易用性與功能性的基礎上，解決與 Kubernetes Native Service 適配問題，解決大規模集羣下的地址推送性能瓶頸問題；
• 適配雲原生基礎設施的解決方案。這涉及到 Dubbo 服務與基礎設施生命週期對接、Kubernetes Native Service 適配、適應基礎設施調度的服務治理規則、適配 Service Mesh 架構的解決方案等；

接下來沿着這三個方面簡要展開。

下一代 RPC 協議

專一在協議自身來講，下一代的協議主要聚焦在 HTTP/二、Reactive Stream、Flow Control 等方面：

• Reactive Stream
  Reactive Stream 引入 RPC，帶來更豐富的通訊語義和 API 編程模型支持，如 Request-Stream、Bi-Stream 等
• HTTP/2
  微服務雲原生場景下，基於 HTTP/2構建的通訊協議具備更好的通用性和穿透性
• Flow Control
  協議內置流控機制，支持相似 Reqctive Stream 的 Request (n) 流控機制

從解決的業務場景問題上來講，基於新的協議 Dubbo 在框架層面要支持智能決策的負載均衡算法、對 Mesh 和網關更友好、更容易提供多語言實現與互通等

• Mesh
  協議對穿透 Mesh 更友好，區分協議頭 Metadata 與 RPC Payload，方便完成與 Mesh 的協做，包括流量控制機制、應用層配置協商等
• 協議通用性
  兼顧通用性與性能，支持協議能在各類設備上運行
• 多語⾔支持
  如經過支持 Protobuf 提供了更完善的 跨語言服務定義 與 序列化傳輸的支持

應用級服務治理

面向接口一直以來都是 Dubbo 框架的優點。一方面它的易用性，爲開發者屏蔽了遠程調用的存在；另外一方面面向接口的地址發現、服務治理帶來了更強大的能力，使得整個 Dubbo 治理體系很是強大與靈活。

既然面向接口有如此多的好處，那爲何咱們還要探索麪嚮應用的服務治理模式呢？

聽起來彷佛有些矛盾。其實究竟是面向接口，仍是面向應用，只是從不一樣的角度看 Dubbo。咱們所聊的「面向接口 -> 面向應用」的改造，主要體如今服務註冊、發現層面：

而咱們說的面向應用的新模型，主要對第2點，即註冊中心的數據組織轉變爲 「面向應用/實例」 粒度。這爲咱們解決兩個問題：

• 在服務發現層面與 Kubernetes Service 等微服務模型對齊
• 服務發現的數據量將有一個量級的降低，從 「接口數 * 實例數 」降低到 「應用數 * 實例數」

具體能夠參見文章《Dubbo 邁出雲原生重要一步 - 應用級服務發現解析》，本系列文章後續也會有對這部分機制和實現的更深度解析。

雲原生基礎設施

雲原生帶來了底層基礎設施，應用開發、部署和運維等全方位的變化：

基礎設施

• 基礎設施調度機制變化，帶來運維（生命週期）、服務治理等方面的變化。
• 服務發現能力下沉， Kubernetes 抽象了 Native Service Discovery。

Service Mesh - 雲原生微服務解決方案

• Mesh 爲跨語言、sdk 升級等提供瞭解決方案，Dubbo sdk 要與 Mesh 協做，作到功能、協議、服務治理等多方便的適配。
• Mesh 還沒有大規模鋪開，且其更適合對流量管控更關注的應用，傳統 SDK 的性能優點仍舊存在，二者混部遷移場景可能會長期存在。

從應用場景上，Dubbo 可能的部署環境包括：

1. 不使用 Kubernetes Native Service，Kubernetes 只做爲容器編排調度設施，繼續使用 Dubbo  自建的服務註冊、發現機制。
2. 複用 Kubernetes Native Service，Dubbo 再也不關心服務註冊，Dubbo Client 負責服務發現與流量分配。
3. Dubbo sdk 往 Mesh 遷移，一方面要作到適應 Mesh 架構，成爲 Mesh 體系下的 RPC 編程和通訊方案；另外一方面要作到 Dubbo 與 Mesh 架構長期共存，互相打通服務發現和治理體系。
4. Kubernetes 上與雲下混合部署的平滑遷移支持，包括服務發現的統一與網絡通訊方案的打通。

從 Dubbo 功能劃分上，將着重從如下方面提供對雲原生基礎設施的支持：

生命週期：Dubbo 與 Kubernetes 調度機制綁定，保持服務生命週期與 Pod 容器等生命週期的自動對齊

治理規則：服務治理規則在規則體、規則格式方面進行優化，如規則體以 YAML 描述、取消過濾規則對 IP 的直接依賴，定義規則特有的 CRD 資源等。

服務發現： 支持 K8S Native Service 的服務發現，包括 DNS、API-Server，支持 xDS 的服務發現

Mesh 架構協做：構建下一代的基於 HTTP/2的通訊協議，支持 xDS 的標準化的數據下發

新一代的 RPC 協議和應用級服務發現模型將會是這一部分的前置基礎。

總結與展望

做爲系列文章開篇，咱們在這裏對 Dubbo 過去一年的成績作了簡要的總結與回顧，包括 Dubbo 社區、產品迭代的發展。

接下來咱們會看到更多來自深度 Dubbo 用戶的落地經驗分享，Dubbo-go 子社區的發展故事等。

更重要的，咱們也對下一代雲原生 Dubbo - Dubbo 3.0 作了展望，後續關於 Dubbo 3.0 Roadmap、方案設計與進展解析等也將在此係列中發佈。 

敬請期待！