你真的瞭解微服務架構嗎？聽聽八年阿里架構師怎樣講述Dubbo和Spring Cloud微服務架構

微服務架構是互聯網很熱門的話題，是互聯網技術發展的必然結果。它提倡將單一應用程序劃分紅一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。雖然微服務架構沒有公認的技術標準和規範或者草案，但業界已經有一些頗有影響力的開源微服務架構框架提供了微服務的關鍵思路，例如Dubbo和Spring Cloud。各大互聯網公司也有自研的微服務框架，但其模式都於這兩者相差不大。

微服務主要的優點以下：

一、下降複雜度

將原來偶合在一塊兒的複雜業務拆分爲單個服務，規避了本來複雜度無止境的積累。每個微服務專一於單一功能，並經過定義良好的接口清晰表述服務邊界。每一個服務開發者只專一服務自己，經過使用緩存、DAL等各類技術手段來提高系統的性能，而對於消費方來講徹底透明。

二、可獨立部署

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

三、容錯

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

四、擴展

單塊架構應用也能夠實現橫向擴展，就是將整個應用完整的複製到不一樣的節點。當應用的不一樣組件在擴展需求上存在差別時，微服務架構便體現出其靈活性，由於每一個服務能夠根據實際需求獨立進行擴展。

本文主要圍繞微服務的技術選型、通信協議、服務依賴模式、開始模式、運行模式等幾方面來綜合比較Dubbo和Spring Cloud 這2種開發框架。架構師能夠根據公司的技術實力並結合項目的特色來選擇某個合適的微服務架構平臺，以此穩妥地實施項目的微服務化改造或開發進程。

1、核心部件

微服務的核心要素在於服務的發現、註冊、路由、熔斷、降級、分佈式配置，基於上述幾種必要條件對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來完善。

例如

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

2．服務跟蹤：可使用京東開源的Hydra，或者擴展Filter用Zippin來作服務跟蹤

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

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

2、通信協議

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

（一）、支持協議

一、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實現

二、Spring Cloud：Spring Cloud 使用HTTP協議的REST API

（二）、性能比較

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

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

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

3、服務依賴方式

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

• interface層：服務接口層，定義了服務對外提供的全部接口

• Molel層：服務的DTO對象層，

• business層：業務實現層，實現interface接口而且和DB交互

所以須要爲每一個微服務定義了各自的interface接口，並經過持續集成發佈到私有倉庫中，調用方應用對微服務提供的抽象接口存在強依賴關係，開發、測試、集成環境都須要嚴格的管理版本依賴。若是想免費學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java進階羣650385180，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。

經過maven的install & deploy命令把interface和Model層發佈到倉庫中，服務調用方只須要依賴interface和model層便可。在開發調試階段只發布Snapshot版本。等到服務調試完成再發布Release版本，經過版本號來區分每次迭代的版本。經過xml配置方式便可方面接入dubbo，對程序無入侵。

▲Dubbo接口依賴方式

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

點評：Dubbo服務依賴略重，須要有完善的版本管理機制，可是程序入侵少。而Spring Cloud經過Json交互，省略了版本管理的問題，可是具體字段含義須要統一管理，自身Rest API方式交互，爲跨平臺調用奠基了基礎。

4、組件運行流程

下圖中的每一個組件都是須要部署在單獨的服務器上，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略勝一籌。

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

到底使用是dubbo仍是Spring Cloud其實並不重要，重點在於如何合理的利用微服務。下面是一張互聯網通用的架構圖,其中每一個環節都是微服務的核心部分。

（一）、架構分解

• 網關集羣：數據的聚合、實現對接入客戶端的身份認證、防報文重放與防數據篡改、功能調用的業務鑑權、響應數據的脫敏、流量與併發控制等

• 業務集羣：通常狀況下移動端訪問和瀏覽器訪問的網關須要隔離，防止業務耦合

• Local Cache：因爲客戶端訪問業務可能須要調用多個服務聚合，因此本地緩存有效的下降了服務調用的頻次，同時也提示了訪問速度。本地緩存通常使用自動過時方式，業務場景中容許有必定的數據延時。

• 服務層：原子服務層，實現基礎的增刪改查功能，若是須要依賴其餘服務須要在Service層主動調用

• Remote Cache：訪問DB前置一層分佈式緩存，減小DB交互次數，提高系統的TPS

• DAL：數據訪問層，若是單表數據量過大則須要經過DAL層作數據的分庫分表處理。

• MQ：消息隊列用來解耦服務之間的依賴，異步調用能夠經過MQ的方式來執行

• 數據庫主從：服務化過程當中畢竟的階段，用來提高系統的TPS

（二）注意事項

• 服務啓動方式建議使用jar方式啓動，啓動速度快，更容易監控

• 緩存、緩存、緩存，系統中能使用緩存的地方儘可能使用緩存，經過合理的使用緩存能夠有效的提升系統的TPS

• 服務拆分要合理，儘可能避免因服務拆分而致使的服務循環依賴

• 合理的設置線程池，避免設置過大或者太小致使系統異常

6、總結

Dubbo出生於阿里系，是阿里巴巴服務化治理的核心框架，並被普遍應用於中國各互聯網公司；只須要經過spring配置的方式便可完成服務化，對於應用無入侵。設計的目的仍是服務於自身的業務爲主。雖然阿里內部緣由dubbo曾經一度暫停維護版本，可是框架自己的成熟度以及文檔的完善程度，徹底能知足各大互聯網公司的業務需求。若是咱們須要使用配置中心、分佈式跟蹤這些內容都須要本身去集成，這樣無形中增長了使用 Dubbo 的難度。

Spring Cloud 是大名鼎鼎的 Spring 家族的產品， 專一於企業級開源框架的研發。 Spring Cloud 自從發展到如今，仍然在不斷的高速發展，幾乎考慮了服務治理的方方面面，開發起來很是的便利和簡單。

Dubbo於2017年開始又重啓維護，發佈了更新後的2.5.6版本，而Spring Cloud更新的很是快，目前已經更新到Finchley.M2。所以，企業須要根據自身的研發水平和所處階段選擇合適的架構來解決業務問題，無論是Dubbo仍是Spring Cloud都是實現微服務有效的工具。