微服務(wù)架構(gòu)是互聯(lián)網(wǎng)很熱門的話題，是互聯(lián)網(wǎng)技術(shù)發(fā)展的必然結(jié)果。它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。雖然微服務(wù)架構(gòu)沒有公認(rèn)的技術(shù)標(biāo)準(zhǔn)和規(guī)范或者草案，但業(yè)界已經(jīng)有一些很有影響力的開源微服務(wù)架構(gòu)框架提供了微服務(wù)的關(guān)鍵思路，例如Dubbo和Spring Cloud。各大互聯(lián)網(wǎng)公司也有自研的微服務(wù)框架，但其模式都于這二者相差不大。

微服務(wù)主要的優(yōu)勢如下：

1、降低復(fù)雜度

將原來偶合在一起的復(fù)雜業(yè)務(wù)拆分為單個服務(wù)，規(guī)避了原本復(fù)雜度無止境的積累。每一個微服務(wù)專注于單一功能，并通過定義良好的接口清晰表述服務(wù)邊界。每個服務(wù)開發(fā)者只專注服務(wù)本身，通過使用緩存、DAL等各種技術(shù)手段來提升系統(tǒng)的性能，而對于消費方來說完全透明。

2、可獨立部署

由于微服務(wù)具備獨立的運行進程，所以每個微服務(wù)可以獨立部署。當(dāng)業(yè)務(wù)迭代時只需要發(fā)布相關(guān)服務(wù)的迭代即可，降低了測試的工作量同時也降低了服務(wù)發(fā)布的風(fēng)險。

3、容錯

在微服務(wù)架構(gòu)下，當(dāng)某一組件發(fā)生故障時，故障會被隔離在單個服務(wù)中。 通過限流、熔斷等方式降低錯誤導(dǎo)致的危害，保障核心業(yè)務(wù)正常運行。

4、擴展

單塊架構(gòu)應(yīng)用也可以實現(xiàn)橫向擴展，就是將整個應(yīng)用完整的復(fù)制到不同的節(jié)點。當(dāng)應(yīng)用的不同組件在擴展需求上存在差異時，微服務(wù)架構(gòu)便體現(xiàn)出其靈活性，因為每個服務(wù)可以根據(jù)實際需求獨立進行擴展。

本文主要圍繞微服務(wù)的技術(shù)選型、通訊協(xié)議、服務(wù)依賴模式、開始模式、運行模式等幾方面來綜合比較Dubbo和Spring Cloud 這2種開發(fā)框架。架構(gòu)師可以根據(jù)公司的技術(shù)實力并結(jié)合項目的特點來選擇某個合適的微服務(wù)架構(gòu)平臺，以此穩(wěn)妥地實施項目的微服務(wù)化改造或開發(fā)進程。

一、核心部件

微服務(wù)的核心要素在于服務(wù)的發(fā)現(xiàn)、注冊、路由、熔斷、降級、分布式配置，基于上述幾種必要條件對Dubbo和Spring Cloud做出對比。

1、總體架構(gòu)

Dubbo 核心部件（如下圖）:

Provider： 暴露服務(wù)的提供方，可以通過jar或者容器的方式啟動服務(wù)

Consumer：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費方。

Registry： 服務(wù)注冊中心和發(fā)現(xiàn)中心。

Monitor： 統(tǒng)計服務(wù)和調(diào)用次數(shù)，調(diào)用時間監(jiān)控中心。（dubbo的控制臺頁面中可以顯示，目前只有一個簡單版本）

Container：服務(wù)運行的容器。

▲Dubbo 總體架構(gòu)

Spring Cloud總體架構(gòu)如下圖

Service Provider： 暴露服務(wù)的提供方。

Service Consumer：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費方。

EureKa Server： 服務(wù)注冊中心和服務(wù)發(fā)現(xiàn)中心。

▲Spring Cloud總體架構(gòu)

點評：從整體架構(gòu)上來看，二者模式接近，都需要需要服務(wù)提供方，注冊中心，服務(wù)消費方。

2、微服務(wù)架構(gòu)核心要素

Dubbo只是實現(xiàn)了服務(wù)治理，而Spring Cloud子項目分別覆蓋了微服務(wù)架構(gòu)下的眾多部件，而服務(wù)治理只是其中的一個方面。Dubbo提供了各種Filter，對于上述中“無”的要素，可以通過擴展Filter來完善。

例如

1．分布式配置：可以使用淘寶的diamond、百度的disconf來實現(xiàn)分布式配置管理

2．服務(wù)跟蹤：可以使用京東開源的Hydra，或者擴展Filter用Zippin來做服務(wù)跟蹤

3．批量任務(wù)：可以使用當(dāng)當(dāng)開源的Elastic-Job、tbschedule

點評：從核心要素來看，Spring Cloud 更勝一籌，在開發(fā)過程中只要整合Spring Cloud的子項目就可以順利的完成各種組件的融合，而Dubbo缺需要通過實現(xiàn)各種Filter來做定制，開發(fā)成本以及技術(shù)難度略高。

二、通訊協(xié)議

基于通訊協(xié)議層面對2種框架支持的協(xié)議類型以及運行效率方面進行比較；

（一）、支持協(xié)議

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

dubbo：Dubbo缺省協(xié)議采用單一長連接和NIO異步通訊，適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用，以及服務(wù)消費者機器數(shù)遠(yuǎn)大于服務(wù)提供者機器數(shù)的情況

rmi：RMI協(xié)議采用JDK標(biāo)準(zhǔn)的java.rmi.*實現(xiàn)，采用阻塞式短連接和JDK標(biāo)準(zhǔn)序列化方式

Hessian:Hessian協(xié)議用于集成Hessian的服務(wù)，Hessian底層采用Http通訊，采用Servlet暴露服務(wù)，Dubbo缺省內(nèi)嵌Jetty作為服務(wù)器實現(xiàn)

http:采用Spring的HttpInvoker實現(xiàn)

Webservice:基于CXF的frontend-simple和transports-http實現(xiàn)

2、Spring Cloud：Spring Cloud 使用HTTP協(xié)議的REST API

（二）、性能比較

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

說明：客戶端和服務(wù)端配置均采用阿里云的ECS服務(wù)器，4核8G配置，dubbo采用默認(rèn)的dubbo協(xié)議

點評：dubbo支持各種通信協(xié)議，而且消費方和服務(wù)方使用長鏈接方式交互，通信速度上略勝Spring Cloud，如果對于系統(tǒng)的響應(yīng)時間有嚴(yán)格要求，長鏈接更合適。

三、服務(wù)依賴方式

Dubbo：服務(wù)提供方與消費方通過接口的方式依賴，服務(wù)調(diào)用設(shè)計如下：

interface層：服務(wù)接口層，定義了服務(wù)對外提供的所有接口

Molel層：服務(wù)的DTO對象層，

business層：業(yè)務(wù)實現(xiàn)層，實現(xiàn)interface接口并且和DB交互

因此需要為每個微服務(wù)定義了各自的interface接口，并通過持續(xù)集成發(fā)布到私有倉庫中，調(diào)用方應(yīng)用對微服務(wù)提供的抽象接口存在強依賴關(guān)系，開發(fā)、測試、集成環(huán)境都需要嚴(yán)格的管理版本依賴。

通過maven的install & deploy命令把interface和Model層發(fā)布到倉庫中，服務(wù)調(diào)用方只需要依賴interface和model層即可。在開發(fā)調(diào)試階段只發(fā)布Snapshot版本。等到服務(wù)調(diào)試完成再發(fā)布Release版本，通過版本號來區(qū)分每次迭代的版本。通過xml配置方式即可方面接入dubbo，對程序無入侵。

▲Dubbo接口依賴方式

Spring Cloud：服務(wù)提供方和服務(wù)消費方通過json方式交互，因此只需要定義好相關(guān)json字段即可，消費方和提供方無接口依賴。通過注解方式來實現(xiàn)服務(wù)配置，對于程序有一定入侵。

點評：Dubbo服務(wù)依賴略重，需要有完善的版本管理機制，但是程序入侵少。而Spring Cloud通過Json交互，省略了版本管理的問題，但是具體字段含義需要統(tǒng)一管理，自身Rest API方式交互，為跨平臺調(diào)用奠定了基礎(chǔ)。

四、組件運行流程

下圖中的每個組件都是需要部署在單獨的服務(wù)器上，gateway用來接受前端請求、聚合服務(wù)，并批量調(diào)用后臺原子服務(wù)。每個service層和單獨的DB交互。

▲Dubbo組件運行流程

gateWay:前置網(wǎng)關(guān)，具體業(yè)務(wù)操作，gateWay通過dubbo提供的負(fù)載均衡機制自動完成

Service：原子服務(wù)，只提供該業(yè)務(wù)相關(guān)的原子服務(wù)

Zookeeper：原子服務(wù)注冊到zk上

▲Spring Cloud 組件運行

Spring Cloud

所有請求都統(tǒng)一通過 API 網(wǎng)關(guān)（Zuul）來訪問內(nèi)部服務(wù)。

網(wǎng)關(guān)接收到請求后，從注冊中心（Eureka）獲取可用服務(wù)。

由 Ribbon 進行均衡負(fù)載后，分發(fā)到后端的具體實例。

微服務(wù)之間通過 Feign 進行通信處理業(yè)務(wù)。

點評：業(yè)務(wù)部署方式相同，都需要前置一個網(wǎng)關(guān)來隔絕外部直接調(diào)用原子服務(wù)的風(fēng)險。Dubbo需要自己開發(fā)一套API 網(wǎng)關(guān)，而Spring Cloud則可以通過Zuul配置即可完成網(wǎng)關(guān)定制。使用方式上Spring Cloud略勝一籌。

五、微服務(wù)架構(gòu)組成以及注意事項

到底使用是dubbo還是Spring Cloud其實并不重要，重點在于如何合理的利用微服務(wù)。下面是一張互聯(lián)網(wǎng)通用的架構(gòu)圖,其中每個環(huán)節(jié)都是微服務(wù)的核心部分。

（一）、架構(gòu)分解

網(wǎng)關(guān)集群：數(shù)據(jù)的聚合、實現(xiàn)對接入客戶端的身份認(rèn)證、防報文重放與防數(shù)據(jù)篡改、功能調(diào)用的業(yè)務(wù)鑒權(quán)、響應(yīng)數(shù)據(jù)的脫敏、流量與并發(fā)控制等

業(yè)務(wù)集群：一般情況下移動端訪問和瀏覽器訪問的網(wǎng)關(guān)需要隔離，防止業(yè)務(wù)耦合

Local Cache：由于客戶端訪問業(yè)務(wù)可能需要調(diào)用多個服務(wù)聚合，所以本地緩存有效的降低了服務(wù)調(diào)用的頻次，同時也提示了訪問速度。本地緩存一般使用自動過期方式，業(yè)務(wù)場景中允許有一定的數(shù)據(jù)延時。

服務(wù)層：原子服務(wù)層，實現(xiàn)基礎(chǔ)的增刪改查功能，如果需要依賴其他服務(wù)需要在Service層主動調(diào)用

Remote Cache：訪問DB前置一層分布式緩存，減少DB交互次數(shù)，提升系統(tǒng)的TPS

DAL：數(shù)據(jù)訪問層，如果單表數(shù)據(jù)量過大則需要通過DAL層做數(shù)據(jù)的分庫分表處理。

MQ：消息隊列用來解耦服務(wù)之間的依賴，異步調(diào)用可以通過MQ的方式來執(zhí)行

數(shù)據(jù)庫主從：服務(wù)化過程中畢竟的階段，用來提升系統(tǒng)的TPS

（二）注意事項

服務(wù)啟動方式建議使用jar方式啟動，啟動速度快，更容易監(jiān)控

緩存、緩存、緩存，系統(tǒng)中能使用緩存的地方盡量使用緩存，通過合理的使用緩存可以有效的提高系統(tǒng)的TPS

服務(wù)拆分要合理，盡量避免因服務(wù)拆分而導(dǎo)致的服務(wù)循環(huán)依賴

合理的設(shè)置線程池，避免設(shè)置過大或者過小導(dǎo)致系統(tǒng)異常

如果想學(xué)習(xí)Java性能優(yōu)化，工程化、高性能及分布式、深入淺出。微服務(wù)、Spring，MyBatis，Netty源碼分析的朋友可以加下454377428群里有阿里大牛直播講解技術(shù)，以及Java大型互聯(lián)網(wǎng)技術(shù)的視頻免費分享給大家。

六、總結(jié)

Dubbo出生于阿里系，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于中國各互聯(lián)網(wǎng)公司；只需要通過spring配置的方式即可完成服務(wù)化，對于應(yīng)用無入侵。設(shè)計的目的還是服務(wù)于自身的業(yè)務(wù)為主。雖然阿里內(nèi)部原因dubbo曾經(jīng)一度暫停維護版本，但是框架本身的成熟度以及文檔的完善程度，完全能滿足各大互聯(lián)網(wǎng)公司的業(yè)務(wù)需求。如果我們需要使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成，這樣無形中增加了使用 Dubbo 的難度。

Spring Cloud 是大名鼎鼎的 Spring 家族的產(chǎn)品， 專注于企業(yè)級開源框架的研發(fā)。 Spring Cloud 自從發(fā)展到現(xiàn)在，仍然在不斷的高速發(fā)展，幾乎考慮了服務(wù)治理的方方面面，開發(fā)起來非常的便利和簡單。

Dubbo于2017年開始又重啟維護，發(fā)布了更新后的2.5.6版本，而Spring Cloud更新的非?？?，目前已經(jīng)更新到Finchley.M2。因此，企業(yè)需要根據(jù)自身的研發(fā)水平和所處階段選擇合適的架構(gòu)來解決業(yè)務(wù)問題，不管是Dubbo還是Spring Cloud都是實現(xiàn)微服務(wù)有效的工具。

來自：http://blog.csdn.net/leonardc/article/details/79789325