從總體架構上來看
兩者模式接近，都須要服務提供方，註冊中心，服務消費方。差別不大。詳見下方：前端
Dubbo
Provider： 暴露服務的提供方，能夠經過jar或者容器的方式啓動服務後端
Consumer：調用遠程服務的服務消費方。服務器
Registry： 服務註冊中心和發現中心。架構
Monitor： 統計服務和調用次數，調用時間監控中心。（dubbo的控制檯頁面中能夠顯示，目前只有一個簡單版本）併發
Container：服務運行的容器。異步
Spring Cloud
Service Provider： 暴露服務的提供方。分佈式
Service Consumer：調用遠程服務的服務消費方。ide
EureKa Server： 服務註冊中心和服務發現中心。微服務
從核心要素來看
Spring Cloud 更勝一籌，在開發過程當中只要整合Spring Cloud的子項目就能夠順利的完成各類組件的融合，而Dubbo缺須要經過實現各類Filter來作定製，開發成本以及技術難度略高。spa
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略勝一籌。