知識星球來自：開源中國
連結：https://www.oschina.net/question/3820517_2302528
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 框架和微服務領域。