微服務Dubbo和SpringCloud架構設計、優劣勢比較

http://youzhixueyuan.com/comparison-of-dubbo-and-springcloud-architecture-design.html

http://youzhixueyuan.com/spring-clound-from-entry-to-mastery.html

一、核心部件

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

1、總體架構

•  Dubbo 核心部件（如下圖）:

•  Provider： 暴露服務的提供方，可以通過jar或者容器的方式啟動服務
•  Consumer：呼叫遠端服務的服務消費方。
•  Registry： 服務註冊中心和發現中心。
•  Monitor： 統計服務和呼叫次數，呼叫時間監控中心。（dubbo的控制檯頁面中可以顯示，目前只有一個簡單版本）
•  Container：服務執行的容器。

▲Dubbo 總體架構

Spring Cloud總體架構如下圖

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

▲Spring Cloud總體架構

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

2、微服務架構核心要素

Dubbo只是實現了服務治理，而Spring Cloud子專案分別覆蓋了微服務架構下的眾多部件，而服務治理只是其中的一個方面。Dubbo提供了各種Filter，對於上述中“無”的要素，可以通過擴充套件Filter來完善。

例如

1．分散式配置：可以使用淘寶的diamond、百度的disconf來實現分散式配置管理

2．服務跟蹤：可以使用京東開源的Hydra，或者擴充套件Filter用Zippin來做服務跟蹤

3．批量任務：可以使用噹噹開源的Elastic-Job、tbschedule

點評：從核心要素來看，Spring Cloud 更勝一籌，在開發過程中只要整合Spring Cloud的子專案就可以順利的完成各種元件的融合，而Dubbo缺需要通過實現各種Filter來做定製，開發成本以及技術難度略高。

二、通訊協議

基於通訊協議層面對2種框架支援的協議型別以及執行效率方面進行比較；

（一）、支援協議

1、Dubbo：dubbo使用RPC通訊協議，提供序列化方式如下：

dubbo：Dubbo預設協議採用單一長連線和NIO非同步通訊，適合於小資料量大併發的服務呼叫，以及服務消費者機器數遠大於服務提供者機器數的情況

rmi：RMI協議採用JDK標準的java.rmi.*實現，採用阻塞式短連線和JDK標準序列化方式

Hessian:Hessian協議用於整合Hessian的服務，Hessian底層採用Http通訊，採用Servlet暴露服務，Dubbo預設內嵌Jetty作為伺服器實現

http:採用Spring的HttpInvoker實現

Webservice:基於CXF的frontend-simple和transports-http實現

2、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方式互動，為跨平臺呼叫奠定了基礎。

四、元件執行流程

下圖中的每個元件都是需要部署在單獨的伺服器上，gateway用來接受前端請求、聚合服務，並批量呼叫後臺原子服務。每個service層和單獨的DB互動。

▲Dubbo元件執行流程

•  gateWay:前置閘道器，具體業務操作，gateWay通過dubbo提供的負載均衡機制自動完成
•  Service：原子服務，只提供該業務相關的原子服務
•  Zookeeper：原子服務註冊到zk上

▲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.6版本，而Spring Cloud更新的非常快，目前已經更新到Finchley.M2。因此，企業需要根據自身的研發水平和所處階段選擇合適的架構來解決業務問題，不管是Dubbo還是Spring Cloud都是實現微服務有效的工具。