談談spring cloud與dubbo的差別

歡迎通路我的個人部落格：戎碼一生

背景

Dubbo，是阿裡巴巴服務化治理的核心架構，并被廣泛應用于阿裡巴巴集團的各成員站點。阿裡巴巴近幾年對開源社群的貢獻不論在國内還是國外都是引人注目的，比如：JStorm捐贈給Apache并加入Apache基金會等，為中國網際網路人争足了面子，使得阿裡巴巴在國人眼裡已經從電商更新為一家科技公司了。

Spring Cloud，從命名我們就可以知道，它是Spring Source的産物，Spring社群的強大背書可以說是Java企業界最有影響力的組織了，除了Spring Source之外，還有Pivotal和Netfix是其強大的後盾與技術輸出。其中Netflix開源的整套微服務架構套件是Spring Cloud的核心。

小結：如果拿Dubbo與Netflix套件做對比，前者在國内影響力較大，後者在國外影響力較大，我認為在背景上可以打個平手；但是若要與Spring Cloud做對比，由于Spring Source的加入，在背書上，Spring Cloud略勝一籌。不過，英雄不問出處，在背景這一點上，不能作為選擇架構的主要因素，當您一籌莫展的時候，可以作為參考依據。

社群活躍度

我們選擇一個開源架構，社群的活躍度是我們極為關注的一個要點。社群越活躍，解決問題的速度越快，架構也會越來越完善，不然當我們碰到問題，就不得不自己解決。而對于團隊來說，也就意味着我們不得不自己去維護架構的源碼，這對于團隊來說也将會是一個很大的負擔。

下面看看這兩個項目在github上的更新時間，下面截圖自2016年7月30日：

• Dubbo ： https://github.com/dubbo

最後更新時間為：2019年8月24日

• Spring Cloud ： https://github.com/spring-cloud

最後更新時間為：四小時前

可以看到Dubbo的更新已經是一個月前，并且更新頻率很低。而Spring Cloud的更新是四小時前，仍處于高速疊代的階段。

小結：在社群活躍度上，Spring Cloud毋庸置疑的優于Dubbo，這對于沒有大量精力與财力維護這部分開源内容的團隊來說，Spring Cloud會是更優的選擇。

架構完整度

或許很多人會說Spring Cloud和Dubbo的對比有點不公平，Dubbo隻是實作了服務治理，而Spring Cloud下面有17個子項目（可能還會新增）分别覆寫了微服務架構下的方方面面，服務治理隻是其中的一個方面，一定程度來說，Dubbo隻是Spring Cloud Netflix中的一個子集。但是在選擇架構上，方案完整度恰恰是一個需要重點關注的内容。

根據Martin Fowler對 微服務架構 的描述中，雖然該架構相較于單體架構有子產品化解耦、可獨立部署、技術多樣性等諸多優點，但是由于分布式環境下解耦，也帶出了不少測試與運維複雜度。

根據微服務架構在各方面的要素，看看Spring Cloud和Dubbo都提供了哪些支援。

以上列舉了一些核心部件，大緻可以了解為什麼之前說Dubbo隻是類似Netflix的一個子集了吧。當然這裡需要申明一點，Dubbo對于上表中總結為“無”的元件不代表不能實作，而隻是Dubbo架構自身不提供，需要另外整合以實作對應的功能，比如：

• 分布式配置：可以使用淘寶的diamond、百度的disconf來實作分布式配置管理。但是Spring

  Cloud中的Config元件除了提供配置管理之外，由于其存儲可以使用git，是以它天然的實作了配置内容的版本管理，可以完美的與應用版本管理整合起來。

• 服務跟蹤：可以使用京東開源的Hydra
• 批量任務：可以使用當當開源的Elastic-Job
• ……

雖然，Dubbo自身隻是實作了服務治理的基礎，其他為保證叢集安全、可維護、可測試等特性方面都沒有很好的實作，但是幾乎大部分關鍵元件都能找到第三方開源來實作，這些元件主要來自于國内各家大型網際網路企業的開源産品。

RPC vs REST

另外，由于Dubbo是基礎架構，其實作的内容對于我們實施微服務架構是否合理，也需要我們根據自身需求去考慮是否要修改，比如Dubbo的服務調用是通過RPC實作的，但是如果仔細拜讀過Martin Fowler的 microservices 一文，其定義的服務間通信是HTTP協定的REST API。那麼這兩種有何差別呢？

先來說說，使用Dubbo的RPC來實作服務間調用的一些痛點：

• 服務提供方與調用方接口依賴方式太強：我們為每個微服務定義了各自的service抽象接口，并通過持續內建釋出到私有倉庫中，調用方應用對微服務提供的抽象接口存在強依賴關系，是以不論開發、測試、內建環境都需要嚴格的管理版本依賴，才不會出現服務方與調用方的不一緻導緻應用無法編譯成功等一系列問題，以及這也會直接影響本地開發的環境要求，往往一個依賴很多服務的上層應用，每天都要更新很多代碼并install之後才能進行後續的開發。若沒有嚴格的版本管理制度或開發一些自動化工具，這樣的依賴關系會成為開發團隊的一大噩夢。而REST接口相比RPC更為輕量化，服務提供方和調用方的依賴隻是依靠一紙契約，不存在代碼級别的強依賴，當然REST接口也有痛點，因為接口定義過輕，很容易導緻定義文檔與實際實作不一緻導緻服務內建時的問題，但是該問題很好解決，隻需要通過每個服務整合swagger，讓每個服務的代碼與文檔一體化，就能解決。是以在分布式環境下，REST方式的服務依賴要比RPC方式的依賴更為靈活。
• 服務對平台敏感，難以簡單複用：通常我們在提供對外服務時，都會以REST的方式提供出去，這樣可以實作跨平台的特點，任何一個語言的調用方都可以根據接口定義來實作。那麼在Dubbo中我們要提供REST接口時，不得不實作一層代理，用來将RPC接口轉換成REST接口進行對外釋出。若我們每個服務本身就以REST接口方式存在，當要對外提供服務時，主要在API網關中配置映射關系和權限控制就可實作服務的複用了。

相信這些痛點也是為什麼當當網在dubbox（基于Dubbo的開源擴充）中增加了對REST支援的原因之一。

小結：Dubbo實作了服務治理的基礎，但是要完成一個完備的微服務架構，還需要在各環節去擴充和完善以保證叢集的健康，以減輕開發、測試以及運維各個環節上增加出來的壓力，這樣才能讓各環節人員真正的專注于業務邏輯。而Spring Cloud依然發揚了Spring Source整合一切的作風，以标準化的姿态将一些微服務架構的成熟産品與架構揉為一體，并繼承了Spring Boot簡單配置、快速開發、輕松部署的特點，讓原本複雜的架構工作變得相對容易上手一些（如果您讀過我之前關于Spring Cloud的一些核心元件使用的文章，應該能體會這些讓人興奮而激動的特性，傳送門）。是以，如果選擇Dubbo請務必在各個環節做好整套解決方案的準備，不然很可能随着服務數量的增長，整個團隊都将疲于應付各種架構上不足引起的困難。而如果選擇Spring Cloud，相對來說每個環節都已經有了對應的元件支援，可能有些也不一定能滿足你所有的需求，但是其活躍的社群與高速的疊代進度也會是你可以依靠的強大後盾。

文檔品質

Dubbo的 文檔 可以說在國内開源架構中算是一流的，非常全，并且講解的也非常深入，由于版本已經穩定不再更新，是以也不太會出現不一緻的情況，另外提供了中文與英文兩種版本，對于國内開發者來說，閱讀起來更加容易上手，這也是dubbo在國内更火一些的原因吧。

Spring Cloud由于整合了大量元件，文檔在體量上自然要比dubbo多很多，文檔内容上還算簡潔清楚，但是更多的是偏向整合，更深入的使用方法還是需要檢視其整合元件的詳細文檔。另外由于Spring Cloud基于Spring Boot，很多例子相較于傳統Spring應用要簡單很多（因為自動化配置，很多内容都成了約定的預設配置），這對于剛接觸的開發者可能會有些不适應，比較建議了解和學習Spring Boot之後再使用Spring Cloud，不然可能會出現很多一知半解的情況。

小結：雖然Spring Cloud的文檔量大，但是如果使用Dubbo去整合其他第三方元件，實際也是要去閱讀大量第三方元件文檔的，是以在文檔量上，我覺得差別不大。對于文檔品質，由于Spring Cloud的疊代很快，難免會出現不一緻的情況，是以在品質上我認為Dubbo更好一些。而對于文檔語言上，Dubbo自然對國内開發團隊來說更有優勢。

總結

使用Dubbo建構的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條記憶體品質不行就點不亮了，總是讓人不怎麼放心，但是如果你是一名高手，那這些都不是問題；而Spring Cloud就像品牌機，在Spring Source的整合下，做了大量的相容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝元件外的東西，就需要對其基礎有足夠的了解。

從目前Spring Cloud的被關注度和活躍度上來看，很有可能将來會成為微服務架構的标準架構。

至于微服務項目開發中到底原因哪種架構，就我個人認為，技術沒有好壞，隻有适合于不适合，是以選擇适合你項目的那種架構吧！

歡迎通路我的個人部落格：戎碼一生