Dubbo和Spring Cloud微服務架構比較

Dubbo 出生於阿里系，是阿里巴巴服務化治理的核心框架，並被普遍應用於中國各互聯網公司；只須要經過 Spring 配置的方式便可完成服務化，對於應用無***，設計的目的仍是服務於自身的業務爲主。

微服務架構是互聯網很熱門的話題，是互聯網技術發展的必然結果。它提倡將單一應用程序劃分紅一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。

雖然微服務架構沒有公認的技術標準和規範或者草案，但業界已經有一些頗有影響力的開源微服務架構框架提供了微服務的關鍵思路，例如 Dubbo 和 Spring Cloud。

各大互聯網公司也有自研的微服務框架，但其模式都與這兩者相差不大。

微服務主要的優點

下降複雜度

將原來耦合在一塊兒的複雜業務拆分爲單個服務，規避了本來複雜度無止境的積累。

每個微服務專一於單一功能，並經過定義良好的接口清晰表述服務邊界；每一個服務開發者只專一服務自己，經過使用緩存、DAL 等各類技術手段來提高系統的性能，而對於消費方來講徹底透明。

可獨立部署

因爲微服務具有獨立的運行進程，因此每一個微服務能夠獨立部署。當業務迭代時只須要發佈相關服務的迭代便可，下降了測試的工做量同時也下降了服務發佈的風險。

容錯

在微服務架構下，當某一組件發生故障時，故障會被隔離在單個服務中。好比經過限流、熔斷等方式下降錯誤致使的危害，保障核心業務正常運行。

擴展

單塊架構應用也能夠實現橫向擴展，就是將整個應用完整的複製到不一樣的節點。

當應用的不一樣組件在擴展需求上存在差別時，微服務架構便體現出其靈活性，由於每一個服務能夠根據實際需求獨立進行擴展。

本文主要圍繞微服務的技術選型、通信協議、服務依賴模式、開始模式、運行模式等幾方面來綜合比較 Dubbo 和 Spring Cloud 這 2 種開發框架。

架構師能夠根據公司的技術實力並結合項目的特色來選擇某個合適的微服務架構平臺，以此穩妥地實施項目的微服務化改造或開發進程。

核心部件

微服務的核心要素在於服務的發現、註冊、路由、熔斷、降級、分佈式配置，基於上述幾種必要條件對 Dubbo 和 Spring Cloud 作出對比。

整體架構

Dubbo 核心部件（以下圖）:

• Provider：暴露服務的提供方，能夠經過 jar 或者容器的方式啓動服務。
• Consumer：調用遠程服務的服務消費方。
• Registry：服務註冊中心和發現中心。
• Monitor：統計服務和調用次數，調用時間監控中心。（Dubbo 的控制檯頁面中能夠顯示，目前只有一個簡單版本。）
• Container：服務運行的容器。

Dubbo 整體架構

Spring Cloud整體架構（以下圖）：

• Service Provider： 暴露服務的提供方。
• Service Consumer：調用遠程服務的服務消費方。
• EureKa Server： 服務註冊中心和服務發現中心。

Spring Cloud 整體架構

點評：從總體架構上來看，兩者模式接近，都須要服務提供方，註冊中心，服務消費方。

微服務架構核心要素

Dubbo 只是實現了服務治理，而 Spring Cloud 子項目分別覆蓋了微服務架構下的衆多部件，服務治理只是其中的一個方面。

Dubbo 提供了各類 Filter，對於上述中「無」的要素，能夠經過擴展 Filter 來完善。例如：

• 分佈式配置：可使用淘寶的 diamond、百度的 disconf 來實現分佈式配置管理。
• 服務跟蹤：可使用京東開源的 Hydra，或者擴展 Filter 用 Zippin 來作服務跟蹤。
• 批量任務：可使用噹噹開源的 Elastic-Job、tbschedule。

點評：從核心要素來看，Spring Cloud 更勝一籌，在開發過程當中只要整合 Spring Cloud 的子項目就能夠順利的完成各類組件的融合，而 Dubbo 卻須要經過實現各類 Filter 來作定製，開發成本以及技術難度略高。

通信協議

基於通信協議層面對 2 種框架支持的協議類型以及運行效率方面進行比較。

支持協議

Dubbo

Dubbo 使用 RPC 通信協議，提供序列化方式以下：

• Dubbo：Dubbo 缺省協議採用單一長鏈接和 NIO 異步通信，適合於小數據量大併發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的狀況。
• RMI：RMI 協議採用 JDK 標準的 java.rmi.* 實現，採用阻塞式短鏈接和 JDK 標準序列化方式。
• Hessian：Hessian 協議用於集成 Hessian 的服務，Hessian 底層採用 HTTP 通信，採用 Servlet 暴露服務，Dubbo 缺省內嵌 Jetty 做爲服務器實現。
• HTTP：採用 Spring 的 Http Invoker 實現。
• Webservice：基於 CXF 的 frontend-simple 和 transports-http 實現。

Spring Cloud

Spring Cloud 使用 HTTP 協議的 REST API。

性能比較

使用一個 Pojo 對象包含 10 個屬性，請求 10 萬次，Dubbo 和 Spring Cloud 在不一樣的線程數量下，每次請求耗時（ms）以下：

說明：客戶端和服務端配置均採用阿里雲的 ECS 服務器，4 核 8G 配置，Dubbo 採用默認的 Dubbo 協議。

點評：Dubbo 支持各類通訊協議，並且消費方和服務方使用長連接方式交互，通訊速度上略勝 Spring Cloud，若是對於系統的響應時間有嚴格要求，長連接更合適。

服務依賴方式

Dubbo

服務提供方與消費方經過接口的方式依賴，服務調用設計以下：

• Interface 層：服務接口層，定義了服務對外提供的全部接口。
• Molel 層：服務的 DTO 對象層。
• Business層：業務實現層，實現 Interface 接口而且和 DB 交互。

所以須要爲每一個微服務定義各自的 Interface 接口，並經過持續集成發佈到私有倉庫中。調用方應用對微服務提供的抽象接口存在強依賴關係，開發、測試、集成環境都須要嚴格的管理版本依賴。

經過 maven 的 install & deploy 命令把 Interface 和 Model 層發佈到倉庫中，服務調用方只須要依賴 Interface 和 Model 層便可。

在開發調試階段只發布 Snapshot 版本，等到服務調試完成再發布 Release 版本，經過版本號來區分每次迭代的版本。經過 xml 配置方式便可接入 Dubbo，對程序無***。

Dubbo 接口依賴方式

Spring Cloud

服務提供方和服務消費方經過 Json 方式交互，所以只須要定義好相關 Json 字段便可，消費方和提供方無接口依賴。經過註解方式來實現服務配置，對於程序有必定***。

點評：Dubbo 服務依賴略重，須要有完善的版本管理機制，可是程序***少。

而 Spring Cloud 經過 Json 交互，省略了版本管理的問題，可是具體字段含義須要統一管理，自身 Rest API 方式交互，爲跨平臺調用奠基了基礎。

組件運行流程

Dubbo

下圖中的每一個組件都是須要部署在單獨的服務器上，Gateway 用來接受前端請求、聚合服務，並批量調用後臺原子服務。每一個 Service 層和單獨的 DB 交互。

Dubbo 組件運行流程

Dubbo 組件運行：

• Gateway：前置網關，具體業務操做，Gateway 經過 Dubbo 提供的負載均衡機制自動完成。
• Service：原子服務，只提供該業務相關的原子服務。
• Zookeeper：原子服務註冊到 ZK 上。

Spring Cloud 組件運行

Spring Cloud

Spring Cloud組件運行：

• 全部請求都統一經過 API 網關（Zuul）來訪問內部服務。
• 網關接收到請求後，從註冊中心（Eureka）獲取可用服務。
• 由 Ribbon 進行均衡負載後，分發到後端的具體實例。
• 微服務之間經過 Feign 進行通訊處理業務。

點評：業務部署方式相同，都須要前置一個網關來隔絕外部直接調用原子服務的風險。

Dubbo 須要本身開發一套 API 網關，而 Spring Cloud 則能夠經過 Zuul 配置便可完成網關定製。使用方式上 Spring Cloud 略勝一籌。

微服務架構組成以及注意事項

到底使用是 Dubbo 仍是 Spring Cloud 並不重要，重點在於如何合理的利用微服務。

下面是一張互聯網通用的架構圖，其中每一個環節都是微服務的核心部分。

架構分解：

• 網關集羣：數據的聚合、實現對接入客戶端的身份認證、防報文重放與防數據篡改、功能調用的業務鑑權、響應數據的脫敏、流量與併發控制等。
• 業務集羣：通常狀況下移動端訪問和瀏覽器訪問的網關須要隔離，防止業務耦合。
• Local Cache：因爲客戶端訪問業務可能須要調用多個服務聚合，因此本地緩存有效的下降了服務調用的頻次，同時也提示了訪問速度。本地緩存通常使用自動過時方式，業務場景中容許有必定的數據延時。
• 服務層：原子服務層，實現基礎的增刪改查功能，若是須要依賴其餘服務須要在 Service 層主動調用。
• Remote Cache：訪問 DB 前置一層分佈式緩存，減小 DB 交互次數，提高系統的TPS。
• DAL：數據訪問層，若是單表數據量過大則須要經過 DAL 層作數據的分庫分表處理。
• MQ：消息隊列用來解耦服務之間的依賴，異步調用能夠經過 MQ 的方式來執行。
• 數據庫主從：服務化過程當中必經的階段，用來提高系統的 TPS。

注意事項：

• 服務啓動方式建議使用jar方式啓動，啓動速度快，更容易監控。
• 緩存、緩存、緩存，系統中能使用緩存的地方儘可能使用緩存，經過合理的使用緩存能夠有效的提升系統的TPS。
• 服務拆分要合理，儘可能避免因服務拆分而致使的服務循環依賴。
• 合理的設置線程池，避免設置過大或者太小致使系統異常。

總結

Dubbo 出生於阿里系，是阿里巴巴服務化治理的核心框架，並被普遍應用於中國各互聯網公司；只須要經過 Spring 配置的方式便可完成服務化，對於應用無***，設計的目的仍是服務於自身的業務爲主。

雖然阿里內部緣由 Dubbo 曾經一度暫停維護版本，可是框架自己的成熟度以及文檔的完善程度，徹底能知足各大互聯網公司的業務需求。

若是咱們使用配置中心、分佈式跟蹤這些內容都須要本身去集成，這樣無形中增長了使用 Dubbo 的難度。

Spring Cloud 是大名鼎鼎的 Spring 家族的產品， 專一於企業級開源框架的研發。

Spring Cloud 自從發佈到如今，仍然在不斷的高速發展，幾乎考慮了服務治理的方方面面，開發起來很是的便利和簡單。

Dubbo 於 2017 年開始又重啓維護，發佈了更新後的 2.5.7 版本，而 Spring Cloud 更新的很是快，目前已經更新到 Finchley.M2。

所以，企業須要根據自身的研發水平和所處階段選擇合適的架構來解決業務問題，不論是 Dubbo 仍是 Spring Cloud 都是實現微服務有效的工具。