整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
服務(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ù)具備獨立的運行進(jìn)程，所以每個微服務(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ù)實際需求獨立進(jìn)行擴展。
本文主要圍繞微服務(wù)的技術(shù)選型、通訊協(xié)議、服務(wù)依賴模式、開始模式、運行模式等幾方面來綜合比較Dubbo和Spring Cloud 這2種開發(fā)框架。架構(gòu)師可以根據(jù)公司的技術(shù)實力并結(jié)合項目的特點來選擇某個合適的微服務(wù)架構(gòu)平臺，以此穩(wěn)妥地實施項目的微服務(wù)化改造或開發(fā)進(jìn)程。
一、核心部件
微服務(wù)的核心要素在于服務(wù)的發(fā)現(xiàn)、注冊、路由、熔斷、降級、分布式配置，基于上述幾種必要條件對Dubbo和Spring Cloud做出對比。
1、總體架構(gòu)
▲Dubbo 總體架構(gòu)
Spring Cloud總體架構(gòu)如下圖
▲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é)議類型以及運行效率方面進(jìn)行比較；
（一）、支持協(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è)計如下：
因此需要為每個微服務(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組件運行流程
▲Spring Cloud 組件運行
Spring Cloud
點評：業(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)分解
（二）注意事項
六、總結(jié)
Dubbo出生于阿里系，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于中國各互聯(lián)網(wǎng)公司；只需要通過spring配置的方式即可完成服務(wù)化，對于應(yīng)用無入侵。設(shè)計的目的還是服務(wù)于自身的業(yè)務(wù)為主。雖然阿里內(nèi)部原因dubbo曾經(jīng)一度暫停維護(hù)版本，但是框架本身的成熟度以及文檔的完善程度，完全能滿足各大互聯(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年開始又重啟維護(hù)，發(fā)布了更新后的2.5.6版本，而Spring Cloud更新的非?？?，目前已經(jīng)更新到Finchley.M2。因此，企業(yè)需要根據(jù)自身的研發(fā)水平和所處階段選擇合適的架構(gòu)來解決業(yè)務(wù)問題，不管是Dubbo還是Spring Cloud都是實現(xiàn)微服務(wù)有效的工具。
者：moon
原文：https://mp.weixin.qq.com/s/-kVf5qWqcw-4AJF7LL3uWw
雖然金三銀四過了，但是金九銀十馬上就要到了，還不快快準(zhǔn)備起來？
今天就開啟《面試八股文》系列的第一版-RPC王者Dubbo，moon 在后續(xù)的《面試八股文》系列還將繼續(xù)推出mysql，spring，并發(fā)，redis，kafka，zookeeper等一系列文章。
當(dāng)然大家有什么好的建議也可以通過公眾號或者個人微信和我交流。
每天一個知識點
目錄
Dubbo是一個分布式服務(wù)框架，致力于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案，以及SOA服務(wù)治理方案。
RPC（Remote Procedure Call）—遠(yuǎn)程過程調(diào)用，它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計算機程序上請求服務(wù)，而不需要了解底>層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)>通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。RPC采用客戶機/服務(wù)器模式。請求程序就是一個客戶機，而服務(wù)提供程序就是一個服務(wù)器。首先，客戶機調(diào)用進(jìn)程發(fā)>送一個有進(jìn)程參數(shù)的調(diào)用信息到服務(wù)進(jìn)程，然后等待應(yīng)答信息。在服務(wù)器端，進(jìn)程保持睡眠狀態(tài)直到調(diào)用信息到達(dá)為>止。當(dāng)一個調(diào)用信息到達(dá)，服務(wù)器獲得進(jìn)程參數(shù)，計算結(jié)果，發(fā)送答復(fù)信息，然后等待下一個調(diào)用信息，最后，客戶>端調(diào)用進(jìn)程接收答復(fù)信息，獲得進(jìn)程結(jié)果，然后調(diào)用執(zhí)行繼續(xù)進(jìn)行。有多種 RPC模式和執(zhí)行。
我們用一種通俗易懂的語言解釋它，遠(yuǎn)程調(diào)用就是本地機器調(diào)用遠(yuǎn)程機器的一個方法，遠(yuǎn)程機器返回結(jié)果的過程。
為什么要這么做？
主要原因是由于單臺服務(wù)的性能已經(jīng)無法滿足我們了，在這個流量劇增的時代，只有多臺服務(wù)器才能支撐起來現(xiàn)有的用戶體系，
而在這種體系下，服務(wù)越來越多，逐漸演化出了現(xiàn)在這種微服務(wù)化的RPC框架。
Dubbo的核心功能主要包含:
調(diào)用過程圖：
責(zé)任鏈模式:
責(zé)任鏈模式在Dubbo中發(fā)揮的作用舉足輕重，就像是Dubbo框架的骨架。Dubbo的調(diào)用鏈組織是用責(zé)任鏈模式串連起來的。責(zé)任鏈中的每個節(jié)點實現(xiàn)Filter接口，然后由ProtocolFilterWrapper，將所有Filter串連起來。Dubbo的許多功能都是通過Filter擴展實現(xiàn)的，比如監(jiān)控、日志、緩存、安全、telnet以及RPC本身都是。
觀察者模式:
Dubbo中使用觀察者模式最典型的例子是RegistryService。消費者在初始化的時候回調(diào)用subscribe方法，注冊一個觀察者，如果觀察者引用的服務(wù)地址列表發(fā)生改變，就會通過NotifyListener通知消費者。此外，Dubbo的InvokerListener、ExporterListener 也實現(xiàn)了觀察者模式，只要實現(xiàn)該接口，并注冊，就可以接收到consumer端調(diào)用refer和provider端調(diào)用export的通知。
修飾器模式:
Dubbo中還大量用到了修飾器模式。比如ProtocolFilterWrapper類是對Protocol類的修飾。在export和refer方法中，配合責(zé)任鏈模式，把Filter組裝成責(zé)任鏈，實現(xiàn)對Protocol功能的修飾。其他還有ProtocolListenerWrapper、 ListenerInvokerWrapper、InvokerWrapper等。
工廠方法模式:
CacheFactory的實現(xiàn)采用的是工廠方法模式。CacheFactory接口定義getCache方法，然后定義一個AbstractCacheFactory抽象類實現(xiàn)CacheFactory，并將實際創(chuàng)建cache的createCache方法分離出來，并設(shè)置為抽象方法。這樣具體cache的創(chuàng)建工作就留給具體的子類去完成。
抽象工廠模式:
ProxyFactory及其子類是Dubbo中使用抽象工廠模式的典型例子。ProxyFactory提供兩個方法，分別用來生產(chǎn)Proxy和Invoker（這兩個方法簽名看起來有些矛盾，因為getProxy方法需要傳入一個Invoker對象，而getInvoker方法需要傳入一個Proxy對象，看起來會形成循環(huán)依賴，但其實兩個方式使用的場景不一樣）。AbstractProxyFactory實現(xiàn)了ProxyFactory接口，作為具體實現(xiàn)類的抽象父類。然后定義了JdkProxyFactory和JavassistProxyFactory兩個具體類，分別用來生產(chǎn)基于jdk代理機制和基于javassist代理機制的Proxy和Invoker。
適配器模式:
為了讓用戶根據(jù)自己的需求選擇日志組件，Dubbo自定義了自己的Logger接口，并為常見的日志組件（包括jcl, jdk, log4j, slf4j）提供相應(yīng)的適配器。并且利用簡單工廠模式提供一個LoggerFactory，客戶可以創(chuàng)建抽象的Dubbo自定義Logger，而無需關(guān)心實際使用的日志組件類型。在LoggerFactory初始化時，客戶通過設(shè)置系統(tǒng)變量的方式選擇自己所用的日志組件，這樣提供了很大的靈活性。
代理模式:
Dubbo consumer使用Proxy類創(chuàng)建遠(yuǎn)程服務(wù)的本地代理，本地代理實現(xiàn)和遠(yuǎn)程服務(wù)一樣的接口，并且屏蔽了網(wǎng)絡(luò)通信的細(xì)節(jié)，使得用戶在使用本地代理的時候，感覺和使用本地服務(wù)一樣。
可以直接通過Dubbo配置中的version版本來控制多個版本即可。
比如：
<dubbo:service interface="com.xxxx.rent.service.IDemoService" ref="iDemoServiceFirst" version="1.0.0"/>
<dubbo:service interface="com.xxxx.rent.service.IDemoService" ref="iDemoServiceSecond" version="1.0.1"/>
老版本 version=1.0.0, 新版本version=1.0.1
1.通過ServiceConfig解析標(biāo)簽，創(chuàng)建dubbo標(biāo)簽解析器來解析dubbo的標(biāo)簽，容器創(chuàng)建完成之后，觸發(fā)ContextRefreshEvent事件回調(diào)開始暴露服務(wù)
2.通過proxyFactory.getInvoker方法，并利用javassist或DdkProxyFactory來進(jìn)行動態(tài)代理，將服務(wù)暴露接口封裝成invoker對象，里面包含了需要執(zhí)行的方法的對象信息和具體的URL地址。
3.再通過DubboProtocol的實現(xiàn)把包裝后的invoker轉(zhuǎn)換成exporter，
4.然后啟動服務(wù)器server，監(jiān)聽端口
5.最后RegistryProtocol保存URL地址和invoker的映射關(guān)系，同時注冊到服務(wù)中心
1.首先客戶端根據(jù)config文件信息從注冊中心訂閱服務(wù)，首次會全量緩存到本地，后續(xù)的更新會監(jiān)聽動態(tài)更新到本地。
2.之后DubboProtocol根據(jù)provider的地址和接口信息連接到服務(wù)端server，開啟客戶端client，然后創(chuàng)建invoker
3.之后通過invoker為服務(wù)接口生成代理對象，這個代理對象用于遠(yuǎn)程調(diào)用provider，至此完成了服務(wù)引用
Zookeeper、Redis、Multicast、Simple 等都可以作為Dubbo的注冊中心
SPI(Service Provider Interface)，是一種服務(wù)發(fā)現(xiàn)機制，其實就是將結(jié)構(gòu)的實現(xiàn)類寫入配置當(dāng)中，在服務(wù)加載的時候?qū)⑴渲梦募毺帲虞d實現(xiàn)類，這樣就可以在運行的時候，動態(tài)的幫助接口替換實現(xiàn)類。
Dubbo的SPI其實是對java的SPI進(jìn)行了一種增強,可以按需加載實現(xiàn)類之外，增加了 IOC 和 AOP 的特性，還有自適應(yīng)擴展機制。
SPI在dubbo應(yīng)用很多，包括協(xié)議擴展、集群擴展、路由擴展、序列化擴展等等。
Dubbo對于文件目錄的配置分為了三類。
key=com.xxx.xxx
Java Spi
Dubbo Spi
1.加權(quán)隨機：比如我們有三臺服務(wù)器[A, B, C]，給他們設(shè)置權(quán)重為[4, 5, 6]，然后講這三個數(shù)平鋪在水平線上,和為15。
然后在15以內(nèi)生成一個隨機數(shù)，0～4是服務(wù)器A，4～9是服務(wù)器B，9～15是服務(wù)器C
2.最小活躍數(shù)：每個服務(wù)提供者對應(yīng)一個活躍數(shù) active，初始情況下，所有服務(wù)提供者活躍數(shù)均為0。每收到一個請求，活躍數(shù)加1，完成請求后則將活躍數(shù)減1。在服務(wù)運行一段時間后，性能好的服務(wù)提供者處理請求的速度更快，因此活躍數(shù)下降的也越快，此時這樣的服務(wù)提供者能夠優(yōu)先獲取到新的服務(wù)請求。
3.一致性hash：
4.加權(quán)輪詢：比如我們有三臺服務(wù)器[A, B, C]，給他們設(shè)置權(quán)重為[4, 5, 6]，那么假如總共有15次請求，那么會有4次落在A服務(wù)器，5次落在B服務(wù)器，6次落在C服務(wù)器。
1.Failover Cluster失敗自動切換：dubbo的默認(rèn)容錯方案，當(dāng)調(diào)用失敗時自動切換到其他可用的節(jié)點，具體的重試次數(shù)和間隔時間可用通過引用服務(wù)的時候配置，默認(rèn)重試次數(shù)為1是只調(diào)用一次。
2.Failback Cluster失敗自動恢復(fù)：在調(diào)用失敗，記錄日志和調(diào)用信息，然后返回空結(jié)果給consumer，并且通過定時任務(wù)每隔5秒對失敗的調(diào)用進(jìn)行重試
3.Failfast Cluster快速失敗：只會調(diào)用一次，失敗后立刻拋出異常
4.Failsafe Cluster失敗安全：調(diào)用出現(xiàn)異常，記錄日志不拋出，返回空結(jié)果
5.Forking Cluster并行調(diào)用多個服務(wù)提供者：通過線程池創(chuàng)建多個線程，并發(fā)調(diào)用多個provider，結(jié)果保存到阻塞隊列，只要有一個provider成功返回了結(jié)果，就會立刻返回結(jié)果
6.Broadcast Cluster廣播模式：逐個調(diào)用每個provider，如果其中一臺報錯，在循環(huán)調(diào)用結(jié)束后，拋出異常。
分層圖：
從大的范圍來說，dubbo分為三層
Service和Config兩層可以認(rèn)為是API層，主要提供給API使用者，使用者只需要配置和完成業(yè)務(wù)代碼就可以了。
后面所有的層級是SPI層，主 要提供給擴展者使用主要是用來做Dubbo的二次開發(fā)擴展功能。
再劃分到更細(xì)的層面，就是圖中的10層模式。
服務(wù)失效踢出基于Zookeeper的臨時節(jié)點原理。
Zookeeper中節(jié)點是有生命周期的，具體的生命周期取決于節(jié)點的類型，節(jié)點主要分為持久節(jié)點(Persistent)和臨時節(jié)點(Ephemeral) 。
其實主要就是為了將調(diào)用細(xì)節(jié)封裝起來，將調(diào)用遠(yuǎn)程方法變得和調(diào)用本地方法一樣簡單，還可以做一些其他方面的增強，比如負(fù)載均衡，容錯機制，過濾操作，調(diào)用數(shù)據(jù)的統(tǒng)計。
關(guān)于這個問題，其實核心考察點就是你對于RPC框架的理解，一個成熟的RPC框架可以完成哪些功能，其實當(dāng)我們看過一兩個RPC框架后，就可以對這個問題回答個七七八八了，我們來舉個例子。
1.首先我們得需要一個注冊中心，去管理消費者和提供者的節(jié)點信息，這樣才會有消費者和提供才可以去訂閱服務(wù)，注冊服務(wù)。
2.當(dāng)有了注冊中心后，可能會有很多個provider節(jié)點，那么我們肯定會有一個負(fù)載均衡模塊來負(fù)責(zé)節(jié)點的調(diào)用，至于用戶指定路由規(guī)則可以使一個額外的優(yōu)化點。
3.具體的調(diào)用肯定會需要牽扯到通信協(xié)議，所以需要一個模塊來對通信協(xié)議進(jìn)行封裝，網(wǎng)絡(luò)傳輸還要考慮序列化。
4.當(dāng)調(diào)用失敗后怎么去處理？所以我們還需要一個容錯模塊，來負(fù)責(zé)失敗情況的處理。
5.其實做完這些一個基礎(chǔ)的模型就已經(jīng)搭建好了，我們還可以有更多的優(yōu)化點，比如一些請求數(shù)據(jù)的監(jiān)控，配置信息的處理，日志信息的處理等等。
這其實就是一個比較基本的RPC框架的大體思路，大家有沒有g(shù)et到？
服務(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ù)具備獨立的運行進(jìn)程，所以每個微服務(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ù)實際需求獨立進(jìn)行擴展。
本文主要圍繞微服務(wù)的技術(shù)選型、通訊協(xié)議、服務(wù)依賴模式、開始模式、運行模式等幾方面來綜合比較Dubbo和Spring Cloud 這2種開發(fā)框架。架構(gòu)師可以根據(jù)公司的技術(shù)實力并結(jié)合項目的特點來選擇某個合適的微服務(wù)架構(gòu)平臺，以此穩(wěn)妥地實施項目的微服務(wù)化改造或開發(fā)進(jìn)程。
微服務(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é)議層面對2種框架支持的協(xié)議類型以及運行效率方面進(jìn)行比較；
（一）、支持協(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)格要求，長鏈接更合適。
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)格的管理版本依賴。如果想免費學(xué)習(xí)Java工程化、高性能及分布式、深入淺出。微服務(wù)、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java進(jìn)階群：478030634，群里有阿里大牛直播講解技術(shù)，以及Java大型互聯(lián)網(wǎng)技術(shù)的視頻免費分享給大家。
通過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 進(jìn)行均衡負(fù)載后，分發(fā)到后端的具體實例。
微服務(wù)之間通過 Feign 進(jìn)行通信處理業(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略勝一籌。
到底使用是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)異常
Dubbo出生于阿里系，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于中國各互聯(lián)網(wǎng)公司；只需要通過spring配置的方式即可完成服務(wù)化，對于應(yīng)用無入侵。設(shè)計的目的還是服務(wù)于自身的業(yè)務(wù)為主。雖然阿里內(nèi)部原因dubbo曾經(jīng)一度暫停維護(hù)版本，但是框架本身的成熟度以及文檔的完善程度，完全能滿足各大互聯(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年開始又重啟維護(hù)，發(fā)布了更新后的2.5.6版本，而Spring Cloud更新的非常快，目前已經(jīng)更新到Finchley.M2。因此，企業(yè)需要根據(jù)自身的研發(fā)水平和所處階段選擇合適的架構(gòu)來解決業(yè)務(wù)問題，不管是Dubbo還是Spring Cloud都是實現(xiàn)微服務(wù)有效的工具。
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
