首先，從嚴格意義上來說，Dubbo和SpringCloud的定位是不一樣的。Dubbo是一個高效能的、基於java的開源RPC框架，注意它的定位是是高效能和RPC框架。SpringCloud提供了一系列通用工具來幫助開發者在分散式系統裡快速構建一些常見模式，比如分散式配置管理、服務發現、熔斷降級、智慧路由、微代理、控制匯流排、一次性令牌、全域性鎖、分散式選主、分散式session等一些列解決方案，它的設計目標是提供一整套服務治理能力，它具有一套完整的微服務解決方案體系。
dubbo只是一個分散式的 RPC 框架，如果一定要按照分散式系統架構裡的功能來定義的話，只是解決了服務發現、服務路由、服務降級和負載均衡方面的能力，新版本里也提供了動態配置中心和服務治理相關的能力，但相比 Spring Cloud 而言，還是差了相當一部分的能力。
從功能支援上來說，dubbo 的角色定位可能更像是另外一個大名鼎鼎的框架，那就是 gRPC，而且兩者在使用的方式以及工作原理上都非常相似，都是基於序列化協議來解決分散式系統中的遠端呼叫問題，在使用上可以透過約定介面或者透過 proto 檔案生成程式碼檔案來“提升使用者的使用”。
如果你在系統設計之初就已經考慮到了後續可能會涉及到各種服務治理能力，比如分散式配置、全域性鎖、分散式session等常見需求，那麼使用 SpringCloud 將會減少你很多的工作，因為這些基本上都是"套件"，相互配合使用會非常順暢。如果你想要的只是解決分散式架構後的遠端呼叫問題，那麼 Dubbo 是一個不錯的選擇。
上文也提到，SpringCloud 提供了一整套微服務治理的功能元件，很多元件基本上都是"開箱即用"的，並且相互之間能很好的相容，舉個例子，如果要在 Spring Cloud 裡實現服務發現、負載均衡和熔斷降級，你只需要引用SpringCloud 的依賴元件即可，直接透過註解便可使用，基本上零配置；而 dubbo 框架，除了上述提到的能力支援之外，如果想要使用熔斷降級，那你可能需要額外引用 hystrix 或者 resilience4j 來實現；溫馨提示，hystrix 官方目前也已經宣佈不再更新，並且推薦使用 resilience4j 。
SpringCloud 裡並沒有限制服務之間的通訊協議，但是主流的一些客戶端比如 restTemple、feign 等都是直接支援使用 Ribbon 來做服務註冊發現和智慧路由的，其底層通訊的協議都是HTTP；而dubbo框架預設是基於NIO非同步傳輸使用 TCP 長連線並採用 Hessian 二進位制序列化方式通訊的；
這會涉及後續系統在擴充套件上的相容性問題，比如需要呼叫一個三方系統或者是被第三方系統呼叫，相比而言 HTTP 協議可能更加通用。
dubbo 在模型設計上將一個介面定義為一個服務，而 SpringCloud 裡則是將一個應用定義為一個服務，這兩者在模型上是存在很大差異的，你也許會奇怪，這個對使用會有影響嗎？從現有使用方面來說是沒有什麼影響的，但是你如果有關注 Service Mesh 最新微服務技術的話，目前對 Dubbo 協議這塊可能支援暫時還不完善，其中很大一部分原因就是因為在服務模型上與 K8S 的服務模型有差異；
如果分散式系統中比較關注遠端呼叫的效能，那 Dubbo 可能是一個較好的選擇，基於 NIO 和 TCP 長連線的通訊傳輸方式，在效能上相比 HTTP 協議是有絕對優勢的；當然基於 SpringCloud 你也可以使用 gRPC 協議來解決效能問題，那就是另外一個問題了。
首先，從嚴格意義上來說，Dubbo和SpringCloud的定位是不一樣的。Dubbo是一個高效能的、基於java的開源RPC框架，注意它的定位是是高效能和RPC框架。SpringCloud提供了一系列通用工具來幫助開發者在分散式系統裡快速構建一些常見模式，比如分散式配置管理、服務發現、熔斷降級、智慧路由、微代理、控制匯流排、一次性令牌、全域性鎖、分散式選主、分散式session等一些列解決方案，它的設計目標是提供一整套服務治理能力，它具有一套完整的微服務解決方案體系。
dubbo只是一個分散式的 RPC 框架，如果一定要按照分散式系統架構裡的功能來定義的話，只是解決了服務發現、服務路由、服務降級和負載均衡方面的能力，新版本里也提供了動態配置中心和服務治理相關的能力，但相比 Spring Cloud 而言，還是差了相當一部分的能力。
從功能支援上來說，dubbo 的角色定位可能更像是另外一個大名鼎鼎的框架，那就是 gRPC，而且兩者在使用的方式以及工作原理上都非常相似，都是基於序列化協議來解決分散式系統中的遠端呼叫問題，在使用上可以透過約定介面或者透過 proto 檔案生成程式碼檔案來“提升使用者的使用”。
如果你在系統設計之初就已經考慮到了後續可能會涉及到各種服務治理能力，比如分散式配置、全域性鎖、分散式session等常見需求，那麼使用 SpringCloud 將會減少你很多的工作，因為這些基本上都是"套件"，相互配合使用會非常順暢。如果你想要的只是解決分散式架構後的遠端呼叫問題，那麼 Dubbo 是一個不錯的選擇。
能力支援方面上文也提到，SpringCloud 提供了一整套微服務治理的功能元件，很多元件基本上都是"開箱即用"的，並且相互之間能很好的相容，舉個例子，如果要在 Spring Cloud 裡實現服務發現、負載均衡和熔斷降級，你只需要引用SpringCloud 的依賴元件即可，直接透過註解便可使用，基本上零配置；而 dubbo 框架，除了上述提到的能力支援之外，如果想要使用熔斷降級，那你可能需要額外引用 hystrix 或者 resilience4j 來實現；溫馨提示，hystrix 官方目前也已經宣佈不再更新，並且推薦使用 resilience4j 。
協議相容方面SpringCloud 裡並沒有限制服務之間的通訊協議，但是主流的一些客戶端比如 restTemple、feign 等都是直接支援使用 Ribbon 來做服務註冊發現和智慧路由的，其底層通訊的協議都是HTTP；而dubbo框架預設是基於NIO非同步傳輸使用 TCP 長連線並採用 Hessian 二進位制序列化方式通訊的；
這會涉及後續系統在擴充套件上的相容性問題，比如需要呼叫一個三方系統或者是被第三方系統呼叫，相比而言 HTTP 協議可能更加通用。
模型定義方面dubbo 在模型設計上將一個介面定義為一個服務，而 SpringCloud 裡則是將一個應用定義為一個服務，這兩者在模型上是存在很大差異的，你也許會奇怪，這個對使用會有影響嗎？從現有使用方面來說是沒有什麼影響的，但是你如果有關注 Service Mesh 最新微服務技術的話，目前對 Dubbo 協議這塊可能支援暫時還不完善，其中很大一部分原因就是因為在服務模型上與 K8S 的服務模型有差異；
呼叫效能方面如果分散式系統中比較關注遠端呼叫的效能，那 Dubbo 可能是一個較好的選擇，基於 NIO 和 TCP 長連線的通訊傳輸方式，在效能上相比 HTTP 協議是有絕對優勢的；當然基於 SpringCloud 你也可以使用 gRPC 協議來解決效能問題，那就是另外一個問題了。