spring cloud 1：Spring Cloud和dubbo對比

最近一段時間不論互聯網仍是傳統行業，凡是涉及信息技術範疇的圈子幾乎都在討論 微服務架構 。近期也看到各大技術社區開始組織一些沙龍和論壇來分享Spring Cloud的相關實施經驗，這對於最近正在整理Spring Cloud相關套件內容與實例應用的我而言，仍是有很多激勵的。

目前，Spring Cloud在國內的知名度並不高，在前陣子的求職過程當中，與一些互聯網公司的架構師、技術VP或者CTO在交流時，有些甚至還不知道該項目的存在。可能這也與國內阿里巴巴開源服務治理框架Dubbo有必定的關係，除了Dubbo自己較爲完善的中文文檔以外，很多科技公司的架構師均出自阿里系，因此就目前狀況看，短時間國內仍是Dubbo的天下。

那麼第一次實施微服務架構時，咱們應該選擇哪一個基礎框架更好呢？

如下內容均爲做者我的觀點，知識面有限，若有不對，純屬正常，不喜勿噴。

Round 1：背景

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略勝一籌。不過，英雄不問出處，在背景這一點上，不能做爲選擇框架的主要因素，當您束手無策的時候，能夠做爲參考依據。

Round 2：社區活躍度

咱們選擇一個開源框架，社區的活躍度是咱們極爲關注的一個要點。社區越活躍，解決問題的速度越快，框架也會愈來愈完善，否則當咱們碰到問題，就不得不本身解決。而對於團隊來講，也就意味着咱們不得不本身去維護框架的源碼，這對於團隊來講也將會是一個很大的負擔。

 

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

Round 3：架構完整度

或許不少人會說Spring Cloud和Dubbo的對比有點不公平，Dubbo只是實現了服務治理，而Spring Cloud下面有17個子項目（可能還會新增）分別覆蓋了微服務架構下的方方面面，服務治理只是其中的一個方面，必定程度來講，Dubbo只是Spring Cloud Netflix中的一個子集。可是在選擇框架上，方案完整度偏偏是一個須要重點關注的內容。

根據Martin Fowler對 微服務架構 的描述中，雖然該架構相較於單體架構有模塊化解耦、可獨立部署、技術多樣性等諸多優勢，可是因爲分佈式環境下解耦，也帶出了很多測試與運維複雜度。

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

	Dubbo	Spring Cloud
服務註冊中心	Zookeeper	Spring Cloud Netflix Eureka
服務調用方式	RPC	REST API
服務網關	無	Spring Cloud Netflix Zuul
斷路器	不完善	Spring Cloud Netflix Hystrix
分佈式配置	無	Spring Cloud Config
服務跟蹤	無	Spring Cloud Sleuth
消息總線	無	Spring Cloud Bus
數據流	無	Spring Cloud Stream
批量任務	無	Spring Cloud Task
……	……	……

以上列舉了一些核心部件，大體能夠理解爲何以前說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，相對來講每一個環節都已經有了對應的組件支持，可能有些也不必定能知足你全部的需求，可是其活躍的社區與高速的迭代進度也會是你能夠依靠的強大後盾。

Round 4：文檔質量

Dubbo的 文檔 能夠說在國內開源框架中算是一流的，很是全，而且講解的也很是深刻，因爲版本已經穩定再也不更新，因此也不太會出現不一致的狀況，另外提供了中文與英文兩種版本，對於國內開發者來講，閱讀起來更加容易上手，這也是dubbo在國內更火一些的緣由吧。

Spring Cloud因爲整合了大量組件，文檔在體量上天然要比dubbo多不少，文檔內容上還算簡潔清楚，可是更多的是偏向整合，更深刻的使用方法仍是須要查看其整合組件的詳細文檔。另外因爲Spring Cloud基於Spring Boot，不少例子相較於傳統Spring應用要簡單不少（由於自動化配置，不少內容都成了約定的默認配置），這對於剛接觸的開發者可能會有些不適應，比較建議瞭解和學習Spring Boot以後再使用Spring Cloud，否則可能會出現不少只知其一;不知其二的狀況。

小結：雖然Spring Cloud的文檔量大，可是若是使用Dubbo去整合其餘第三方組件，實際也是要去閱讀大量第三方組件文檔的，因此在文檔量上，我以爲區別不大。對於文檔質量，因爲Spring Cloud的迭代很快，不免會出現不一致的狀況，因此在質量上我認爲Dubbo更好一些。而對於文檔語言上，Dubbo天然對國內開發團隊來講更有優點。

總結

經過上面再幾個環節上的分析，相信你們對Dubbo和Spring Cloud有了一個初步的瞭解。就我我的對這兩個框架的使用經驗和理解，打個不恰當的比喻：使用Dubbo構建的微服務架構就像組裝電腦，各環節咱們的選擇自由度很高，可是最終結果頗有可能由於一條內存質量不行就點不亮了，老是讓人不怎麼放心，可是若是你是一名高手，那這些都不是問題；而Spring Cloud就像品牌機，在Spring Source的整合下，作了大量的兼容性測試，保證了機器擁有更高的穩定性，可是若是要在使用非原裝組件外的東西，就須要對其基礎有足夠的瞭解。

從目前Spring Cloud的被關注度和活躍度上來看，頗有可能未來會成爲微服務架構的標準框架。因此，Spring Cloud的系列文章，我會繼續寫下去。也歡迎各位朋友一塊兒交流，共同進步。

 

 

轉至：http://blog.csdn.net/shuijieshuijie/article/details/53133082