微服務特點：

微服務（Microservices）是一種架構風格，一個大型復雜軟件應用由一個或多個微服務組成。

獨立部署

松耦合

單一職責，每個服務僅關注一件任務

微服務框架

?相關概念:

?

rpc	1、遠端過程調用，其調用協議通常包含傳輸協議和編碼協議。 2、RPC 可以把 HTTP 作為一種傳輸協議（比如 gRPC 使用 HTTP 2.0 協議傳輸），本身還會封裝一層 RPC 框架的應用層協議，不同語言之間調用需要依賴 RPC 協議
grpc	HTTP 2.0 協議傳輸
dubbo	自定義報文的 TCP 協議。編碼協議包含: 如基于文本編碼的 XML Json，也有二進制編碼的 ProtoBuf Binpack 等
rest	REST 風格直接把 HTTP 作為應用協議（直接和服務打交道），不同語言之間調用比較方便

?

為什么 Dubbo 比 Spring Cloud 性能要高一些？

Dubbo 采用單一長連接和 NIO 異步通訊（保持連接/輪詢處理），使用自定義報文的 TCP 協議，并且序列化使用定制 Hessian2 框架，適合于小數據量大并發的服務調用，以及服務消費者機器數遠大于服務提供者機器數的情況，但不適用于傳輸大數據的服務調用

Spring Cloud 直接使用 HTTP 協議（但也不是強綁定，也可以使用 RPC 庫，或者采用 HTTP 2.0 + 長鏈接方式（Fegin 可以靈活設置））。

Dubbo

分布式服務框架，致力于提供高性能和透明化的?RPC 遠程服務調用方案，以及?SOA 服務治理方案。簡單的說，Dubbo 就是個服務框架，說白了就是個遠程服務調用的分布式框架.

dubbo	Provider: 暴露服務的服務提供方。
	Consumer: 調用遠程服務的服務消費方。
	Registry: 服務注冊與發現的注冊中心。
	Monitor: 統計服務的調用次調和調用時間的監控中心。
	Container: 服務運行容器。

SpringCloud

基于 Spring Boot，為微服務體系開發中的架構問題，提供了一整套的解決方案——服務注冊與發現，服務消費，服務保護與熔斷，網關，分布式調用追蹤，分布式配置管理等。Spring Boot 是 Spring 的一套快速配置腳手架，使用默認大于配置的理念，用于快速開發單個微服務。

核心功能：

• 分布式/版本化配置
• 服務注冊和發現
• 路由
• 服務和服務之間的調用
• 負載均衡
• 斷路器
• 分布式消息傳遞

流程：

• 請求統一通過 API 網關（Zuul）來訪問內部服務。
• 網關接收到請求后，從注冊中心（Eureka）獲取可用服務。
• 由 Ribbon 進行均衡負載后，分發到后端具體實例。
• 微服務之間通過 Feign 進行通信處理業務。
• Hystrix 負責處理服務超時熔斷。
• Turbine 監控服務間的調用和熔斷相關指標。

對比

dubbo	優點： Dubbo 支持?RPC 調用，服務之間的調用性能會很好。 支持多種序列化協議，如 Hessian、HTTP、WebService。 Dobbo Admin后臺管理功能強大，提供了路由規則、動態配置、訪問控制、權重調節、均衡負載等功能。 在國內影響力比較大，中文社區文檔較為全面。 阿里最近重啟維護
	缺點： 1、Registry 嚴重依賴第三方組件（zookeeper 或者 redis），當這些組件出現問題時，服務調用很快就會中斷 2、只支持 RPC 調用。使得服務提供方（抽象接口）與調用方在代碼上產生了強依賴 3、Dubbo?只是實現了服務治理，其他微服務框架并未包含，需要結合第三方框架實現（比如分布式配置用淘寶的 Diamond、服務跟蹤用京東的 Hydra，但使用相對麻煩些），開發成本較高，且風險較大。
springcloud	優點 1、有強大的 Spring 社區、Netflix 等公司支持 2、標準化的將微服務的成熟產品和框架結合一起，Spring Cloud 提供整套的微服務解決方案，開發成本較低，且風險較小。 3、基于 Spring Boot，具有簡單配置、快速開發、輕松部署、方便測試的特點 4、支持 REST 服務調用，相比于 RPC，更加輕量化和靈活（服務之間只依賴一紙契約，不存在代碼級別的強依賴），有利于跨語言服務的實現，以及服務的發布部署。另外，結合 Swagger，也使得服務的文檔一體化 5、提供了 Docker 及 Kubernetes 微服務編排支持 6、企業應用非常多，經受了大公司的應用考驗（比如 Netfilx 公司），以及強大的開源社區支持
	缺點： 1、REST 服務調用性能會比 RPC 低一些（但也不是強綁定） 2、Spring Cloud 整合了大量組件，相關文檔比較復雜，需要針對性的進行閱讀 3、支持 REST 服務調用，可能因為接口定義過輕，導致定義文檔與實際實現不一致導致服務集成時的問題（可以使用統一文檔和版本管理解決，比如 Swagger）。

?

性能比較：

選型出發點

微服務選型要評估以下幾點：

內部是否存在異構系統集成的問題；

備選框架功能特性是否滿足需求；

HTTP 協議的通信對于應用的負載量會否真正成為瓶頸點（Spring Cloud 也并不是和 HTTP + JSON 強制綁定的，如有必要 Thrift、ProtoBuf 等高效的 RPC、序列化協議同樣可以作為替代方案）；

社區活躍度、團隊技術儲備等。作為已經沒有團隊持續維護的開源項目，選擇 Dubbo 框架內部就必須要組建一個維護團隊，先不論你要準備要集成多少功能做多少改造，作為一個支撐所有工程正常運轉的基礎組件，問題的及時響應與解答、重大缺陷的及時修復能力就已足夠重要。

選型建議

1、使用 Dubbo 構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條內存質量不行就點不亮了，總是讓人不怎么放心，但是如果你是一名高手，那這些都不是問題；而 Spring Cloud 就像品牌機，在 Spring Source 的整合下，做了大量的兼容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝組件外的東西，就需要對其基礎有足夠的了解。

2、Spring Cloud 可以說是一個更完備的微服務解決方案，它從功能性上是 Dubbo 的一個超集對于一些中小型企業 Spring Cloud 可能是一個更好的選擇

3、Dubbo 和 Spring Cloud 的主要不同體現在兩個方面：服務調用方式不同和專注點不同（生態不同）。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的Java 微服务框架对比：Dubbo 和 Spring Cloud的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。