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