?

---

人生有涯，學海無涯，學無止境，精益求精！----------- Banana.Banuit Gang(香柚幫)

---

此文章轉載于他人，記錄在個人博客，為了自己能更方便查閱和學習。

轉載于：https://www.cnblogs.com/hasagi/p/11259411.html

微服務

　　微服務（Microservices）是一種架構風格，一個大型復雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力，而無論是Dobbo或者是SpringCloud都屬于Java的微服務框架。

?

服務調用

服務調用方式是 Dubbo 和 Spring Cloud 重要不同點，了解 RPC/gRPC/HTTP/REST 相關概念，有助于對比 Dubbo 和 Spring Cloud。

1、RPC 是遠端過程調用，其調用協議通常包含傳輸協議和編碼協議。

2、HTTP 嚴格來說跟 RPC 不是一個層級的概念，HTTP 本身也可以作為 RPC 的傳輸層協議。

?

其中傳輸協議包含，例如著名的gRPC使用的?HTTP 2.0 協議，也有如?Dubbo?一類的自定義報文的 TCP 協議。而編碼協議則有基于文本編碼的，也有二進制編碼的等。

需要注意的是在跨語言調用的時候，REST 風格直接把 HTTP 作為應用協議（直接和服務打交道），不同語言之間調用比較方便。而?RPC 可以把 HTTP 作為一種傳輸協議（比如 gRPC 使用 HTTP 2.0 協議傳輸），本身還會封裝一層 RPC 框架的應用層協議，不同語言之間調用需要依賴 RPC 協議。

?

Dubbo 是什么？

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

?

Dubbo 框架

模塊注解：

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

流程詳解：

• 0 服務容器負責啟動，加載，運行服務提供者（Standalone 容器）。
• 1 服務提供者在啟動時，向注冊中心注冊自己提供的服務（Zookeeper/Redis）。
• 2 服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
• 3 注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數據給消費者。
• 4 服務消費者，從提供者地址列表中，基于軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
• 5 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心（根據數據可以動態調整權重）。

?

Dubbo 集群容錯

?

?

　　面對服務消費方時，當業務邏輯中需要調用一個服務時，真正調用的其實是 Dubbo 創建的一個 Proxy，該 Proxy 會把調用轉化成調用指定的 Invoker（Cluster 將 Directory 中的多個 Invoker 偽裝成一個 Invoker，對上層透明，偽裝過程包含了容錯邏輯，調用失敗后，重試另一個（通過 LoadBalance），Invoker 封裝了 Provider 地址及 Service 接口信息）。而在這一系列的委托調用的過程里就完成了服務治理的邏輯，最終完成調用。

?

Dubbo 特點

• 遠程通訊: 提供對多種基于長連接的 NIO 框架抽象封裝（非阻塞 I/O 的通信方式），包括多種線程模型、序列化，以及“請求-響應”模式的信息交換方式。
• 集群容錯: 提供基于接口方法的透明遠程過程調用（RPC），包括多協議支持（自定義 RPC 協議），以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。
• 自動發現: 基于注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

?

優點

• Dubbo 支持?RPC 調用，服務之間的調用性能會很好。
• 支持多種序列化協議，如 Hessian、HTTP、WebService。
• Dobbo Admin后臺管理功能強大，提供了路由規則、動態配置、訪問控制、權重調節、均衡負載等功能。
• 在國內影響力比較大，中文社區文檔較為全面。
• 阿里最近重啟維護。

?

缺點

• Registry 嚴重依賴第三方組件（zookeeper 或者 redis），當這些組件出現問題時，服務調用很快就會中斷。
• Dubbo 只支持 RPC 調用。使得服務提供方（抽象接口）與調用方在代碼上產生了強依賴，服務提供者需要不斷將包含抽象接口的 jar 包打包出來供消費者使用。一旦打包出現問題，就會導致服務調用出錯，并且以后發布部署會成很大問題（太強的依賴關系）。
• 另外，以后要兼容服務，Dubbo RPC 本身不支持跨語言（可以用跨語言 RPC 框架解決，比如gRPC（重復封裝了），或者自己再包一層 REST 服務，提供跨平臺的服務調用實現，但相對麻煩很多）
• Dubbo?只是實現了服務治理，其他微服務框架并未包含，如果需要使用，需要結合第三方框架實現（比如分布式配置用淘寶的 Diamond、服務跟蹤用京東的 Hydra，但使用相對麻煩些），開發成本較高，且風險較大。
• 社區更新不及時（雖然最近在重啟更新）。

?

Spring Cloud 是什么？

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

?

Spring Cloud 組件架構

流程：

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

?

?

優點

• 有強大的 Spring 社區、Netflix 等公司支持，并且開源社區貢獻非常活躍。
• 標準化的將微服務的成熟產品和框架結合一起，Spring Cloud 提供整套的微服務解決方案，開發成本較低，且風險較小。
• 基于 Spring Boot，具有簡單配置、快速開發、輕松部署、方便測試的特點。
• 支持 REST 服務調用，相比于 RPC，更加輕量化和靈活（服務之間只依賴一紙契約，不存在代碼級別的強依賴），有利于跨語言服務的實現，以及服務的發布部署。另外，結合 Swagger，也使得服務的文檔一體化。
• 提供了 Docker 微服務編排支持。
• 國內外企業應用非常多，經受了大公司的應用考驗（比如 Netfilx 公司），以及強大的開源社區支持。

?

?

缺點

• 支持 REST 服務調用，但是因為接口定義過輕，導致定義文檔與實際實現不一致導致服務集成時的問題（可以使用統一文檔和版本管理解決，比如 Swagger）。
• 另外，REST 服務調用性能會比 RPC 低一些（但也不是強綁定）
• Spring Cloud 整合了大量組件，相關文檔比較復雜，需要針對性的進行閱讀。

?

?

Dubbo 和 Spring Cloud 對比

Dubbo 專注 RPC 和服務治理，Spring Cloud 則是一個微服務架構生態。

?

ZooKeeper 和 Eureka 的區別

　　鑒于服務發現對服務化架構的重要性，Dubbo 實踐通常以 ZooKeeper 為注冊中心（Dubbo 原生支持的 Redis 方案需要服務器時間同步，且性能消耗過大）。針對分布式領域著名的 CAP 理論（C——數據一致性，A——服務可用性，P——服務對網絡分區故障的容錯性），Zookeeper 保證的是 CP ，但對于服務發現而言，可用性比數據一致性更加重要，AP 勝過 CP，而 Eureka 設計則遵循 AP 原則。
Spring Cloud 支持 Consul（CA）和 Zookeeper，但不推薦使用。

?

總結

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

總結

以上是生活随笔為你收集整理的Dobbo和SpringCloud的区别的全部內容，希望文章能夠幫你解決所遇到的問題。

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