一、基本介紹
dubbo
Dubbo 是一個分布式服務框架，致力於提供高性能和透明化的 RPC 遠程服務調用方案，以及 SOA 服務治理方案。簡單的說，Dubbo 就是個服務框架，說白了就是個遠程服務調用的分布式框架
優點：
- Dubbo 支持 RPC 調用，服務之間的調用性能會很好。
- 支持多種序列化協議，如 Hessian、HTTP、WebService。
- Dobbo Admin后台管理功能強大，提供了路由規則、動態配置、訪問控制、權重調節、均衡負載等功能。
- 在國內影響力比較大，中文社區文檔較為全面。
- 阿里最近重啟維護。
缺點：
- Registry 嚴重依賴第三方組件（zookeeper 或者 redis），當這些組件出現問題時，服務調用很快就會中斷。
- Dubbo 只支持 RPC 調用。使得服務提供方（抽象接口）與調用方在代碼上產生了強依賴，服務提供者需要不斷將包含抽象接口的 jar 包打包出來供消費者使用。一旦打包出現問題，就會導致服務調用出錯，並且以后發布部署會成很大問題（太強的依賴關系）。
- 另外，以后要兼容 .NET Core 服務，Dubbo RPC 本身不支持跨語言（可以用跨語言 RPC 框架解決，比如 Thrift、gRPC（重復封裝了），或者自己再包一層 REST 服務，提供跨平台的服務調用實現，但相對麻煩很多）
- Dubbo 只是實現了服務治理，其他微服務框架並未包含，如果需要使用，需要結合第三方框架實現（比如分布式配置用淘寶的 Diamond、服務跟蹤用京東的 Hydra，但使用相對麻煩些），開發成本較高，且風險較大。
- 社區更新不及時（雖然最近在瘋狂更新），但也難免阿里以后又不更新了，就尷尬了。
- 主要是國內公司使用，但阿里內部使用 HSF，相對於 Spring Cloud，企業應用會差一些。
spring cloud
Spring Cloud 基於 Spring Boot，為微服務體系開發中的架構問題，提供了一整套的解決方案——服務注冊與發現，服務消費，服務保護與熔斷，網關，分布式調用追蹤，分布式配置管理等。
優點：
- 有強大的 Spring 社區、Netflix 等公司支持，並且開源社區貢獻非常活躍。
- 標准化的將微服務的成熟產品和框架結合一起，Spring Cloud 提供整套的微服務解決方案，開發成本較低，且風險較小。
- 基於 Spring Boot，具有簡單配置、快速開發、輕松部署、方便測試的特點。
- 支持 REST 服務調用，相比於 RPC，更加輕量化和靈活（服務之間只依賴一紙契約，不存在代碼級別的強依賴），有利於跨語言服務的實現，以及服務的發布部署。另外，結合 Swagger，也使得服務的文檔一體化。
- 提供了 Docker 及 Kubernetes 微服務編排支持。
- 國內外企業應用非常多，經受了大公司的應用考驗（比如 Netfilx 公司），以及強大的開源社區支持。
缺點：
- 支持 REST 服務調用，可能因為接口定義過輕，導致定義文檔與實際實現不一致導致服務集成時的問題（可以使用統一文檔和版本管理解決，比如 Swagger）。
- 另外，REST 服務調用性能會比 RPC 低一些（但也不是強綁定）
- Spring Cloud 整合了大量組件，相關文檔比較復雜，需要針對性的進行閱讀。
補充：spring cloud目前支持的服務發現
| euerka | Consul | zookeeper | etcd | |
|---|---|---|---|---|
| 服務健康檢查 | 可配支持 | 服務狀態，內存，硬盤等 | (弱)長連接，keepalive | 連接心跳 |
| 多數據中心 | — | 支持 | — | — |
| kv 存儲服務 | — | 支持 | 支持 | 支持 |
| 一致性 | — | raft | paxos | raft |
| cap | ap | ca | cp | cp |
| 使用接口(多語言能力) | http（sidecar） | 支持 http 和 dns | 客戶端 | http/grpc |
| watch 支持 | 支持 long polling/大部分增量 | 全量/支持long polling | 支持 | 支持 long polling |
| 自身監控 | metrics | metrics | — | metrics |
| 安全 | — | acl /https | acl | https 支持（弱） |
| spring cloud 集成 | 已支持 | 已支持 | 已支持 | 已支持 |
還有Service Mesh 如果用一句話來解釋什么是 Service Mesh，可以將它比作是應用程序或者說微服務間的 TCP/IP，負責服務之間的網絡調用、限流、熔斷和監控。
對於編寫應用程序來說一般無須關心 TCP/IP 這一層（比如通過 HTTP 協議的 RESTful 應用），
同樣使用 Service Mesh 也就無須關系服務之間的那些原來是通過應用程序或者其他框架實現的事情，比如 Spring Cloud、OSS，現在只要交給 Service Mesh 就可以了。 Service Mesh有一個成熟的產品，微軟內部用了近10年的產品，現在命名為Service fabric 開源在GitHub上：https://github.com/Microsoft/service-fabric
二、主要區別
（1）服務調用方式
Q：為什么說 Dubbo 比 Spring Cloud 性能要高一些？
A：因為 Dubbo 采用單一長連接和 NIO 異步通訊（保持連接/輪詢處理），使用自定義報文的 TCP 協議，並且序列化使用定制 Hessian2 框架，適合於小數據量大並發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的情況，但不適用於傳輸大數據的服務調用。而 Spring Cloud 直接使用 HTTP 協議（但也不是強綁定，也可以使用 RPC 庫，或者采用 HTTP 2.0 + 長鏈接方式（Fegin 可以靈活設置））。
（2）
參考博文：
到底孰優孰劣？Dubbo和Spring Cloud微服務架構終極對決！
Java 微服務框架選型（Dubbo 和 Spring Cloud？）