javascript
Spring Cloud与Duddo比较(非原创）
文章大綱
一、Spring Cloud與Duddo背景介紹
二、Spring Cloud與Duddo比較
三、參考文章
一、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或者自研。
二、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需要自己組裝；整機的性能有保證，組裝的機子更自由。
三、參考文章
轉載于:https://www.cnblogs.com/WUXIAOCHANG/p/10913087.html
總結
以上是生活随笔為你收集整理的Spring Cloud与Duddo比较(非原创）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Angular中的routerLink
- 下一篇： 二叉树前中后、层次遍历