Dubbo與Spring Cloud的比較


區別:

-----

來源(背景):

Dubbo,是阿里巴巴服務化治理的核心框架,並被廣泛應用於阿里巴巴集團的各成員站點。

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

 

傳輸:

Dubbo由於是二進制的傳輸,占用帶寬會更少;

Spring Cloud是http協議傳輸,帶寬會比較多,同時使用http協議一般會使用JSON報文,消耗會更大。但是在國內95%的公司內,網絡消耗不是什么太大問題,如果真的成了問題,通過壓縮、二進制、高速緩存、分段降級等方法,很容易解。

 

開發難度:

Dubbo的開發難度較大,原因是dubbo的jar包依賴問題很多大型工程無法解決;

Spring Cloud的接口協議約定比較自由且松散,需要有強有力的行政措施來限制接口無序升級

 

后續改進:

Dubbo通過dubbofilter,很多東西沒有,需要自己繼承,如監控,如日志,如限流,如追蹤

Spring Cloud自己帶了很多監控、限流措施,但是功能可能和歐美習慣相同,國內需要進行適當改造,但更簡單,就是ServletFilter而已,但是總歸比dubbo多一些東西是好的;

 

注冊中心:

Dubbo的注冊中心可以選擇zk,redis等多種;

Spring Cloud:的注冊中心只能用eureka或者自研;

 

配置中心:

dubbo:如果我們使用配置中心、分布式跟蹤這些內容都需要自己去集成,無形中增加了使用難度。

Spring Cloud:提供了微服務的一整套解決方案:服務發現注冊、配置中心、消息總線、負載均衡、斷路器、數據監控等

 

核心部件的比較:

Dubbo:

Provider:暴露服務的提供方,可以通過 jar 或者容器的方式啟動服務。

Consumer:調用遠程服務的服務消費方。

Registry:服務注冊中心和發現中心。

Monitor:統計服務和調用次數,調用時間監控中心。(Dubbo 的控制台頁面中可以顯示,目前只有一個簡單版本。)

Container:服務運行的容器。

Spring Cloud:

Service Provider: 暴露服務的提供方。

Service Consumer:調用遠程服務的服務消費方。

EureKa Server: 服務注冊中心和服務發現中心。

 

架構的完整度:

Dubbo只是實現了服務治理;

Spring Cloud下面有17個子項目(可能還會新增)分別覆蓋了微服務架構下的方方面面,服務治理只是其中的一個方面;

一定程度來說,Dubbo只是Spring Cloud Netflix中的一個子集。

 

服務依賴方式:

Dubbo:服務提供方與消費方通過接口的方式依賴,服務調用設計如下:

Interface 層:服務接口層,定義了服務對外提供的所有接口。

Molel 層:服務的 DTO 對象層。

Business層:業務實現層,實現 Interface 接口並且和 DB 交互。

因此需要為每個微服務定義各自的 Interface 接口,並通過持續集成發布到私有倉庫中。調用方應用對微服務提供的抽象接口存在強依賴關系,開發、測試、集成環境都需要嚴格的管理版本依賴。

 

通過 maven 的 install & deploy 命令把 Interface 和 Model 層發布到倉庫中,服務調用方只需要依賴 Interface 和 Model 層即可。在開發調試階段只發布 Snapshot 版本,等到服務調試完成再發布;Release 版本,通過版本號來區分每次迭代的版本。通過 xml 配置方式即可接入 Dubbo,對程序無入侵。

總之:服務提供方與消費方通過接口的方式依賴,Dubbo 服務依賴略重,需要有完善的版本管理機制,但是程序入侵少。

 

Spring Cloud:

服務提供方和服務消費方通過 Json 方式交互,因此只需要定義好相關 Json 字段即可,消費方和提供方無接口依賴。通過注解方式來實現服務配置,對於程序有一定入侵。

通過 Json 交互,省略了版本管理的問題,但是具體字段含義需要統一管理,自身 Rest API 方式交互,為跨平台調用奠定了基礎。

 

 

總體:

Dubbo:使用Dubbo構建的微服務架構就像組裝電腦,各環節我們的選擇自由度很高,但是最終結果很有可能因為一條內存質量不行就點不亮了,總是讓人不怎么放心,但是如果你是一名高手,那這些都不是問題;

Spring Cloud就像品牌機,在Spring Source的整合下,做了大量的兼容性測試,保證了機器擁有更高的穩定性,但是如果要在使用非原裝組件外的東西,就需要對其基礎有足夠的了解。

 

-------------------------------------

優缺點(綜上得到):

-------------------------------------

Dubbo

優點:

1.支持各種通信協議,而且消費方和服務方使用長鏈接方式交互,通信速度上略勝 ;

2.采用rpc方式,性能上比Spring Cloud的rpc更好;

3.dubbo的網絡消耗小於springcloud

缺點:

1.如果我們使用配置中心、分布式跟蹤這些內容都需要自己去集成;

2.開發難度較大,原因是dubbo的jar包依賴問題很多大型工程無法解決;

3.

 

Spring Cloud:

優點:

1、產出於Spring大家族,Spring在企業級開發框架中來頭很大,可以保證后續的更新、完善。

2、spring cloud社區活躍,教程豐富,遇到問題很容易找到解決方案;

3、spring cloud功能比dubbo更加完善;

5、spring cloud采用rest訪問方式,rest的技術無關性使用效果更棒;

6、spring cloud輕輕松松幾行代碼就完成了熔斷、均衡負責、服務中心的各種平台功能;

7、從公司招聘工程師方面,spring cloud更有優勢,因為其技術更新更炫;

8、提供了微服務的一整套解決方案:服務發現注冊、配置中心、消息總線、負載均衡、斷路器、數據監控等;作為一個微服務治理的大家伙,考慮的很全面,幾乎服務治理的方方面面都考慮到了,方便開發開箱即用;

 

缺點:

1.如果對於系統的響應時間有嚴格要求,長鏈接更合適。

2.接口協議約定比較自由且松散,需要有強有力的行政措施來限制接口無序升級

 

參考:https://blog.csdn.net/ChauncyNong/article/details/80961630

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM