卷首語：對話 Dubbo掌門人北緯：3.0 將至，這個版本會帶來哪些新功能？
作者 | 趙鈺瑩
2008 年，Dubbo 項目誕生；2014 年，由於內部團隊調整，Dubbo 暫停更新；2017 年，北緯帶領團隊重新喚醒 Dubbo，並將其捐獻給了 Apache 基金會。短短 15 個月，Dubbo 便從基金會畢業。如今，Dubbo 已經畢業一年，越來越多開發者開始詢問 Dubbo 3.0 到底有哪些變化。近期，InfoQ 獨家對話 Dubbo 項目二代掌門人北緯（GitHub ID@beiwei30），聽他解答上述問題。
“事實上，從我負責這個項目以來，我個人的體感是大家一直比較擔心這個項目能不能持續發展，會不會斷更。我也知道一些開發者在擔心 Dubbo 只是阿里主導的 KPI 開源項目。”
根據 X-lab 開放實驗室最新發布的《2020 年微服務領域開源數字化報告》，Dubbo 的開源活躍度全球排名 693，在微服務框架中排名第五，僅今年參與過社區建設的開發者數量已經達到 500 多人。 整個社區蓬勃發展，來自外部的代碼貢獻量已經超過來自阿里員工的貢獻量。
長久以來，總有開發者喜歡將 Dubbo 與 Spring Cloud 進行比較，提到這兩個名字的第一反應往往是應該選哪個，而不是二者如何配合使用。 在北緯看來，這主要還是技術選型的問題，以及用戶對隨之而來的切換成本的顧慮。其實這是一種誤解，兩者的關係不是非此即彼。今天的 Dubbo 已經成爲了 Spring Cloud Alibaba 中一個重要的技術組件，Dubbo 服務和 Spring Cloud 服務可以完美的互相調用。未來，Dubbo 3.0 進一步的簡化了 Dubbo 和 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 在註冊數據的模型上達成高度統一，複用同一套服務註冊中心，進一步簡化混布場景中的架構。
如今，社區中的很多開發者都對 3.0 版本期待已久。3.0 版本的主基調就是雲原生支持，重點思考雲原生友好的新一代 RPC 協議、應用級服務註冊發現、K8s 原生服務發佈、Mesh 控制面 xDS 協議對接以及分佈式服務柔性等重磅級特性。
實際上，Dubbo 3.0 的功能會分階段進行，目前應用級服務發現已經在內部和一些頭部用戶的場景做試點，後續隨着項目的進展，團隊會第一時間發佈功能實現細節。在不久後的 9 月份， Dubbo 3.0 應用級註冊發現將在阿里巴巴內部和開源側各公司落地。
就應用方而言，從接口級註冊發現到應用級註冊發現可以顯著降低註冊中心和客戶端的內存壓力。今年雙 11，雲原生服務治理規則會把 Dubbo 多年以來在大規模高併發服務治理方面的最佳實踐融入雲原生。下一代協議將基於 http2/protobuf 帶來更好的生態和 Reactive 的全面支持，柔性增強所涵蓋的自適應策略和分佈式負載均衡將會在性能和穩定性上帶來更大突破。
目錄
熱點丨 Hot
思科前員工爲報復惡意刪除 400 多臺虛擬機，公司損失超 1600 萬
理論派 | Theory
一個微服務業務系統的中臺構建之路
從 0 到 1 搭建技術中臺之 ID 生成服務實踐
推薦文章 | Article
重新思考日誌：業務系統竟然是一個大數據庫？
深度解讀：實時數倉架構對比與基於 Flink 的典型 ETL 場景實現
觀點 | Opinion
Java 的新未來：逐漸“Kotlin 化”