微服務-Dubbo和Spring Cloud微服務架構比較
轉載聲明
本文大量內容系轉載自網絡，有刪改，並參考其他文檔資料加入了一些內容：
- Dubbo和Spring Cloud微服務架構比較
- 作者：aspirant
- 出處：cnblogs
1 背景
1.1 概述
Dubbo 出生於阿里系，是阿里巴巴服務化治理的核心框架，並被廣泛應用於中國各互聯網公司；只需要通過 Spring 配置的方式即可完成服務化，對於應用無入侵，設計的目的還是服務於自身的業務爲主。
微服務架構是互聯網很熱門的話題，是互聯網技術發展的必然結果。它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。
雖然微服務架構沒有公認的技術標準和規範或者草案，但業界已經有一些很有影響力的開源微服務架構框架提供了微服務的關鍵思路，例如 Dubbo 和 Spring Cloud。
各大互聯網公司也有自研的微服務框架，但其模式都與這二者相差不大。
1.2 微服務主要的優勢
-
降低複雜度
將原來耦合在一起的複雜業務拆分爲單個服務，規避了原本複雜度無止境的積累。每一個微服務專注於單一功能，並通過定義良好的接口清晰表述服務邊界；
每個服務開發者只專注服務本身，通過使用緩存、DAL 等各種技術手段來提升系統的性能，而對於消費方來說完全透明。
-
可獨立部署
由於微服務具備獨立的運行進程，所以每個微服務可以獨立部署。當業務迭代時只需要發佈相關服務的迭代即可，降低了測試的工作量同時也降低了服務發佈的風險。 -
容錯
在微服務架構下，當某一組件發生故障時，故障會被隔離在單個服務中。比如通過限流、熔斷等方式降低錯誤導致的危害，保障核心業務正常運行。 -
可擴展
單塊架構應用也可以實現橫向擴展，就是將整個應用完整的複製到不同的節點。當應用的不同組件在擴展需求上存在差異時，微服務架構便體現出其靈活性，因爲每個服務可以根據實際需求獨立進行擴展。
2 對比
2.1 概述
本文主要圍繞微服務的技術選型、通訊協議、服務依賴模式、開始模式、運行模式等幾方面來綜合比較 Dubbo 和 Spring Cloud 這 2 種開發框架。
架構師可以根據公司的技術實力並結合項目的特點來選擇某個合適的微服務架構平臺，以此穩妥地實施項目的微服務化改造或開發進程。
微服務的核心要素在於服務的發現、註冊、路由、熔斷、降級、分佈式配置，基於上述幾種必要條件對 Dubbo 和 Spring Cloud 做出對比。
2.2 總體架構
2.2.1 Dubbo總體架構
Dubbo 核心部件（如下圖）:
- Provider：暴露服務的提供方，可以通過 jar 或者容器的方式啓動服務。
- Consumer：調用遠程服務的服務消費方。
- Registry：服務註冊中心和發現中心。
- Monitor：統計服務和調用次數，調用時間監控中心。（Dubbo 的控制檯頁面中可以顯示，目前只有一個簡單版本。）
- Container：服務運行的容器。
2.2.2 Spring Cloud總體架構
- Service Provider： 暴露服務的提供方。
- Service Consumer：調用遠程服務的服務消費方。
- EureKa Server： 服務註冊中心和服務發現中心。
2.2.2 架構對比小結
從整體架構上來看，二者模式接近，都需要三個角色：
- 註冊中心
- 服務提供方
- 服務消費方
2.3 微服務架構核心要素
2.3.1 對比
- Dubbo 只是實現了服務治理
Dubbo 提供了各種 Filter，對於上述中“無”的要素，可以通過擴展 Filter 來完善。例如：- 分佈式配置：
可以使用淘寶的 diamond、百度的 disconf 來實現分佈式配置管理。 - 服務跟蹤：
可以使用京東開源的 Hydra，或者擴展 Filter 用 Zippin 來做服務跟蹤。 - 批量任務：
可以使用噹噹開源的 Elastic-Job、tbschedule。
- 分佈式配置：
- Spring Cloud 子項目分別覆蓋了微服務架構下的衆多部件，服務治理只是其中的一個方面
2.3.2 小結
從核心要素來看，Spring Cloud 更勝一籌，在開發過程中只要整合 Spring Cloud 的子項目就可以順利的完成各種組件的融合，而 Dubbo 卻需要通過實現各種 Filter 來做定製，開發成本以及技術難度略高。
2.4 通訊協議
基於通訊協議層面對 2 種框架支持的協議類型以及運行效率方面進行比較。
2.4.1 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 實現。
2.4.2 Spring Cloud支持的協議
Spring Cloud 使用 HTTP 協議的 REST API。
2.4.3 性能比較
使用一個 Pojo 對象包含 10 個屬性，請求 10 萬次，Dubbo 和 Spring Cloud 在不同的線程數量下，每次請求耗時（ms）如下，越低越好（說明：客戶端和服務端配置均採用阿里雲的 ECS 服務器，4 核 8G 配置，Dubbo 採用默認的 Dubbo 協議。）：
Dubbo 支持各種通信協議，而且消費方和服務方使用長鏈接方式交互，通信速度上略勝 Spring Cloud，如果對於系統的響應時間有嚴格要求，長鏈接更合適。
2.5 服務依賴方式
2.5.1 Dubbo服務依賴方式
服務提供方與消費方通過接口的方式依賴，服務調用設計如下：
- Interface 層
服務接口層，定義了服務對外提供的所有接口。 - Model 層
服務的 DTO 對象層。 - Business層
業務實現層，實現 Interface 接口並且和 DB 交互。
因此需要爲每個微服務定義各自的 Interface 接口，並通過持續集成發佈到私有倉庫中。
而對於調用方應用，對微服務提供的抽象接口存在強依賴關係，開發、測試、集成環境都需要嚴格的管理版本依賴。通過 maven 的 install & deploy 命令把 Interface 和 Model 層發佈到倉庫中，服務調用方只需要依賴 Interface 和 Model 層即可。
在開發調試階段只發布 Snapshot 版本，等到服務調試完成再發布 Release 版本，通過版本號來區分每次迭代的版本。通過 xml 配置方式即可接入 Dubbo，對程序無入侵。
2.5.2 Spring Cloud服務依賴方式
服務提供方和服務消費方通過 Json 方式交互，因此只需要定義好相關 Json 字段即可，消費方和提供方無接口依賴。通過註解方式來實現服務配置，對於程序有一定入侵。
2.5.3 小結
- Dubbo 服務依賴略重，需要有完善的版本管理機制，但是程序入侵少。
- 而 Spring Cloud 通過 Json 交互，省略了版本管理的問題，但是具體字段含義需要統一管理，自身 Rest API 方式交互，爲跨平臺調用奠定了基礎。
2.6 組件運行流程
2.6.1 Dubbo
下圖中的每個組件都是需要部署在單獨的服務器上，Gateway 用來接受前端請求、聚合服務，並批量調用後臺原子服務。每個 Service 層和單獨的 DB 交互。
- Gateway：前置網關，具體業務操作，Gateway 通過 Dubbo 提供的負載均衡機制自動完成。
- XX Service：原子服務，只提供該業務相關的原子服務。
- Zookeeper：原子服務註冊到 ZK 上。
2.6.2 Spring Cloud 組件運行
- 所有請求都統一通過 API 網關（Zuul）來訪問內部服務。
- 網關接收到請求後，從註冊中心（Eureka）獲取可用服務。
- 由 Ribbon 進行均衡負載後，分發到後端的具體實例。
- 微服務之間通過 Feign 進行通信處理業務。
2.6.3 小結
- 業務部署方式相同，都需要前置一個網關來隔絕外部直接調用原子服務的風險。
- Dubbo 需要自己開發一套 API 網關，而 Spring Cloud 則可以通過 Zuul 配置即可完成網關定製。使用方式上 Spring Cloud 略勝一籌。
3 微服務架構組成以及注意事項
到底使用是 Dubbo 還是 Spring Cloud 並不重要，重點在於如何合理的利用微服務。
下面是一張互聯網通用的架構圖，其中每個環節都是微服務的核心部分。
- 網關集羣
數據的聚合、實現對接入客戶端的身份認證、防報文重放與防數據篡改、功能調用的業務鑑權、響應數據的脫敏、流量與併發控制等。 - 業務集羣
一般情況下移動端訪問和瀏覽器訪問的網關需要隔離，防止業務耦合。 - Local Cache
由於客戶端訪問業務可能需要調用多個服務聚合，所以本地緩存有效的降低了服務調用的頻次，同時也提示了訪問速度。本地緩存一般使用自動過期方式，業務場景中允許有一定的數據延時。 - 服務層
原子服務層，實現基礎的增刪改查功能，如果需要依賴其他服務需要在 Service 層主動調用。 - Remote Cache
訪問 DB 前置一層分佈式緩存，減少 DB 交互次數，提升系統的TPS。 - DAL
數據訪問層，如果單表數據量過大則需要通過 DAL 層做數據的分庫分表處理。 - MQ
消息隊列用來解耦服務之間的依賴，異步調用可以通過 MQ 的方式來執行。 - 數據庫主從
服務化過程中必經的階段，用來提升系統的 TPS。
注意事項：
- 服務啓動方式建議使用jar方式啓動，啓動速度快，更容易監控。
- 緩存很重要，系統中能使用緩存的地方儘量使用緩存，通過合理的使用緩存可以有效的提高系統的TPS。
- 服務拆分要合理，儘量避免因服務拆分而導致的服務循環依賴。
- 合理的設置線程池，避免設置過大或者過小導致系統異常。
4 總結
4.1 Dubbo
Dubbo 出生於阿里系，是阿里巴巴服務化治理的核心框架，並被廣泛應用於中國各互聯網公司；只需要通過 Spring 配置的方式即可完成服務化，對於應用無入侵，設計的目的還是服務於自身的業務爲主。
雖然阿里內部原因 Dubbo 曾經一度暫停維護版本，但是框架本身的成熟度以及文檔的完善程度，完全能滿足各大互聯網公司的業務需求。
但如果我們使用配置中心、分佈式跟蹤這些內容都需要自己去集成，這樣無形中增加了使用 Dubbo 的難度。
4.2 Spring Cloud
Spring Cloud 是大名鼎鼎的 Spring 家族的產品， 專注於企業級開源框架的研發。
Spring Cloud 自從發佈到現在，仍然在不斷的高速發展，幾乎考慮了服務治理的方方面面，開發起來非常的便利和簡單。
Dubbo 於 2017 年開始又重啓維護，發佈了更新後的 2.5.7 版本，而 Spring Cloud 更新的非常快，目前已經更新到 Finchley.M2。
因此，企業需要根據自身的研發水平和所處階段選擇合適的架構來解決業務問題，不管是 Dubbo 還是 Spring Cloud 都是實現微服務有效的工具。