服務(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)系。