2016年，我在部落格中發表過一篇《微服務架構的基礎框架選擇：Spring Cloud還是Dubbo？》獲得了很大的閱讀量和轉載量。在這篇文章中，我主要對比了Spring Cloud與Dubbo所具備的能力，並闡述了個人推崇Spring Cloud的原因。但是，最近各大技術社群出現了不少類似的文章，觀點比較激進，對於Spring Cloud的褒揚遠勝於Dubbo，但是這些評價很多都忽略了Spring Cloud與Dubbo在設計視角上的不同。其實在前文中我也說明了Dubbo與Spring Cloud的對比本身就不公平，因為兩者產出的目標格局是不一樣的。所以，就目前階段來說，大家對於框架的選擇上，還是要綜合考慮自身團隊與遺留業務系統的特點來確定更合適的技術棧，而不是盲從於“時髦”的架構體系。
昨天看到了開源中國對Dubbo社群維護者的訪談，內容非常不錯。所以這裡分享給大家。其實，在最近一年多的時間裡，結合實際的生產實踐，我也有了更多的理解與感悟。或許在後面的一段時間裡，以博文或GitChat的方式與大家分享一下我對Dubbo與Spring Cloud的“愛恨情仇”！
以下內容經授權轉載自公眾號“開源中國”
曾風靡國內的開源 RPC 服務框架 Dubbo 在重啟維護後，令許多使用者為之雀躍，但同時，也迎來了一些質疑的聲音。網際網路技術發展迅速，Dubbo 是否還能跟上時代？Dubbo 與 Spring Cloud 相比又有何優勢和差異？是否會有相關舉措保證 Dubbo 的後續更新頻率？帶著這些疑問，本期開源訪談邀請到了主導 Dubbo 重啟維護開發的劉軍，解答大家最想了解的相關問題。
【本期嘉賓】
劉軍，阿里巴巴中介軟體高階研發工程師，主導了 Dubbo 重啟維護以後的幾個發版計劃，專注於高效能 RPC 框架和微服務相關領域。曾負責網易考拉 RPC 框架的研發及指導在內部使用，參與了服務治理平臺、分散式跟蹤系統、分散式一致性框架等從無到有的設計與開發過程。
【訪談內容】
1、為什麼會在三年後重新維護 Dubbo ？
對於這個問題社群的使用者比較關心，我們在之前的一些渠道也專門做了解答，我在此引用如下：
Dubbo 自 2011 年開源以來，深受國內友商和開源愛好者的青睞，雖然一直陸續在維護，但是由於 Dubbo 使用者群體龐大，日常維護根本無法完全滿足社群的旺盛需求。隨著集團內部技術水平的迅速發展，如今不僅能夠保證集團及客戶的系統高效執行，還能抽調更多精力將技術賦能給全社會。
開源就是阿里巴巴集團在技術層面賦能的重要領域。阿里巴巴中介軟體團隊今後不僅要聆聽社群的聲音，及時修復問題，及時合併優秀的 pull request，還會力爭將 Dubbo 打造成有國際影響力的 RPC 框架。
從集團層面看，阿里為國內甚至國際開源社群貢獻了大量優秀開源專案，如大家熟知的 RocketMQ、JStorm、Fastjson、Dubbo、Weex 等。在今年的雲棲大會上，阿里集團公開宣佈了將加大技術投入、擁抱開源的發展策略。正是由於以上幾個原因，阿里巴巴中介軟體團隊決定Dubbo的下一步計劃是持續發展，並走向國際化。
2、Dubbo 在停更後還能一直受到喜愛和廣泛使用的原因是什麼？其優勢在哪？
Dubbo 自開源以後，被國內很多網際網路公司用作服務化基礎框架，經歷了在阿里內部及很多大型網際網路公司長時間生產環境實踐，已經被證明是一個高度可靠、經受得住大規模流量考驗的服務治理框架，這些成功的實踐案例，在服務化框架選型時能給予架構師足夠的信心與經驗。
另外，相比很多開源 RPC 框架，Dubbo 在服務治理功能集上可謂非常完善：不僅提供了服務註冊發現、負載均衡及路由等面向分散式叢集的基礎能力，還設計了面向開發測試階段的 mock、泛化呼叫等機制，同時也提供了服務治理、監控的視覺化平臺。
Dubbo 是一個高度可擴充套件的框架，幾乎所有核心功能都被設計為一個擴充套件點，因此從使用者的角度，即使之前在 Dubbo 的官方社群支援不足的情況下，使用者仍可以很容易的對 Dubbo 進行裁剪或擴充套件以滿足組織內部的需求。
3、網際網路技術發展迅速，雲、容器等技術的快速應用，是否已經讓 Dubbo 存在掉隊傾向？後續要如何解決？
首先從 RPC 的角度來說，RPC 是一個相對成熟的方向，Dubbo 在協議、網路通訊等層面的設計已經保證了穩定性與高效能，在這個層面 Dubbo 已經做得非常好了；而從服務治理的角度，Dubbo 已經對很多叢集場景下的服務治理特性提供了支援，同時隨著近兩年微服務架構的流行，Dubbo 在某些功能上確實需要加強：比如社群關心的熔斷功能，Dubbo 雖有容錯支援但卻還沒有融入熔斷的理念。我們計劃在接下來的幾個版本中會重點對這些缺失的功能逐步增強。
Dubbo 本身的定位只是一個 RPC 框架，基於 Dubbo 開發的應用還是要依賴周邊的平臺與生態，所以 Dubbo 自然要去積極的適配周邊生態的發展趨勢。比如你提到的以容器技術為代表的 Cloud Native 生態，這個確實是 Dubbo 要去積極跟進的方向，Dubbo 也已經在行動，比如近期的版本中支援了 Docker 容器等隔離網路環境的部署，同時對 OpenTracing、Spring Boot 的支援也在進行中，而對於底層排程平臺及周邊生態的變化，我們也在積極關注，總之 Dubbo 會積極的融入到這些健康發展的生態中去，以支援基於 Dubbo 開發的系統可以更順暢的走向雲化。
4、是否會有相關舉措保證 Dubbo 的後續更新頻率以解決使用者的擔憂？
Dubbo 自 2017 年 8 月份重啟維護以來，已經連續釋出了 5 個版本，基本維持了每月一個版本的發版節奏，而發版內容上以優先解決社群呼聲較高的需求為主。2。5。8 版本開始，之前社群累積報告的 bug 基本都已得到了修復，另外還對 netty4 的支援、annotation 的增強、java 8 的支援、docker 的支援等進行了增強。Dubbo 做出的一系列改進，讓社群再次沸騰起來。
接下來，我們將繼續投入一定的精力關注社群的使用反饋與需求，建立更完善的發版機制，做到影響版本穩定性的 bug 隨時修復，使用者關心的功能及時在 feature 版本予以支援。當前已經在我們規劃中的，近期將會提供支援的功能點包括：spring boot 的整合、RESTful、優雅部署、容錯增強、路由策略增強以及非同步化增強等。
5、Dubbo 和 HSF 都是阿里自研的 RPC 服務框架，Dubbo 後續是否會吸取 HSF 上的一些特性以滿足業務拓展需求？
當然，我們會考慮在合適的時機，陸續的將阿里在 HSF 框架以及在大規模服務化場景下的服務治理經驗透過 Dubbo 輸出到社群。HSF 本身完全相容 Dubbo ，和阿里內部的很多系統結合比較緊密並且做了一些定製化的工作，這使得 HSF 更適合於阿里內部的超大規模叢集場景，相信 HSF 在超大規模連線管理、智慧路由、服務管控等方面的經驗能幫助到 Dubbo 社群的使用者。
值得一提的是，當前維護 Dubbo 的團隊成員很多也同時參與 HSF 的維護，除此之外，還有一些來自阿里中介軟體其他團隊的同學參與進來，這樣更利於形成良性迴圈，做到真正意義上的內外統一。
7、目前 Dubbo 被拿來比較最多的就是 Spring Cloud ，您怎麼看待二者的關係，業務上是否有所衝突？
關於 Dubbo 和 Spring Cloud 間的關係，我們在開源中國年終盛典的 Dubbo 分享中也作了簡單闡述，首先要明確的一點是 Dubbo 和 Spring Cloud 並不是完全的競爭關係，兩者所解決的問題域並不一樣：Dubbo 的定位始終是一款 RPC 框架，而 Spring Cloud 的目標是微服務架構下的一站式解決方案。如果非要比較的話，我覺得 Dubbo 可以類比到 Netflix OSS 技術棧，而 Spring Cloud 集成了 Netflix OSS 作為分散式服務治理解決方案，但除此之外 Spring Cloud 還提供了包括 config、stream、security、sleuth 等等分散式問題解決方案。
當前由於 RPC 協議、註冊中心元資料不匹配等問題，在面臨微服務基礎框架選型時 Dubbo 與 Spring Cloud 是隻能二選一，這也是為什麼大家總是拿 Dubbo 和 Spring Cloud 做對比的原因之一。Dubbo 之後會積極尋求適配到 Spring Cloud 生態，比如作為 Spring Cloud 的二進位制通訊方案來發揮 Dubbo 的效能優勢，或者 Dubbo 透過模組化以及對 http 的支援適配到 Spring Cloud 。
7、現階段的服務治理框架（方案）是否存在瓶頸，如何看待其後續發展方向？
首先，我想結合時下流行的容器排程平臺簡單說一下，以 kubernetes 為例，它不僅提供了容器的部署、排程等生命週期管理能力，還抽象出了服務的概念，能實現服務地址的動態註冊發現、負載均衡、health check、動態配置等，可以說服務治理的能力在往底層平臺層面下沉，而類似 Dubbo 的服務治理框架本身可以變得更輕量。
另一個方面，跨多語言的服務治理一直是開源服務治理框架面臨的問題。有些 RPC 框架提供了完善跨語言的通訊支援，但是服務治理能力有限，如 gRPC、thrift 等；而有豐富服務治理功能的框架往往侷限於某一個特定的開發語言，如 Netflix、Dubbo 僅限定於 java 。最近興起的 Service Mesh 方案看似是未來解決跨語言問題的完美方案，它接管了所有的網路流量，因此能實現流量排程和管控相關的功能。更進一步，類似 istio、conduit 等框架又與底層排程平臺的服務註冊發現等能力進行對接，同時也對微服務周邊解決方案的適配提供了統一抽象，RPC 通訊和服務治理能力不再耦合在一起，業務應用只需要面向基礎的 RPC 通訊框架程式設計。
從 Dubbo 自身來說，未來主要會著重向 Cloud Native 、多語言增強、微服務支援等幾個方向演進，同時不斷建設生態系統、社群、以及國際影響力。
訪談原文：
https：//www。
oschina。net/question/28
96879_2272652
