![1.png](https://ucc.alicdn.com/pic/developer-ecology/86f96cb46a5a4f2ab1e931a9ebe89e79.png)

作者 | 劉軍

**導讀：**今年是 Dubbo 從 Apache 基金會畢業的一週年，同時也是推進 Dubbo 3.0，即全面擁抱雲原生的重要一年。Dubbo 社群策劃了【Dubbo 雲原生之路】系列文章，和大家一起回顧 Apache Dubbo 社群的發展。系列文章主要涵蓋 Dubbo 技術解讀、社群運營、應用案例解析三大部分。

縱觀中國開源歷史，你真的沒法找到第二個像 Dubbo 一樣自帶爭議和討論熱度的開源專案。

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

# 前言

本篇作為整個系列的開篇，將整體回顧並展望 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](https://github.com/apache/dubbo) 專案社群發展的總結，下面將介紹 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 的技術架構演進，從程式設計模型、服務治理、傳輸協議、效能最佳化等角度切入：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/2356fa01939c4a0788b7517fdc7d913b.png)

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

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

除 Dubbo Java 之外，Dubbo 周邊也發展出了很多優秀的子專案（子社群），其中包括 [Dubbo-spring-boot-project](https://github.com/apache/dubbo-spring-boot-project)、[Dubbo-go](https://github.com/apache/dubbo-go) 等，這裡先著重介紹 Dubbo-go 子社群。

Dubbo-go 專案最早由[於雨](https://github.com/AlexStocks)在 2016 年 5 月構建，同年9月釋出並開源，如下時間軸圖清晰記錄了[ Dubbo-go 的前世今生](https://blog.csdn.net/RA681t58CJxsgCkJ31/article/details/103856203/)。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/886274d17e234b33ac52381210fa38ad.png)

秉承 "bridge the gap between Java and Go" 天然使命的 [Dubbo-go](https://github.com/apache/dubbo-go)，已經進入第五個年頭，也走出了自己獨特的發展路徑：

- 當前的[ v1.4.0 版本](https://blog.csdn.net/weixin_45583158/article/details/105132322)已對齊 2.6.x 版本，即將釋出的版本將與 v2.7.x【對標 v2.7.5】對齊，而後將會發布對標 Dubbo 3.x 的 v1.6.0 版本；
- 獨立維護從底層的 hessian2 協議庫 [Dubbo-go-hessian2](https://github.com/apache/dubbo-go-hessian2)、網路庫 [getty](https://github.com/dubbogo/getty) 到上層對標 Dubbo 的 [Dubbo-go](https://github.com/apache/dubbo-go) 的全套實現；
- 獨立的 TCP + Protobuf 和 gRPC + JSON 通訊方案也已開發完成【將包含著在版本 v1.5.0 中】；
- 已與 Dubbo/[gRPC](https://juejin.im/post/5e44ed11e51d4526e651b3e6)/[Spring Boot](https://mp.weixin.qq.com/s/9ngGYnkdcu14GkaPBjOBLg) 實現互聯互通；
- 透過接入 [Opentracing](https://mp.weixin.qq.com/s/3AHW0wK8WnfY2ll76iNqHw) 和 Promethus，Dubbo-go 在可觀測性等微服務方向的進行了自己獨特的探索；
- 已實現了基於 HTTPS 的[可信 RPC 呼叫](https://mp.weixin.qq.com/s/30CjBKheCZClKaZCw1DRZA)；
- 已經實現了自己獨特的[把 Kubernetes 作為註冊中心的微服務方案](https://mp.weixin.qq.com/s/j6CIZpMrSk4VO27viUlDrg)。

[Dubbo-go](https://github.com/apache/dubbo-go) 從最開始 Dubbo 的 Go 語言實現，已發展成為目前 Dubbo 多語言版本中1功能最強大者，它的發展離不開背後強大的 [Dubbo-go 社群](https://dubbogo.github.io/dubbo-go-website/img/dubbo-go-group.jpg)。除了上述 Dubbo-go 的自身特性外，透過跨社群合作，取得了如下成績：

- 透過與 MOSN 社群合作，已經實現 Dubbo/Dubbo-go 應用可以[零成本接入](https://mosn.io/zh/docs/dev/dubbo-integrate/)基於 MOSN 實現 [Dubbo Mesh](https://my.oschina.net/dubbogo/blog/4309475)，實現微服務和雲原生共存的 **“雙模微服務”**；
- 與 sentinel 社群合作，在 Dubbo/Dubbo-go 完整接入 [sentinel 的降級和限流方案](https://github.com/alibaba/sentinel-golang/tree/master/adapter/dubbo)；
- 與 Apollo 社群合作，在 Dubbo-go 中實現[遠端配置下發](https://juejin.im/post/5e5a837af265da575e37b6fa)；
- 與 Nacos 社群合作，實現基於 Nacos 的服務發現。

[Dubbo-go 社群](https://dubbogo.github.io/dubbo-go-website/img/dubbo-go-group.jpg) 2020 年 Q2 主要目標有：

- 釋出完全對齊 Dubbo 2.7.x 的 [v1.5.0 版本](https://github.com/apache/dubbo-go/tree/feature/dubbo-2.7.5)；
- 釋出對標 Dubbo 3.0 的 v1.6.0 版本；
- 在雲原生方面繼續自己的探索；
- 繼續與兄弟社群保持合作共進態勢，擴大自身使用範圍；
- 生產實踐上推進在阿里集團，以及更多廠家的落地。

專案（包括子專案）目前已先後在[攜程](https://www.infoq.cn/article/7JIDIi7pfwDDk47EpaXZ)、[塗鴉智慧](https://my.oschina.net/dubbogo/blog/4306343)和[螞蟻金服](https://www.infoq.cn/article/v9l8pIENAXZtTya45Wtb)等公司生產落地。今年阿里集團完成 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/2、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。我們所聊的“面向介面 -> 面向應用”的改造，主要體現在服務註冊、發現層面：

![4.png](https://ucc.alicdn.com/pic/developer-ecology/23dad0a61bb34810a1546e1d567faf01.png)

而我們說的面向應用的新模型，主要對第 2 點，即註冊中心的資料組織轉變為 “面向應用/例項” 粒度。這為我們解決兩個問題：

- 在服務發現層面與 Kubernetes Service 等微服務模型對齊；
- 服務發現的資料量將有一個量級的下降，從 “介面數 * 例項數 ”下降到 “應用數 * 例項數”。

具體可以參見文章《[Dubbo 邁出雲原生重要一步 - 應用級服務發現解析](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247491122&idx=1&sn=6c5529e6321a68ff107a5c7894eab599&chksm=fae515fdcd929cebe9928703a06c12435d5362d3f12f420d1f3f53c1d847710209cd1db4937c&token=1362588214&lang=zh_CN#rd)》，本系列文章後續也會有對這部分機制和實現的更深度解析。

## 雲原生基礎設施

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

### 基礎設施

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

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

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

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

- 不使用 Kubernetes Native Service，Kubernetes 只作為容器編排排程設施，繼續使用 Dubbo  自建的服務註冊、發現機制；
- 複用 Kubernetes Native Service，Dubbo 不再關心服務註冊，Dubbo Client 負責服務發現與流量分配；
- Dubbo sdk 往 Mesh 遷移，一方面要做到適應 Mesh 架構，成為 Mesh 體系下的 RPC 程式設計和通訊方案；另一方面要做到 Dubbo 與 Mesh 架構長期共存，互相打通服務發現和治理體系；
- 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、方案設計與進展解析等也將在此係列中釋出。敬請期待！

### 作者簡介

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

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/NDljVPQ4spFQksDM9TC--Q)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

Dubbo 雲原生之路：ASF 畢業一週年、3.0 可期

相關文章