十年再出發，Dubbo 3.0 Preview 即將在 3 月發佈

做者 | Apache Dubbo
來源|阿里巴巴雲原生公衆號

• 2011 年，阿里 B2B 團隊決定將項目開源，一年時間就收穫了來自不一樣行業的大批用戶

• 2014 年，因爲團隊調整，Dubbo 暫停更新

• 2017 年，Dubbo 開源重啓

• 2019 年，Dubbo 在僅用時 15 個月的狀況下從 Apache 基金會畢業

• 2020 年，阿里內部開始 HSF 和 Dubbo 的融合

• 2021 年 3 月，Dubbo 3.0 Preview 即將發佈

• ……

從 2011 到 2021，Dubbo 已經開源十年。十年，對於風起雲涌的雲計算領域是漫長且充滿變化的，但 Dubbo 在這個時代的浪潮裏不只沒有變成被人遺忘的「前浪」，更在雲原生時代，迎來內核雲原生技術棧全面升級。本文是對阿里集團服務框架負責人北緯的採訪，他在阿里同時負責 HSF、Dubbo 和 Spring Cloud Alibaba。本文講述了他 2017 年接手 Dubbo 後社區的進展，並展望開源十年的 Dubbo 將如何走好雲原生之路。

---

2017年，我開始接手 Dubbo 項目後，咱們對外表示會從新維護這個項目，就收到了不少積極的反饋，隨着對這個項目的深刻了解，我發現國內不少大型廠商，甚至傳統國企都在普遍使用該項目，才意識到身上的責任。Dubbo 3.0 Preview 版即將在 3 月發佈，咱們準備了 Dubbo 3.0 前瞻系列電子書（**獲取方式見文末）**，也借這個機會你們聊聊 Dubbo 重啓開源後被頻繁問到的問題：

• 從 Apache 畢業兩年不到的時間，咱們都作了什麼？
• 阿里內部是如何進行 Dubbo 和 HSF 融合的？規模怎麼樣？
• 如何看待 Spring Cloud 和 gRPC?
• 3.0 有什麼值得期待的？

同期畢業最快的 Apache 項目，多語言全面發展

2017 年，我負責這個項目以來，一些開發者在擔憂 Dubbo 只是阿里主導的 KPI 開源項目，比較擔憂這個項目能不能持續發展、會不會斷更。既然這樣，那我乾脆就把它放到中立的位置上，Apache 基金會是一個很好的選擇， 正是這一決定讓 Dubbo 成爲同期五個項目中最快從 Apache 基金會畢業的項目：2019 年 5 月 21 日，Dubbo 在僅用時 15 個月的狀況下從 Apache 基金會畢業。

事實證實，把 Dubbo 捐給 Apache，讓 Dubbo 變成一個社區主導的項目是一個很是正確的決策。根據 X-lab 開放實驗室最新發布的《2020 年微服務領域開源數字化報告》，Dubbo 的開源活躍度全球排名 693，在微服務框架中排名第五，參與過社區建設的開發者數量已經超過 1 萬多人，來自外部的代碼貢獻量已經超過阿里員工的貢獻量。

數據來源 -《2020 年微服務領域開源數字化報告》

Dubbo 項目從 Apache 畢業 2 年不到的時間，整個社區擁有 21 名 PMC 成員，61 名 committer，以及多達 370 名貢獻者。在過去一年，Dubbo 在多語言建設方面前後從社區收穫了 JS、Python、Erlang、PHP、Go 的實現，特別鄭重感謝公里網、攜程網、樂信以及其餘開發者們捐獻或者提交了這些多語言版本的絕大多數代碼，爲社區帶來了豐富的多語言支持解決方案。在於雨的帶領下，Dubbo-go 能夠說是當前衆多多語言版本中最活躍的一個分支，有者很是活躍的 go 子社區及持續增加的企業級用戶，目前 Dubbo go 已經在 1.5 版本追平 Dubbo Java 2.7 的特性；目前正在和 Java 齊頭並進，一塊兒規劃 Dubbo 3.0 中雲原生的路線圖。

咱們對這個大版本 Dubbo 3 的定義是雲原生、阿里背書。計劃分爲三個版本迭代，在後面 Dubbo 3 的路線圖中有詳細的描述。Dubbo 3.0 正在緊鑼密鼓的開發中，核心功能包括 Dubbo3 協議、應用級服務發現、新版路由規則等，go 與 java 版本預計將以一樣的時間節奏兌現以上全部功能，3 月底會有 preview 版本與社區見面。

過去 2 年社區的經歷更讓我相信，單靠核心團隊的幾位工程師憑着單純的開源情懷是很難持續的。全國各地有上百數千家企業在使用 Dubbo，僅依靠咱們一個小團隊的力量遠遠不夠，咱們但願社區內的開發者能夠更多地參與進來。對 Dubbo 而言，無論開發者最初進入並對項目有所貢獻的緣由是什麼。重要的是，咱們但願可以讓整個社區保持開放，即使個別工程師僅僅只是爲了往後找份工做來參與社區也沒有關係，我認爲這種想法很正常，畢竟貢獻項目會佔據開發者不少業餘時間，咱們也但願這個項目能夠對你們有所幫助。

Dubbo 和 HSF 融合，阿里先本身用上 Dubbo 再說

我面臨的第二個最大的質疑是：阿里內部都不用 Dubbo，如何得到開發者的信任？

熟悉阿里技術歷史的同窗可能知道，淘寶的 HSF 項目也是一箇中間件服務框架，與 Dubbo 作的事情高度重合。而 Dubbo 在開源過程當中不少開發者詬病的也是阿里本身都沒有在用 Dubbo。這也是咱們一直在苦惱的：阿里內部的自研體系、商業化的產品技術與開源的項目，三方的技術路線一直沒有機會融爲一體。

隨着阿里自研體系的上雲，融合的機遇終於到來了。2020 年，阿里雲提出了「三位一體」理念，即：將「自研技術」、「開源項目」、「商業產品」造成統一的技術體系，最大化技術的價值。

HSF 目前以 Dubbo 3.0 爲核心，內部特性以 Dubbo 插件的方式存在，並把 HSF 只在阿里集團內部大規模場景下高併發、高性能等優化經驗應用到 Dubbo 3.0 核心上，實現了內外功能的統一，使得社區和客戶都能用到這些優質經驗；另一方面，Dubbo 3.0 雲原生相關的功能借助於社區開發力量獲得進一步發展。經過「三位一體」與社區達成開放雙贏的局面。

個人老領導林昊、阿里人稱畢大師，因爲設計開發了 HSF 今年得到了中國計算機學會的傑出工程師獎，他在獲獎採訪中提到：做爲工程師來說，很大的成就感來自於本身所作的技術被公司大範圍的使用，而且對這家公司的業務發展能起到很大的支撐做用；更大的成就感來自於本身作所的技術背後的思想、實現思路能影響到中國各大互聯網公司、企業去擁抱微服務。隨着 Dubbo 和 HSF 的整合，咱們在整個開源的體系中更多地去展示了 HSF 的能力，可以讓更多的人經過使用 Dubbo 像阿里巴巴以前使用 HSF 同樣更好地構建服務化的系統。

在 2020 年 雙11，Dubbo 3.0 在集團電商業務上已經進入落地階段，電子書裏也會跟你們分享一些咱們的實踐經驗。

如何看待 Spring Cloud 和 gRPC？

在 Dubbo 沉寂的幾年，出來不少新生的服務框架，Dubbo 和 Sping Cloud 是什麼關係？是否是二選一就夠了？Dubbo 和 gRPC 之間的差異是什麼？

Dubbo 和 Spring Cloud 如何二選一？

長久以來，總有開發者喜歡將 Dubbo 與 Spring Cloud 進行比較，提到這兩個名字的第一反應每每是應該選哪一個，而不是兩者如何配合使用。在我看來，這主要仍是技術選型的問題，以及用戶對隨之而來的切換成本的顧慮。其實這是一種誤解，二者的關係不是非此即彼。今天的 Dubbo 已經成爲了  Spring Cloud Alibaba 中一個重要的技術組件，Dubbo 服務和 Spring Cloud 服務能夠完美地互相調用。將來，Dubbo 3.0 進一步的簡化了 Dubbo 和 Spring Cloud 混布場景中服務基礎設施的部署。 Spring Cloud 依託於 Spring 已經成爲 Java 開發的標準框架，這是不爭的事實，並結合大量業界經驗逐漸抽象出一套微服務通用架構模式標準。這套標準的好處在於可讓開發者很是便捷地進行微服務軟件產品開發，且在整個 Spring 生態的加持下已經成爲開發者的「一攬子」解決方案。

和 Spring Cloud 不一樣，Dubbo 在設計之初，擴展性、靈活性就被放在了一個很重要的位置。Dubbo 很容易集成別人，別人也容易集成 Dubbo。同時，Dubbo 通過大量用戶生產驗證，阿里在服務化領域持續實踐的產品。這兩點是 Spring Cloud 目前沒法作到的。隨着 Dubbo 恢復更新，其場景豐富程度與穩定性也有了很是大的提高，目前已經在多家頭部公司大規模應用。

回到衆多開發者對技術選型問題的顧慮：這兩套框架並非非此即彼。相反的，用戶能夠輕鬆的在這兩套框架之間切換，甚至將來能夠完美的在一塊兒協同工 做，這得益於 Spring Cloud Alibaba 的出現。

Spring Cloud 擁有一個強大的國際化社區，阿里巴巴做爲社區裏的重要成員，也貢獻出了 Spring Cloud Alibaba 這套實現，這也是目前整個 Spring Cloud 體系下最完善而且在持續更新的實現方案。

Spring Cloud Alibaba 出現

如今的 Dubbo 2.7 已經能夠很好的在 Spring Cloud 體系下工做。經過 Spring Cloud Alibaba 中 Dubbo 的集成，Spring Cloud 應用能夠調用原生髮布的 Dubbo 服務，Spring Cloud 發佈的 Dubbo 服務也能夠被原生的 Dubbo 客戶端調用。這個得益於 2.7 中服務自省的實驗性項目，以及 Spring Cloud 側對 Dubbo 的適配。

在正在開展的 3.0 大版本中，這個實驗性的項目進化爲原生應用級服務註冊機制。經過這個特性，將來 Spring Cloud 應用和 Dubbo 應用能夠更加完美的混布。用戶能夠爲 Spring Cloud 和 Dubbo 複用同一套服務發現、服務配置、和服務管理體系，爲 Dubbo 和 Spring 互通須要額外搭建網關將成爲過去式，用戶能夠零成本的在二者之間切換，或者視場景不一樣選擇不一樣的框架，甚至能夠在同一個應用中混用。Dubbo 與 Spring Cloud 混布場景中業界常規的 Proxy 集羣終於去掉，整個體系的架構更加簡單和穩定。在 Dubbo 3.0 版本中，整個團隊會繼續進化應用級服務註冊的想法，指望經過這項工做讓 Spring Cloud Alibaba 與 Dubbo 在註冊數據的模型上達成高度統一，複用同一套服務註冊中心，進一步簡化混布場景中的架構。

另外，咱們團隊也在積極發展 Spring Cloud Alibaba 生態。做爲國內 Java 界最具影響力的團隊之一，阿里中間件團隊一直在密切關注 Spring 項目，經過 Spring 的封裝提高阿里的中間件開發體驗。阿里巴巴電商體系絕大部分應用已經實現 Boot 化。

當 Spring Cloud 初具影響力的時候，咱們主動經過 Spring Cloud 來集成阿里巴巴開源組件就變成一件天然而然的事情了 目前，Spring Cloud Alibaba 已經支持 Nacos 做爲服務註冊中心、配置中心，Sentinel 做爲限流，Seata 做爲分佈式事務組件，RocketMQ 做爲分佈式消息組件，固然還有 Dubbo 做爲 RPC 組件，全面取代了已經宣佈中止更新的 Spring Cloud Netflix 全家桶。另外，爲了加速國內工程師對 Spring Initializr 的訪問，團隊還經過阿里雲上託管的 start.aliyun.com 提供了快速生成 Spring Cloud Alibaba 應用的能力。

不管從 GitHub 的項目活躍度數據仍是關注度數據來看，絕不誇張地說，Spring Cloud Alibaba 已經成爲 Spring Cloud 框架中的事實標準了。

如何看待 gRPC？

咱們從不避諱 gRPC，它是一個使人尊敬的對手，是雲原生基礎設施之間通信協議的事實標準。

可是 Dubbo 的優點是不僅僅是一個 RPC，並且是一個 有着強大治理能力的 服務框架。咱們認爲：Dubbo 是 gRPC with batteries。

咱們從 gRPC 身上學到最有價值的一點就是反思 Dubbo 2 中協議設計的不足，開始重視雲原生支持領域裏兩個重要的問題：多語言支持和網關/Mesh 解析友好。在 Dubbo 3.0 中，新版本的協議是重中之重，除了解決上述兩個問題，對 gRPC 協議的兼容也是新協議的設計目標之一。gRPC 有幾項明顯的優點：在支持 HTTP/2 協議上走在了前列，提供了很是豐富的多語言庫支持，與 Google 主導的許多雲原生基礎設施無縫打通。gRPC 及時下流行的 Mesh 等雲原生技術構建了一套看起來相對完善的微服務技術棧，落地這套技術棧看起來是基於 gRPC 的微服務解決方案。

但 gRPC 框架自身而言仍是專一在 RPC 通訊。相比而言，Dubbo 提供了一站式的微服務開發、治理解決方案，Dubbo 有更易用的面向接口的服務定義模型，有更完善的服務發現、服務治理機制。同時，在即將發佈的 3.0 規劃中，Dubbo 3 也將提供官方的 Mesh 解決方案支持，繼續給社區帶來易用的、一站式的解決方案。 

Dubbo 3.0 展望：對雲原生支持

社區中的不少開發者都對 3.0 版本期待已久。Dubbo 3 的主基調就是雲原生支持，計劃分爲三個版本迭代。重點交付雲原生友好的新一代 RPC 協議、應用級服務註冊發現、K8s 原生服務發佈、Mesh 控制面 xDS 協議對接以及分佈式服務柔性等重磅級特性。

• 3.0 版本，重點發布應用級服務註冊發現、Tripe、新路由規則。

• 3.1 版本，重點發布 K8s 原生服務、Mesh 控制面 xDS 協議對接。

• 3.2 版本，重點發布分佈式服務柔性。

目前應用級服務發現已經在內部和一些頭部用戶的場景作試點，後續隨着項目的進展，團隊會第一時間發佈功能實現細節。經過 Dubbo 3.0 的發佈，咱們期待帶來一款向雲原生遷移友好的，對雲原生基礎設施友好的新一代服務框架體系。

將來，Dubbo 項目總的發展基調仍是堅持合做開放的開源路線不動搖，追求更高質量和功能更完善的路線不動搖。目前，社區發展的重中之重是 Dubbo3.0 演進。在不久後的 9 月份， Dubbo 3.0 應用級註冊發現將在阿里巴巴內部和開源側各公司落地。這不只是 Dubbo 邁向雲原生微服務的第一步，也是對接 K8s 註冊發現和跨框架 RPC 互通的前提。

就應用方而言，從接口級註冊發現到應用級註冊發現能夠顯著下降註冊中心和客戶端的內存壓力。今年 雙11，雲原生服務治理規則會把 Dubbo 多年以來在大規模高併發服務治理方面的最佳實踐融入雲原生。下一代協議將基於 http2/protobuf 帶來更好的生態和 Reactive 的全面支持，柔性加強所涵蓋的自適應策略和分佈式負載均衡將會在性能和穩定性上帶來更大的突破。

回到 Dubbo 重啓開源之時，生態相對薄弱 。現在，Dubbo 生態已經日益完善。

Dubbo 豐富的擴展實現

好比，多語言支持已經達到 6 種，30+ 生態子項目。在 Dubbo 主動集成周邊的同時，咱們也被第三方開源項目 Spring Cloud Sleuth、Zipkin、Skywalking、Envoy、tengine 等主動集成。

我心中的完善是但願可以產出一個官方推薦的 Dubbo Stack，免除用戶選擇上面的煩惱。至於 Dubbo Stack 中是否都源自阿里，我卻是抱着順其天然的態度，這仍是須要數聽說話，誰家的組件在生產系統中運用最廣，咱們就推薦誰。總的來講，這件事情的決定權在社區和 Dubbo 用戶。 最後，感謝十年來 Dubbo 的用戶和社區貢獻者們，對於 Dubbo 3.0 Roadmap 中的雲原生友好的新一代 RPC 協議、應用級服務註冊發現、K8s 原生服務發佈等重磅級特性，**咱們梳理了一系列前瞻的文章整理成了電子書。