從整體架構上來看
二者模式接近，都需要服務提供方，注冊中心，服務消費方。差異不大。詳見下方：
Dubbo
Provider： 暴露服務的提供方，可以通過jar或者容器的方式啟動服務
Consumer：調用遠程服務的服務消費方。
Registry： 服務注冊中心和發現中心。
Monitor： 統計服務和調用次數，調用時間監控中心。（dubbo的控制台頁面中可以顯示，目前只有一個簡單版本）
Container：服務運行的容器。
Spring Cloud
Service Provider： 暴露服務的提供方。
Service Consumer：調用遠程服務的服務消費方。
EureKa Server： 服務注冊中心和服務發現中心。
從核心要素來看
Spring Cloud 更勝一籌，在開發過程中只要整合Spring Cloud的子項目就可以順利的完成各種組件的融合，而Dubbo缺需要通過實現各種Filter來做定制，開發成本以及技術難度略高。
Dubbo只是實現了服務治理，而Spring Cloud子項目分別覆蓋了微服務架構下的眾多部件，而服務治理只是其中的一個方面。Dubbo提供了各種Filter，對於上述中“無”的要素，可以通過擴展Filter來完善。
例如
1．分布式配置：可以使用淘寶的diamond、百度的disconf來實現分布式配置管理
2．服務跟蹤：可以使用京東開源的Hydra，或者擴展Filter用Zippin來做服務跟蹤
3．批量任務：可以使用當當開源的Elastic-Job、tbschedule
從協議上看
Dubbo缺省協議采用單一長連接和NIO異步通訊，適合於小數據量大並發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的情況
Spring Cloud 使用HTTP協議的REST API
dubbo支持各種通信協議，而且消費方和服務方使用長鏈接方式交互，通信速度上略勝Spring Cloud，如果對於系統的響應時間有嚴格要求，長鏈接更合適。
從服務依賴方式看
Dubbo服務依賴略重，需要有完善的版本管理機制，但是程序入侵少。而Spring Cloud通過Json交互，省略了版本管理的問題，但是具體字段含義需要統一管理，自身Rest API方式交互，為跨平台調用奠定了基礎。
從組件運行流程看
Dubbo
每個組件都是需要部署在單獨的服務器上，gateway用來接受前端請求、聚合服務，並批量調用后台原子服務。每個service層和單獨的DB交互。
Spring Cloud
所有請求都統一通過 API 網關（Zuul）來訪問內部服務。網關接收到請求后，從注冊中心（Eureka）獲取可用服務。由 Ribbon 進行均衡負載后，分發到后端的具體實例。微服務之間通過 Feign 進行通信處理業務。
業務部署方式相同，都需要前置一個網關來隔絕外部直接調用原子服務的風險。Dubbo需要自己開發一套API 網關，而Spring Cloud則可以通過Zuul配置即可完成網關定制。使用方式上Spring Cloud略勝一籌。