SpringCloud與Dubbo區別對比

1：SpringCloud與Dubbo區別對比

（1）：活躍度

目前SpringCloud的活躍度明顯遠高於Dubbo（參考github）

（2）：主要區別

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

 

 

 

 

 

 

 

 

 

 

 

最大的區別:Spring Cloud拋棄了Dubbo 的RPC通訊，採用的是基於HTTP的REST方式。
嚴格來講，這兩種方式各有優劣。雖然在必定程度上來講，後者犧牲了服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。
並且REST相比RPC更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更爲合適。

例如：品牌機與組裝機的區別

 

使用Dubbo構建的微服務架構就像組裝電腦，各環節咱們的選擇自由度很高，可是最終結果頗有可能由於一條內存質量不行就點不亮了，老是讓人不怎麼放心，可是若是你是一名高手，那這些都不是問題；

 

而Spring Cloud就像品牌（下面全部的框架負載均衡，服務網關。。。都是本身的）機，在Spring Source的整合下，作了大量的兼容性測試，保證了機器擁有更高的穩定性，可是若是要在使用非原裝組件外的東西，就須要對其基礎有足夠的瞭解。

2：總結SpringCloud與Dubbo

Dubbo和Spring Cloud並非徹底的競爭關係，二者所解決的問題域不同：Dubbo的定位始終是一款RPC框架，而Spring Cloud的目的是微服務架構下的一站式解決方案。
非要比較的話，Dubbo能夠類比到Netflix OSS技術棧，而Spring Cloud集成了Netflix OSS做爲分佈式服務治理解決方案，但除此以外Spring Cloud還提供了包括config、stream、security、sleuth等分佈式服務解決方案。 當前因爲RPC協議、註冊中心元數據不匹配等問題，在面臨微服務基礎框架選型時Dubbo與Spring Cloud只能二選一，這也是二者總拿來作對比的緣由。
Dubbo以後會積極尋求適配到Spring Cloud生態，好比做爲SpringCloud的二進制通信方案來發揮Dubbo的性能優點，或者Dubbo經過模塊化以及對http的支持適配到Spring Cloud