點擊右上方，關注開源中國OSC頭條號，獲取最新技術資訊
Dubbo 去年宣佈重啟維護，到現在已經一年有餘，當初重啟的消息在開發者中引起了強烈的反響，很多人看好，也有人持懷疑的態度，甚至到今天，還是有不少人認為 Dubbo 早已死去，回不了魂。
質疑聲中，Dubbo 將首要目標定位於重新激活社區，贏回開發者的信任。在這個過程中，Dubbo 發佈了多個版本，並逐漸從一個 RPC 框架向微服務生態系統轉變；團隊 “把 Dubbo 打造成一個國際化與現代化項目”的探索目前來看也有所呼應，比如年初 Dubbo 入駐 Apache 軟件基金會孵化器，比如它在特性中提供了更加全面的異步支持；而目前 GitHub 上的 star 數也已經有 2.3w+。
期間還有 Dubbo 3.0 的消息放出，3.0 將會是一個變革的版本，它去一切阻塞的變化甚至將影響到阿里 10 多年積累的中間件。
不難看出，目前 Dubbo 還活著。近期 Dubbo 將發佈重啟後的第一個里程碑版本 2.7.0，而且還預告了項目即將從 Apache 軟件基金會畢業，藉此機會，我們採訪了 Dubbo 的項目負責人北緯，請他為開發者梳理了重啟維護這一年多 Dubbo 的進展，並分享了接下來的計劃。
開源中國：2.7.0 新版本最值得關注的地方在哪裡?
北緯：Dubbo 2.7.0 添加了社區呼聲很高的異步化支持、以及註冊中心與配置中心分離這兩個特性。
與 2.6 及以前的版本相比，異步化支持不再侷限於基於 Future 接口的異步，也不再僅僅侷限於只能在客戶端異步。具體來說，Dubbo 2.7.0 版本全面擁抱 JDK8，在客戶端開始支持基於 CompletableFuture 的異步編程範式，在服務端支持基於 AsyncContext 的異步模型。
2.6 及以前的版本，元數據全部存儲在 URL 上，配置信息和註冊信息只能存儲在註冊中心上，註冊中心的容量和擴展成為瓶頸。這個限制在使用 ZooKeeper 作為註冊中心的大規模 Dubbo 應用場景下尤為突出。
在 2.7.0 中，通過對 URL 的改造，將註冊中心拆分成了三個中心，分別是註冊中心、配置中心和元數據中心，三者各司其責，不僅有效地解決了上述容量問題，而且很好地適應了微服務的技術架構，用戶可以開始自由選擇適合自己場景的註冊中心和配置中心。
2.7.0 將內建支持 ZooKeeper、Nacos 和 Apollo 等第三方註冊和配置中心，在後續的版本中，還會進一步提供對 Consul 和 etcd 的支持。另外，通過引入一個全新的元數據中心，將與註冊配置無關的服務信息單獨存儲，除了減輕配置中心與註冊中心的工作壓力之外，還為將來更豐富的服務治理打下基礎。未來，Dubbo 會基於元數據中心提供服務測試、服務 Mock 以及服務 API 管理等特性。
針對三個中心的分離，Dubbo 還會配套發佈全新設計的 Dubbo Ops 控制檯。
另外，2.7.x 會是 Dubbo 在 Apache 軟件基金會畢業的版本，安裝包包名正式切換到了 org.apache.dubbo，為了保證向前的兼容性，我們還在這個版本中提供了 com.alibaba.dubbo 的兼容包。
開源中國：多語言支持現在看只有一個 PHP 版本對齊得比較完善，Python 和 Node 版本是提供了一個客戶端去配合實現功能。在語言支持這方面，現在進展是怎麼樣，有什麼計劃？
北緯：除了 PHP 版本對齊得比較好以外，Node 版本也值得推薦。目前生態中的 Node 實現有兩個版本，分別是
千米網貢獻的 dubbo2.js 和螞蟻金服 egg 團隊貢獻的 egg-dubbo-rpc。這些語言的實現都是在生產系統裡驗證過的，其中 egg 的實現既支持客戶端也支持服務端。除了 PHP 和 Node，Dubbo 還提供了 Go 和 Python 支持。其中 Python 版本支持客戶端與服務端互通，走的是 json-rpc 協議，Go 版本將支持原生 Dubbo 協議，並計劃同時提供客戶端和服務端。
需要強調的是，除了多語言客戶端的支持，Dubbo 基於標準的 Java REST API——JAX-RS 2.0實現了 REST 調用支持，具體的使用方法可以參照這裡：
http://dubbo.apache.org/zh-cn/docs/user/references/protocol/rest.html
總的來說，相比於服務端，客戶端是 Dubbo 多語言支持的重點。從實用的角度來講，社區大量的訴求集中在如何用多語言調用後臺的 Dubbo 服務。當然，目前多語言的支持還處於起步階段，一方面是主流語言覆蓋不夠，比如 .NET 還沒有可用版本，另一方面是因為各個語言的成熟度參差不齊，社區投入不夠。
雖然 Service Mesh 的方案在這兩年發展得如火如荼，但我們也發現原生多語言客戶端在大量的場景中還會持續存在很長的時間，因此我們十分重視原生多語言客戶端的建設。後面總體的思路是
定義 Dubbo 原生客戶端最小功能集，以及成熟度評估標準，持續運營社區，吸引更多的多語言志願者加入。開源中國：重啟維護這一年來主要的工作是關於哪些方面的？實質進展如何？
北緯：說到這個，其實 Dubbo 最近才剛剛在開源中國發起的“最受歡迎中國開源軟件評選”中取得了第三名（Java 類第一名）的好成績，感謝開發者們對 Dubbo 的信任，也感謝開源中國發起的這項活動。
自重啟維護以來，到 2.7.0 發佈，Dubbo 已經累計發佈了 13 個版本。在這個過程中從零開始搭建 Dubbo EcoSystem，目前生態初具規模：
- 逐步提供了 Node、Python、Go 和 PHP 語言客戶端實現、開發工具及配套(Initializr、Benchmark、IDE plugin) 與 samples
- 豐富了核心 SPI 的擴展實現，包括 Hessian、Avro、Protobuf、HTTP/2、Thrift、JMS、etcd3、Sentinel、Nacos、Apollo、K8S 與 Docker
- 改造並重新實現了 Dubbo Ops
- 孵化了 27 個子項目
同時，不少微服務開源項目開始主動對接 Dubbo，包括 Zipkin、spring-cloud-slueth、SkyWalking、Pinpoint 和 Jboot 等。
社區方面，GitHub 上 star 數已經突破 2.3w，增長 150%，在 GitHub Java 項目中排名前十，目前已有 25 位 PPMC 和 committer、162 位 contributor (自重啟開源以來增長了 250%），共舉辦了 5 場 meetup，現場參與人數 2300+，線上參與人數 35000+。
下邊 star 的增長數據可以大致看出 Dubbo 的成長：
目前 Dubbo 正在 Apache 軟件基金會進行孵化，預計在未來的幾個月將畢業成為頂級項目。
當然，這些並不是炫耀 Dubbo 重啟開源後所取得的成績，而是說在社區的共同努力下，Dubbo 正發揮著其更大的技術價值，讓成千上萬的開發者收益，這也是 Dubbo 團隊成就感的最大來源。
我們除了感激社區的信賴之外，心中也充滿了敬畏。因為 Dubbo 在國內的用戶之多，已遠超我們的想象。在“誰在使用 Dubbo”的調研中，目前已有 124 名用戶提供了自己的使用場景，其中不乏著名的互聯網公司和大型國企。我們相信這裡收集的只是國內用戶中的一小部分，只有更加努力，不斷讓 Dubbo 變得更好，才能不辜負使用者對 Dubbo 的信賴。
誰在使用 Dubbo：https://github.com/apache/incubator-dubbo/issues/1012
過去這一年，團隊的目標是重新激活社區和生態。通過線下開發者沙龍、開發者訪談、社區的 issues、pull request 以及郵件組的互動等方式來傾聽社區的聲音，同時，我們把 Dubbo 捐獻給 Apache 進行孵化，積極發展外部的 committer 和 PPMC member，嚴格按照 Apache 之道來運作。通過這些努力，重新贏得了社區的信任。
接下來我們會更加關注核心能力的演進，2.7.0 版本是一個里程碑。這個版本準備了與微服務及雲原生環境中基礎設施對接的技術基礎，未來，Dubbo 將會提供對應的適配，使得 Dubbo 可以更好地融入到微服務和雲原生體系中去。
這裡也順便預告一下，近期我們 2019 年的第一場 meetup 也快來了，歡迎關注：http://t.cn/Ebyekd6。
開源中國：去年年初透露的 3.0 目前是個什麼情況？當初甚至說 3.0 去一切阻塞的變化將影響到阿里 10 年來積累的中間件，那現在具體情況如何？（2.7 中提到的實現全異步編程跟這個去阻塞有什麼不同？）另一方面，3.0 中的 Service Mesh 建設現在如何了？其它方面呢？
北緯：過去一年多工作的重心是激活社區和生態。目前，我們已經開始把工作的重心逐步轉向核心建設，目標就是提供現代化的技術核心，解決好微服務、容器化與雲原生等問題。已經發布的 2.7.0 是第一個里程碑，3.0 同步進入開發階段。
這裡要指出的是，3.0 中規劃的去阻塞和 2.7 中提供的異步是兩個層面的特性。2.7 中的異步是建立在傳統 RPC 中 request – response 會話模型上的，而 3.0 中的異步將會從通訊協議層面由下向上構建，關注的是跨進程、全鏈路的異步問題。
通過底層協議開始支持 streaming 方式，不單單可以支持多種會話模型，還可以在協議層面開始支持反壓、限流等特性，使得整個分佈式體系更具有彈性。所以，2.7 關注的異步更侷限在點對點的異步（一個 consumer 調用一個 provider），而 3.0 關注的異步化，寬度上則關注整個調用鏈上的異步，高度上則向上又可以包裝成 Rx 的編程模型。
有趣的是，Spring 5.0 發佈了對 Flux 的支持，隨後開始解決跨進程的異步問題，有興趣的開發者可以關注一下目前 RSocket 的發展情況。
3.0 中受到關注的還有 Dubbo Mesh 的發展。我們希望 Dubbo Mesh 未來可以進入 Envoy 社區，目前 Dubbo 協議已經被 Envoy 支持。當然，Dubbo Mesh 離真正可用還有很長一段距離，其在選址、負載均衡和服務治理方面的工作需要繼續在數據面建設，另外，控制面板的建設在社區也沒有提上日程。
最後值得一提的是，Dubbo 3.0 定下了內外融合的策略，也就是說 3.0 的核心最終會在阿里巴巴的生產系統中部署，相信通過大流量、大規模的考驗，Dubbo 用戶可以獲得一個性能、穩定、服務治理實踐各方面俱佳的核心，用戶在生產系統中採用 3.0 也會更加放心。
開源中國：接下來 Dubbo 將會從 Apache 孵化器畢業，除了有個名譽，具體對項目之後的維護、發展有什麼影響？
北緯：Apache 孵化器主席 Justin Mclean 每次來中國都會分享什麼是“Apache 之道”，它提倡公益使命、實用主義、社區勝於代碼、公開透明與共識政策和任人唯賢，具體可以參照這篇 Apache 孵化器主席 Justin Mclean 的分享：
https://mp.weixin.qq.com/s/ULea2-uDEG5HRbRewuZjIg
Dubbo 進入 Apache 進行孵化，目的就是遵循 Apache 之道來規範化地發展 Dubbo。同時，通過孵化，Dubbo 團隊的所有成員，對於如何運營好一個開源項目，建設好一個開源社區有了更深的體驗，也就是說，孵化過程就是 Dubbo 團隊自我學習和進階的過程。
從孵化器畢業是一種榮譽，但這並不是結束，而是另一種開始。這有點像求學，畢業並不意味著學習上的中斷，而是發揮更大社會價值的開始。畢業也更像是一個成人禮，意味著 Dubbo 團隊已經符合 Apache 對一個成熟開源項目的要求，並開始具備獨立發展的能力。
Dubbo 自從加入 Apache 的那一天起，就不再屬於阿里巴巴。Dubbo 變得更好，是因為已經有越來越多來自社區的開發者參與到 Dubbo 的共建中。例如，Dubbo 目前的 162 位 contributor 中，有接近 90% 都是來自非阿里巴巴的開發者，這個比例在未來應該會更高。
開源中國：最近 Netflix 官方表示不再繼續開發 Hystrix，用戶被迫遷移，前一陣子 Netflix 也同樣宣佈了 Eureka 2.0 不再維護。而實際上，Spring 官方近期也表明 Netflix 相關項目進入維護模式（Maintenance Mode），即 Spring Cloud 團隊不會再向 Netflix 模塊添加新功能。這讓開發者對 Netflix 產生質疑，有些人覺得 Spring Cloud 中的 Netflix 組件實現再用下去會不會有什麼風險，不少開發者表示要另尋高明。而此時阿里正在建設的 Dubbo EcoSystem 與開源不久的 Spring Cloud Alibaba 正好進入大家的視野。但是開發者也在觀望，不知道 Dubbo EcoSystem 與 Spring Cloud Alibaba 是否可以及時地接過大旗。
北緯：正如大家所看到的，今年發生在 Netflix 上的事情，對 Spring 生態產生了不小的影響，但作為開發者我們應該感謝 Netflix 在過去以及現在正在做的對開源的貢獻。
做開源的技術人都有一種技術情懷，但僅憑情懷，很難將開源堅持下去，最終還是要回歸到技術和商業的本質關係，即技術可以推動商業發展，但也需要商業來賦能技術前行。如果一家企業的戰略主航道上，技術並不是其發展方向之一，那麼其開源項目要維持下去的難度就很大。因此，在開源領域，我更看好技術服務型的企業，即對外輸出技術和相關服務是企業的主營業務之一。
阿里巴巴在服務化改造和微服務領域實踐多年，幾乎涵蓋了微服務技術棧的所有產品和組件，例如 Spring Cloud Alibaba 滿足了在 Spring Cloud 體系中使用阿里巴巴技術棧的需求，Nacos 提供了註冊中心和配置中心方面的功能，Sentinel 則解決了因高流量等訪問行為帶來的架構可靠性的問題。另外，作為已經成為 Apache 頂級項目的 RocketMQ，近期發佈的首個社區子項目 RocketMQ-Spring-Boot，實現了 Spring 體系中通過 RocketMQ 進行分佈式事務的回查和事務消息的發送。
其實，在微服務開發的領域，除了 RPC 和服務註冊發現，開發者還需要更多的能力，例如 API 網關、分佈式監控和分佈式事務等，在這些方面由於沒有事實上推薦的方案，開發者在調研和選型的過程通常都比較痛苦，甚至會遇到個別開源項目不再繼續維護的窘境。
如何通過 Dubbo 把這些微服務領域的其它能力整合起來，形成一套完整的解決方案，成為一個亟待解決的問題。
像前邊提到的，我們計劃並已經著手圍繞 Dubbo 打造一個微服務生態，它包含一系列開源項目，涵蓋微服務開發中的各個方面。這裡面的項目都是經過 Dubbo 社區共同評估過，和 Dubbo 進行了高度集成的，在生產中得到過驗證的項目，且具有兼容性保障。這些項目不僅來自阿里巴巴自己的開源項目，也來自其它公司或社區。我們把它稱之為 Apache Dubbo EcoSystem，希望通過這個生態幫助使用者更輕鬆、更快速地搭建微服務。
嘉賓介紹
北緯，社區暱稱 beiwei30，Apache Dubbo™ PPMC，阿里巴巴高級技術專家，專注於大規模分佈式系統、RPC 框架和微服務領域。
開源社區OSC頭條號，每日推送最新優質的技術類文章，涵蓋外文翻譯，軟件更新，技術博客等優質內容。關注開源社區OSC頭條號，每日獲取最新技術資訊，點擊“
瞭解更多”閱讀原文章。↓↓↓
閱讀更多 開源社區OSC 的文章
