Spring Cloud與Duddo比較(非原創）

文章大綱

1、Spring Cloud與Duddo背景介紹
2、Spring Cloud與Duddo比較
3、參考文章

 

1、Spring Cloud與Duddo背景介紹

  國內技術人員喜歡拿 Dubbo 和 Spring Cloud 進行對比，是由於二者都是服務治理很是優秀的開源框架。但它們二者的出發點是不同的，Dubbo 關注於服務治理這塊而且之後也會繼續往這個方向去發展，Spring Cloud 關注的是微服務的全套解決方案，服務治理也只是微服務生態的一部分而已。所以能夠大膽的判定，Dubbo 將來會在服務治理方面更爲出色，而 Spring Cloud 在微服務治理上面無人能敵。

  隨着Dubbo成爲Apache孵化項目，並且Alibaba從新啓動維護Dubbo，Spring Cloud整合Dubbo是必然的，目前已經在Github上。

  同時阿里巴巴已經推出了Spring Cloud Alibaba項目由兩部分組成：阿里巴巴開源組件和阿里雲產品組件，旨在爲Java開發人員在使用阿里巴巴產品的同時，經過利用 Spring 框架的設計模式和抽象能力，注入Spring Boot和Spring Cloud的優點。

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

  dubbo因爲是二進制的傳輸，佔用帶寬會更少，springCloud是http協議傳輸，帶寬會比較多，同時使用http協議通常會使用JSON報文，消耗會更大。

  dubbo的開發難度較大，緣由是dubbo的jar包依賴問題不少大型工程沒法解決，springcloud的接口協議約定比較自由且鬆散，須要有強有力的行政措施來限制接口無序升級。

  dubbo的註冊中心能夠選擇zk,redis等多種，springcloud的註冊中心只能用eureka或者自研。

2、Spring Cloud與Duddo比較

1. 公司的背景

  Dubbo，是阿里巴巴服務化治理的核心框架，並被普遍應用於中國各互聯網公司；Spring Cloud是大名鼎鼎的Spring家族的產品。阿里巴巴是一個商業公司，雖然也開源了不少的頂級的項目，但從總體戰略上來說，仍然是服務於自身的業務爲主。Spring專一於企業級開源框架的研發，不管是在中國仍是在世界上使用都很是普遍，開發出通用、開源、穩健的開源框架就是他們的主業。

2. 系統結構簡易程序

  springcloud的系統結構更簡單、「註冊+springmvc=springcloud」，而dubbo各類複雜的Url，protocol，register，invocation，dubbofilter，dubboSPI，dubbo序列化..........炫技的成分更多一些

3. 開發難易度

  Duddo的神坑是jar包依賴，開發階段難度極大。springcloud比較自由，但帶來的問題是沒法「強力約束接口規範」。
  從後續改進：dubbo的改進是經過dubbofilter，不少東西沒有，須要本身繼承，如監控，如日誌，如限流，如追蹤。springcloud本身帶了不少監控、限流措施，可是功能可能和歐美習慣相同，國內須要進行適當改造，但更簡單，就是ServletFilter而已，可是總歸比dubbo多一些東西是好的

4. 配套措施

  springcloud一直宣稱本身是「一套全方面的解決方案」。。。。。。我起初信了，後來發現上當了，實話說：有，可是不是很健全，100分打50的樣子，不少你還須要改造。而DUBBO相反，一直宣稱本身是「一套全方面的服務化方案」。。。。。。純服務化頂個鳥用，任何系統都是相輔相成配套的，一個完整的系統，要有前臺、中臺、後臺、前臺包括前端和交互，中臺包括交易、任務、數據，後臺包括財務、帳戶、管理...........單純的服務化解決不了「任何問題」，惟有體系才能解決。在這個層面，springcloud是個往「體系」方向發展的方案，而dubbo僅是個工具而已，二者相比，就比如始祖鳥與草履蟲的區別。

5. 技術實力層面

  對比雙方的源碼，不得不說dubbo做者的技術能力要高於springCloud，而springBoot的做者技術能力要高於dubbo。即：springboot>dubbo>springcloud。我喜歡springboot這種大道至簡的風格，keep it simple and stupid。而dubbo好嘛......你先看看dubboSPI，再看看Protocol$Adpative裏面那一羣繞來繞去的瞎幾把繞的玩意兒，你會迅速判斷出：這羣屌絲在炫技。儘管dubbo從上之下分爲十層四五十個組件，第一感官上是哇塞好全面好偉大的樣子，但深刻以後你會以爲，這技術是很炫，設計的確實很全面，可是用不到，例如：請各位大神給我解釋一下，在zookeeper地址中，使用逗號分隔和分號分隔地址的區別。。。。。用途不大，可是代碼裏爲了這個就走向了「徹底不一樣」的一條分支。用俗語評價，就是「臃腫且無用代碼過多，在文檔裏還非得爲了這個說出123456來」。說完dubbo再說springCloud........它沒有技術含量，徹底沒有，就是一堆簡單組件拼裝在一塊兒，如configserver、eurekaserver、robin、feignClient、htstrix等，每一個都特別簡單，沒什麼技術含量，但我喜歡這種的，就喜歡這種大道至簡的簡單。

6. 社區活躍度

  Dubbo雖然也是一個很是優秀的服務治理框架，而且在服務治理、灰度發佈、流量分發這方面作的比Spring Cloud還好，除過當當網在基礎上增長了rest支持外，已有兩年多的時間幾乎都沒有任何更新了。在使用過程當中出現問題，提交到github的Issue也少有回覆。
  相反Spring Cloud自從發展到如今，仍然在不斷的高速發展，從github上提交代碼的頻度和發佈版本的時間間隔就能夠看出，如今Spring Cloud即將發佈2.0版本，到了後期會更加完善和穩定。

7. 架構完整度

  Dubbo框架只是專一於服務之間的治理，若是咱們須要使用配置中心、分佈式跟蹤這些內容都須要本身去集成，這樣無形中使用dubbo的難度就會增長。Spring Cloud幾乎考慮了服務治理的方方面面，更有Spring Boot這個大將的支持，開發起來很是的便利和簡單。

8. 性能

  Dubbo的網絡消耗小於springcloud，可是在國內95%的公司內，網絡消耗不是什麼太大問題，若是真的成了問題，經過壓縮、二進制、高速緩存、分段降級等方法，很容易解

9. 文檔質量

  Dubbo的文檔能夠說在國內開源框架中算是一流的，很是全，而且講解的也很是深刻，因爲版本已經穩定再也不更新，因此也不太會出現不一致的狀況，另外提供了中文與英文兩種版本，對於國內開發者來講，閱讀起來更加容易上手，這也是dubbo在國內更火一些的緣由吧。
  Spring Cloud因爲整合了大量組件，文檔在體量上天然要比dubbo多不少，文檔內容上還算簡潔清楚，可是更多的是偏向整合，更深刻的使用方法仍是須要查看其整合組件的詳細文檔。另外因爲Spring Cloud基於Spring Boot，不少例子相較於傳統Spring應用要簡單不少（由於自動化配置，不少內容都成了約定的默認配置），這對於剛接觸的開發者可能會有些不適應，比較建議瞭解和學習Spring Boot以後再使用Spring Cloud，否則可能會出現不少只知其一;不知其二的狀況。
  雖然Spring Cloud的文檔量大，可是若是使用Dubbo去整合其餘第三方組件，實際也是要去閱讀大量第三方組件文檔的，因此在文檔量上，我以爲區別不大。對於文檔質量，因爲Spring Cloud的迭代很快，不免會出現不一致的狀況，因此在質量上我認爲Dubbo更好一些。而對於文檔語言上，Dubbo天然對國內開發團隊來講更有優點。

10. 總結

   spring cloud整機，dubbo須要本身組裝；整機的性能有保證，組裝的機子更自由。

3、參考文章

1. https://blog.csdn.net/u010664947/article/details/80007767
2. http://www.51ui.cn/taiw/2919129/
3. https://blog.csdn.net/chendeyou5/article/details/79449423