作者 | 北緯、趙鈺瑩

導讀：2008 年，Dubbo 專案誕生；2014 年，由於內部團隊調整，Dubbo 暫停更新；2017 年，北緯帶領團隊重新喚醒 Dubbo，並將其捐獻給了 Apache 基金會。短短 15 個月，Dubbo 便從基金會畢業。如今，Dubbo 已經畢業一年，越來越多開發者開始詢問 Dubbo 3.0 到底有哪些變化，阿里巴巴內部到底用不用 Dubbo，這是不是一個 KPI 開源專案以及 Dubbo 和 Spring Cloud 之間到底是什麼關係。本文，將獨家對話 Dubbo 專案二代掌門人北緯（GitHub ID@beiwei30），聽他一一解答上述問題。

Dubbo 迴歸的這些年

Dubbo 專案誕生於 2008 年，最初只是一個阿里內部的系統；2011 年，阿里 B2B 決定將整個專案開源，一年時間就收穫了來自不同行業的大批使用者；2014 年，由於內部團隊調整，Dubbo 暫停更新；2017 年 9 月，就在該專案將近 3 年沒動靜的時候，Dubbo 連續釋出了好幾個新版本，並且開始在內部招募對 Dubbo 感興趣的同事。新版本背後的主力開發團隊是阿里巴巴中介軟體團隊，其中一個最重要的人就是北緯，他從 2017 年 7 月開始全面接手 Dubbo。

“我知道這是一個特別出名的開源軟體，但是很長一段時間沒有人維護，我當時在阿里內部的工作方向和 Dubbo 完全一致，也是做服務框架，所以對於認知 Dobbo 並不是非常困難。

接手之後，我們開始沒有做太多事情，只是對外表示會重新維護這個專案，就收到了很多積極的反饋，這讓我非常驚訝，很多開發者也在問我們可以重新維護多久。隨著對這個專案的深入瞭解，我發現國內很多大型廠商，甚至傳統國企都在廣泛使用該專案，當時也覺得自己的責任重大，不知道可不可以把這個專案做好。”

彼時，北緯面臨的第一個問題是：在 Dubbo 主版本停止更新的這些年，業界出現了很多 Dubbo 的分支版本，不同的團隊都在維護自己的分支，如果不重視這一客觀事實，很可能導致只有主版本在快速迭代，其他社群成員根本參與不進來，這樣的開源意義不大。採訪中，北緯表示：“對 Dubbo 來說，這些分支版本同樣重要。我們還是希望可以給大部分深度使用者一條安全的合併路徑，根據我們的主要版本進行迭代。在這個過程中，我們和幾大主流分支版本的開發團隊都進行過交流，他們也非常願意同主版本進行合併。”

在 Dubbo 正式復出之後，北緯也聽到了一些開發者的疑問，比如這次能維護多久之類的。“既然放到阿里巴巴下面，開發者有這樣的擔心，那我乾脆就把它放到中立的位置上，Apache 基金會是一個很好的選擇，因為 GPL 協議太偏理想化，Dubbo 專案更多用在商業化公司，GPL 協議可能會影響後續推廣。相對來說，Apache 協議比較實用。”

正是這一決定讓廣大開發者見到了最短時間從 Apache 基金會畢業的專案： 2019 年 5 月 21 日，Dubbo 在僅用時 15 個月的情況下從 Apache 基金會畢業。

“我記得，與 Dubbo 同期畢業的有五個專案，Dubbo 是用時最短的。我們並不著急讓 Dubbo 畢業，但我們原來預期的時間比 15 個月還要短，但礙於基金會的溝通流程，時間週期會相對拉長。”

Apache 基金會的特點是寬進嚴出，也就是說進去可能相對容易，但畢業是難的，而且非常強調公開透明。在國內，大部分人習慣透過微信和釘釘溝通，響應時間也會比較短，但 Apache 基金會是一個面向全球的組織，所有交流都基於郵件傳遞，一項提議必須在 72 小時內（考慮到全球的時差問題）沒有成員提出反對才可以被採納，這些流程都讓時間週期變得更長。

如今，Dubbo 專案已經畢業一年有餘，整個社群擁有 18 名 PMC 成員，57 名 committer，以及多達 370 名貢獻者，社群程式碼比例已經超過 50%。在採訪中，北緯表示，過去一年，Dubbo 在多語言建設方面先後從社群收穫了 JS、Python、Erlang、PHP、Go 的實現，特別鄭重感謝千米網、樂信以及其他開發者們，為社群帶來了多語言支援。提到 Dubbo，大家第一個想到的可能還是 Java，但目前 Dubbo go 已經在 1.5 版本追平 Dubbo java 2.7 的特性。目前正在和 Java 齊頭並進，一起規劃 Dubbo 3.0 中雲原生的路線圖。

自 Dubbo 2.7 版本之後，整個發版節奏逐漸變慢，很多開發者也注意到“Dubbo 3.0 will come soon”的公告掛了很久。北緯表示，其實是有意識放慢了發版節奏，追求功能的穩定，這不僅僅是因為 Apache Dubbo 的深度使用者，比如工商銀行、攜程、滴滴、鬥魚、瓜子等對 Dubbo 的使用規模越來越大，整個阿里經濟體未來也會開始在內部核心電商業務陸續推進 Dubbo 和 HSF 的融合，Dubbo 的使用者越多，團隊的敬畏感越強烈。

在帶領 Dubbo 前進的過程中，團隊也聽到了來自開發者社群的聲音，比如 Dubbo 和 Sping Cloud 是什麼關係？是不是二選一就夠了？Dubbo 和 gRPC 之間的差別是什麼？這是不是阿里的一個 KPI 開源專案？阿里內部用嗎？

阿里與 Dubbo 之間的關係

“事實上，從我負責這個專案以來，我個人的體感是大家一直比較擔心這個專案能不能持續發展，會不會斷更。我也知道一些開發者在擔心 Dubbo 只是阿里主導的 KPI 開源專案。”

根據 X-lab 開放實驗室最新發布的《2020 年微服務領域開源數字化報告》，Dubbo 的開源活躍度全球排名 693，在微服務框架中排名第五，僅今年參與過社群建設的開發者數量已經達到 500 多人。整個社群蓬勃發展，來自外部的程式碼貢獻量已經超過來自阿里員工的貢獻量。

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

在阿里巴巴雲原生公眾號後臺回覆“微服務報告”即可檢視完整報告。

“我一直認為社群很重要，單靠核心團隊的幾位工程師來做這件事情非常困難，一些想法也是我們想不到的。如今，全國各地有上百家企業在使用 Dubbo，僅依靠我們兩三位工程師的力量遠遠不夠，我們希望社群內的開發者可以更多地參與進來。”

一直以來，開源的理想狀態可能就是單純依靠情懷，但這真的很難做好，靠情懷的始終是少數人，尤其是中國目前的開源遠未達到這種狀態，還處於發展過程中。採訪中，北緯表示，對 Dubbo 而言，不管開發者最初進入並對專案有所貢獻的原因是什麼。重要的是，我們希望能夠讓整個社群保持開放，即便個別工程師僅僅只是為了日後找份工作來參與社群也沒有關係，我認為這種想法很正常，畢竟貢獻專案會佔據開發者很多業餘時間，我們也希望這個專案可以對大家有所幫助。

此外，阿里巴巴內部也在採用 Dubbo 專案，並且開始逐漸向核心交易場景推進。在 Dubbo 最初的成長過程中，阿里內部曾經提過“整個公司大統一，希望不要重複建設，但凡相同的專案都要合併”的想法。當時，淘寶的 HSF 專案也是一箇中介軟體服務框架，與 Dubbo 做的事情高度重合，所以當時表示要將兩個專案進行合併。

時至今日，HSF 和 Dubbo 在阿里經濟體內部都有落地的場景。北緯表示，選擇權由業務視自己的訴求來決定，技術上保證了框架之間的互操作。相對來說，電商場景裡 HSF 的使用是主流，而云的場景裡 Dubbo 使用更多。當然，對於這麼大規模的服務化場景，統一技術棧一直是我們的訴求和目標。在雲原生時代 Dubbo 3.0 的定義中，我們已經開始以開源的 Dubbo 作為核心進行融合，並以此為基礎定義雲原生場景中的關鍵特性，在集團部分電商業務上已經進入落地階段，後續也會跟大家分享我們的實踐經驗。

如何看待 Dubbo 和 Spring Cloud 的關係？

長久以來，總有開發者喜歡將 Dubbo 與 Spring Cloud 進行比較，提到這兩個名字的第一反應往往是應該選哪個，而不是二者如何配合使用。 在北緯看來，這主要還是技術選型的問題，以及使用者對隨之而來的切換成本的顧慮。其實這是一種誤解，兩者的關係不是非此即彼。今天的 Dubbo 已經成為了  Spring Cloud Alibaba 中一個重要的技術元件，Dubbo 服務和 Spring Cloud 服務可以完美的互相呼叫。未來，Dubbo 3.0 進一步的簡化了 Dubbo 和 Spring Cloud 混布場景中服務基礎設施的部署。

如今，Spring Cloud 依託於 Spring 已經成為 Java 開發的標準框架，這是不爭的

事實，並結合大量業界經驗逐漸抽象出一套微服務通用架構模式標準。這套標準的好處在於可以讓開發者非常便捷地進行微服務軟體產品開發，且在整個 Spring 生態的加持下已經成為開發者的“一攬子”解決方案。

相較之下，Dubbo 是阿里對微服務領域持續實踐的產品。在框架設計之初，擴充套件性、靈活性就被放在了一個很重要的位置，這也是為什麼社群對 Dubbo 的熱情一直高漲的原因。隨著 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 在註冊資料的模型上達成高度統一，複用同一套服務註冊中心，進一步簡化混布場景中的架構。

“我們把選擇的自由留給使用者，這是 Dubbo 3.0 中的重要目標。”

此外，北緯整個團隊也在積極發展 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 應用的能力。

Dubbo 和 gRPC？

Spring Cloud 和 Dubbo 之間部分互補可能說的通，但 Dubbo 和 gRPC 確實是極為相似的。作為高效能、開源且通用的 RPC 框架，gRPC 多年來受到了眾多開發者的歡迎和採納。

相似就免不了被開發者比較，對此，北緯很坦然：“我們從不避諱 gPRC，它是一個令人尊敬的對手，是雲原生基礎設施之間通訊協議的事實標準。gRPC 的發展以及 gRPC 每年的會議，我們一直都有關注。”

“我們從 gRPC 身上學到最有價值的一點就是反思 Dubbo 2 中協議設計的不足，開始重視雲原生支援領域裡兩個重要的問題：多語言支援和閘道器 /Mesh 解析友好。”採訪中，北緯表示，在 Dubbo 3.0 中，新版本的協議是重中之重，除了解決上述兩個問題，對 gRPC 協議的相容也是新協議的設計目標之一。

在雲原生時代，gRPC 作為 RPC 框架走在了前面，這一塊短板在北緯看來是要儘快補齊的，而 Dubbo 的優勢是不單單是一個 RPC，而且是一個有著強大治理能力的服務框架，可以這麼說，Dubbo 是 gRPC with batteries。同時，Dubbo 在國內使用者群體巨大，在業務向雲原生技術遷移的歷程中，Dubob 3.0 將可以發揮出巨大作用。

Dubbo 的未來發展

如今，社群中的很多開發者都對 3.0 版本期待已久。北緯表示，3.0 版本的主基調就是雲原生支援，重點思考雲原生友好的新一代 RPC 協議、應用級服務註冊發現、K8s 原生服務釋出、Mesh 控制面 xDS 協議對接以及分散式服務柔性等重磅級特性。

實際上，Dubbo 3.0 的功能會分階段進行，目前應用級服務發現已經在內部和一些頭部使用者的場景做試點，後續隨著專案的進展，團隊會第一時間釋出功能實現細節。“透過 Dubbo 3.0 的交付，我們期待帶來一款向雲原生遷移友好的，對雲原生基礎設施友好的新一代服務框架體系。”

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

就應用方而言，從介面級註冊發現到應用級註冊發現可以顯著降低註冊中心和客戶端的記憶體壓力。今年雙 11，雲原生服務治理規則會把 Dubbo 多年以來在大規模高併發服務治理方面的最佳實踐融入雲原生。下一代協議將基於 http2/protobuf 帶來更好的生態和 Reactive 的全面支援，柔性增強所涵蓋的自適應策略和分散式負載均衡將會在效能和穩定性上帶來更大的突破。北緯表示，在 Dubbo 3.0 發展過程中，急需更多高質量社群力量加入，共同打造下一代的服務框架。

回到 Dubbo 重啟開源之時，生態相對薄弱。畢業 15 個月之後的今天，Dubbo 生態已經日益完善。

（如今 Dubbo 豐富的擴充套件實現）

比如，多語言支援已經達到 6 種，30+ 生態子專案。在 Dubbo 主動整合周邊的同時，我們也被第三方開源專案 Spring Cloud Sleuth、Zipkin、Skywalking、Envoy、tengine 等主動整合。

“或許如今的生態還不夠完善，但也是極大豐富了，我心中的完善是希望能夠產出一個官方推薦的 Dubbo Stack，免除使用者選擇上面的煩惱。至於 Dubbo Stack 中是否都源自阿里，我倒是抱著順其自然的態度，這還是需要資料說話，誰家的元件在生產系統中運用最廣，我們就推薦誰。總的來說，這件事情的決定權在社群和 Dubbo 使用者。”

嘉賓介紹

北緯，Dubbo 第二代掌門人，Apache Dubbo PPMC & Spring Cloud Alibaba 負責人。

“ 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”