本系列文章將為大家介紹當(dāng)下最流行的服務(wù)治理、微服務(wù)等相關(guān)內(nèi)容,從服務(wù)治理、SOA、微服務(wù)到最新的服務(wù)網(wǎng)格(Service Mesh)進(jìn)行綜合介紹和分析。易商阜極自2017年開始積極引進(jìn)微服務(wù)的理念,并運(yùn)用于多個(gè)項(xiàng)目實(shí)踐中,為項(xiàng)目升級(jí)改造帶來了顯著效果。本文將以Dubbo為例,向大家介紹SOA、服務(wù)治理等概念,以及Dubbo的基礎(chǔ)知識(shí)和最新發(fā)展情況。 SOA與服務(wù)治理SOA(面向服務(wù)的體系結(jié)構(gòu))概念由來已久,在10多年前便開始進(jìn)入到我們廣大軟件開發(fā)者的視線中。SOA是一種粗粒度、松耦合服務(wù)架構(gòu),服務(wù)之間通過簡(jiǎn)單、精確定義接口進(jìn)行通訊,不涉及底層編程接口和通訊模型。SOA可以看作是B/S模型、Web Service技術(shù)之后的自然延伸。 服務(wù)治理,也稱為SOA治理,是指用來管理SOA的采用和實(shí)現(xiàn)的過程。以下是在2006年時(shí)IBM對(duì)于服務(wù)治理要點(diǎn)的總結(jié): 服務(wù)定義(服務(wù)的范圍、接口和邊界) 服務(wù)部署生命周期(各個(gè)生命周期階段) 服務(wù)版本治理(包括兼容性) 服務(wù)遷移(啟用和退役) 服務(wù)注冊(cè)中心(依賴關(guān)系) 服務(wù)消息模型(規(guī)范數(shù)據(jù)模型) 服務(wù)監(jiān)視(進(jìn)行問題確定) 服務(wù)所有權(quán)(企業(yè)組織) 服務(wù)測(cè)試(重復(fù)測(cè)試) 服務(wù)安全(包括可接受的保護(hù)范圍)
限于當(dāng)時(shí)的技術(shù)發(fā)展水平,廣大軟件設(shè)計(jì)與開發(fā)人員對(duì)于SOA和服務(wù)治理的技術(shù)認(rèn)知還主要停留在Web Service和ESB總線等技術(shù)和規(guī)范上,并沒有真正在軟件開發(fā)中得以充分落地。 Dubbo開源直到2011年10月27日,阿里巴巴開源了自己的SOA服務(wù)化治理方案的核心框架Dubbo,服務(wù)治理和SOA的設(shè)計(jì)理念開始逐漸在國(guó)內(nèi)軟件行業(yè)中落地,并被廣泛應(yīng)用。 Dubbo作為阿里巴巴內(nèi)部的SOA服務(wù)化治理方案的核心框架,在2012年時(shí)已經(jīng)每天為2000+個(gè)服務(wù)提供3,000,000,000+次訪問量支持,并被廣泛應(yīng)用于阿里巴巴集團(tuán)的各成員站點(diǎn)。Dubbo自2011年開源后,已被許多非阿里系公司使用,其中既有當(dāng)當(dāng)網(wǎng)、網(wǎng)易考拉等互聯(lián)網(wǎng)公司,也有中國(guó)人壽、青島海爾等傳統(tǒng)企業(yè)。 Dubbo簡(jiǎn)介Dubbo是一個(gè)高性能服務(wù)框架,致力于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案,以及SOA服務(wù)治理方案,使得應(yīng)用可通過高性能RPC實(shí)現(xiàn)服務(wù)的輸出和輸入功能,和Spring框架可以無縫集成。 作為一個(gè)分布式服務(wù)框架,以及SOA治理方案,Dubbo其功能主要包括:高性能NIO通訊及多協(xié)議集成,服務(wù)動(dòng)態(tài)尋址與路由,軟負(fù)載均衡與容錯(cuò),依賴分析與服務(wù)降級(jí)等。Dubbo最大的特點(diǎn)是按照分層的方式來架構(gòu),使用這種方式可以使各個(gè)層之間解耦合(或者最大限度地松耦合)。從服務(wù)模型的角度來看,Dubbo采用的是一種非常簡(jiǎn)單的模型,要么是提供方提供服務(wù),要么是消費(fèi)方消費(fèi)服務(wù),所以基于這一點(diǎn)可以抽象出服務(wù)提供方(Provider)和服務(wù)消費(fèi)方(Consumer)兩個(gè)角色。 Dubbo包含遠(yuǎn)程通訊、集群容錯(cuò)和自動(dòng)發(fā)現(xiàn)三個(gè)核心部分。提供透明化的遠(yuǎn)程方法調(diào)用,實(shí)現(xiàn)像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法,只需簡(jiǎn)單配置,沒有任何API侵入。同時(shí)具備軟負(fù)載均衡及容錯(cuò)機(jī)制,可在內(nèi)網(wǎng)替代F5等硬件負(fù)載均衡器,降低成本,減少單點(diǎn)。可以實(shí)現(xiàn)服務(wù)自動(dòng)注冊(cè)與發(fā)現(xiàn),不再需要寫死服務(wù)提供方地址,注冊(cè)中心基于接口名查詢服務(wù)提供者的IP地址,并且能夠平滑添加或刪除服務(wù)提供者。 下圖來自Dubbo官網(wǎng),描述了服務(wù)注冊(cè)中心、服務(wù)提供方、服務(wù)消費(fèi)方、服務(wù)監(jiān)控中心之間的調(diào)用關(guān)系,具體如下圖所示:
 節(jié)點(diǎn)角色說明: 節(jié)點(diǎn) | 角色說明 |
---|
Provider | 暴露服務(wù)的服務(wù)提供方。 | Consumer | 調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方。 | Registry | 服務(wù)注冊(cè)與發(fā)現(xiàn)的注冊(cè)中心。 | Monitor | 統(tǒng)計(jì)服務(wù)的調(diào)用次數(shù)和調(diào)用時(shí)間的監(jiān)控中心。 |
調(diào)用關(guān)系說明: 服務(wù)容器負(fù)責(zé)啟動(dòng),加載,運(yùn)行服務(wù)提供者。 服務(wù)提供者在啟動(dòng)時(shí),向注冊(cè)中心注冊(cè)自己提供的服務(wù)。 服務(wù)消費(fèi)者在啟動(dòng)時(shí),向注冊(cè)中心訂閱自己所需的服務(wù)。 注冊(cè)中心返回服務(wù)提供者地址列表給消費(fèi)者,如果有變更,注冊(cè)中心將基于長(zhǎng)連接推送變更數(shù)據(jù)給消費(fèi)者。 服務(wù)消費(fèi)者,從提供者地址列表中,基于軟負(fù)載均衡算法,選一臺(tái)提供者進(jìn)行調(diào)用,如果調(diào)用失敗,再選另一臺(tái)調(diào)用。 服務(wù)消費(fèi)者和提供者,在內(nèi)存中累計(jì)調(diào)用次數(shù)和調(diào)用時(shí)間,定時(shí)每分鐘發(fā)送一次統(tǒng)計(jì)數(shù)據(jù)到監(jiān)控中心。
Dubbo總體架構(gòu)Dubbo框架設(shè)計(jì)共劃分了10層,最上面的Service層是留給實(shí)際使用Dubbo開發(fā)分布式服務(wù)的開發(fā)者實(shí)現(xiàn)業(yè)務(wù)邏輯的接口層。圖中左邊淡藍(lán)背景的為服務(wù)消費(fèi)方使用的接口,右邊淡綠色背景的為服務(wù)提供方使用的接口,位于中軸線上的為雙方都用到的接口。
 各層說明: ● Config配置層:對(duì)外配置接口,以ServiceConfig、ReferenceConfig為中心,可以直接初始化配置類,也可以通過Spring解析配置生成配置類。
● Proxy服務(wù)代理層:服務(wù)接口透明代理,生成服務(wù)的客戶端Stub和服務(wù)器端Skeleton,以ServiceProxy為中心,擴(kuò)展接口為ProxyFactory。
● Registry注冊(cè)中心層:封裝服務(wù)地址的注冊(cè)與發(fā)現(xiàn),以服務(wù)URL為中心,擴(kuò)展接口為RegistryFactory、Registry、RegistryService。
● Cluster路由層:封裝多個(gè)提供者的路由及負(fù)載均衡,并橋接注冊(cè)中心,以Invoker為中心,擴(kuò)展接口為Cluster、Directory、Router、LoadBalance。
● Monitor監(jiān)控層:RPC調(diào)用次數(shù)和調(diào)用時(shí)間監(jiān)控,以Statistics為中心,擴(kuò)展接口為MonitorFactory、Monitor、MonitorService。
● Protocol遠(yuǎn)程調(diào)用層:封將RPC調(diào)用,以Invocation、Result為中心,擴(kuò)展接口為Protocol、Invoker、Exporter。
● Exchange信息交換層:封裝請(qǐng)求響應(yīng)模式,同步轉(zhuǎn)異步,以Request、Response為中心,擴(kuò)展接口為Exchanger、ExchangeChannel、ExchangeClient、ExchangeServer。
● Transport網(wǎng)絡(luò)傳輸層:抽象MINA和Netty為統(tǒng)一接口,以Message為中心,擴(kuò)展接口為Channel、Transporter、Client、Server、Codec。
● Serialize數(shù)據(jù)序列化層:可復(fù)用的一些工具,擴(kuò)展接口為Serialization、ObjectInput、ObjectOutput、ThreadPool。 模塊分包
各模塊說明: ● dubbo-common公共邏輯模塊:包括Util類和通用模型。
● dubbo-remoting遠(yuǎn)程通訊模塊:相當(dāng)于Dubbo協(xié)議的實(shí)現(xiàn),如果RPC用 RMI協(xié)議則不需要使用此包。
● dubbo-rpc遠(yuǎn)程調(diào)用模塊:抽象各種協(xié)議,以及動(dòng)態(tài)代理,只包含一對(duì)一的調(diào)用,不關(guān)心集群的管理。
● dubbo-cluster集群模塊:將多個(gè)服務(wù)提供方偽裝為一個(gè)提供方,包括:負(fù)載均衡、容錯(cuò)、路由等,集群的地址列表可以是靜態(tài)配置的,也可以是由注冊(cè)中心下發(fā)。
● dubbo-registry注冊(cè)中心模塊:基于注冊(cè)中心下發(fā)地址的集群方式,以及對(duì)各種注冊(cè)中心的抽象。
● dubbo-monitor監(jiān)控模塊:統(tǒng)計(jì)服務(wù)調(diào)用次數(shù)、調(diào)用時(shí)間的、調(diào)用鏈跟蹤的服務(wù)。
● dubbo-config配置模塊:是Dubbo對(duì)外的API,用戶通過Config使用Dubbo,隱藏Dubbo所有細(xì)節(jié)。
● dubbo-container容器模塊:是一個(gè)Standlone的容器,以簡(jiǎn)單的Main加載Spring啟動(dòng),因?yàn)榉?wù)通常不需要Tomcat/JBoss等Web容器的特性,沒必要用Web容器去加載服務(wù)。 協(xié)議支持● Dubbo協(xié)議(默認(rèn)協(xié)議)
● Hessian協(xié)議
● HTTP協(xié)議
● RMI協(xié)議
● WebService協(xié)議
● Thrift協(xié)議
● Memcached協(xié)議
● Redis協(xié)議 注冊(cè)中心1、Multicast注冊(cè)中心: Multicast注冊(cè)中心不需要啟動(dòng)任何中心節(jié)點(diǎn),只要廣播地址一樣,就可以互相發(fā)現(xiàn)。組播受網(wǎng)絡(luò)結(jié)構(gòu)限制,只適合小規(guī)模應(yīng)用或開發(fā)階段使用。組播地址段:224.0.0.0 - 239.255.255.255。 2、ZooKeeper注冊(cè)中心(推薦): ZooKeeper是Apacahe子項(xiàng)目,是一個(gè)樹型的目錄服務(wù),支持變更推送,適合作為Dubbo服務(wù)的注冊(cè)中心,可用于生產(chǎn)環(huán)境。
 對(duì)上圖流程說明如下: 服務(wù)提供者(Provider)啟動(dòng)時(shí),向/dubbo/com.foo.BarService/providers目錄下寫入U(xiǎn)RL。 服務(wù)消費(fèi)者(Consumer)啟動(dòng)時(shí),訂閱/dubbo/com.foo.BarService/providers目錄下的URL,向/dubbo/com.foo.BarService/consumers目錄下寫入自己的URL。 監(jiān)控中心(Monitor)啟動(dòng)時(shí),訂閱/dubbo/com.foo.BarService目錄下的所有提供者和消費(fèi)者URL。
3、Redis注冊(cè)中心: 阿里內(nèi)部并沒有采用Redis做為注冊(cè)中心,而是使用自己實(shí)現(xiàn)的基于數(shù)據(jù)庫(kù)的注冊(cè)中心,即:Redis注冊(cè)中心并沒有在阿里內(nèi)部長(zhǎng)時(shí)間運(yùn)行的可靠性保障,此Redis橋接實(shí)現(xiàn)只為開源版本提供,其可靠性依賴于Redis本身的可靠性。 4、Simple注冊(cè)中心: Simple注冊(cè)中心本身就是一個(gè)普通的Dubbo服務(wù),可以減少第三方依賴,使整體通訊方式一致。只是簡(jiǎn)單實(shí)現(xiàn),不支持集群,可作為自定義注冊(cè)中心的參考,但不適合直接用于生產(chǎn)環(huán)境。 遠(yuǎn)程通信與信息交換遠(yuǎn)程通信需要指定通信雙方所約定的協(xié)議,在保證通信雙方理解協(xié)議語(yǔ)義的基礎(chǔ)上,還要保證高效、穩(wěn)定的消息傳輸。Dubbo繼承了當(dāng)前主流的網(wǎng)絡(luò)通信框架,主要包括如下幾個(gè): ● Mina
● Netty(默認(rèn))
● Grizzly 停止維護(hù)從2012年10月23日Dubbo 2.5.3發(fā)布后,在Dubbo開源將滿一周年之際,阿里基本停止了對(duì)Dubbo的主要升級(jí)。只在之后的2013年和2014年更新過2次對(duì)Dubbo 2.4的維護(hù)版本,然后停止了所有維護(hù)工作。Dubbo對(duì)Srping的支持也停留在了Spring 2.5.6版本上。 分支出現(xiàn)在阿里停止維護(hù)和升級(jí)Dubbo期間,當(dāng)當(dāng)網(wǎng)開始維護(hù)自己的Dubbo分支版本Dubbox,支持了新版本的Spring,并對(duì)外開源了Dubbox。同時(shí),網(wǎng)易考拉也維護(hù)了自己的獨(dú)立分支Dubbok,可惜并未對(duì)外開源。 重獲新生經(jīng)過多年漫長(zhǎng)的等待,隨著微服務(wù)的火熱興起,在國(guó)內(nèi)外開發(fā)者對(duì)阿里不再升級(jí)維護(hù)Dubbo的吐槽聲中,阿里終于開始重新對(duì)Dubbo的升級(jí)和維護(hù)工作。在2017年9月7日 ,阿里發(fā)布了Dubbo的2.5.4版本,距離上一個(gè)版本2.5.3發(fā)布已經(jīng)接近快5年時(shí)間了。在隨后的幾個(gè)月中,阿里Dubbo開發(fā)團(tuán)隊(duì)以差不多每月一版本的速度開始快速升級(jí)迭代,修補(bǔ)了Dubbo老版本多年來存在的諸多bug,并對(duì)Spring等組件的支持進(jìn)行了全面升級(jí)。 分支合并在2018年1月8日,Dubbo 2.6.0版本發(fā)布,新版本將之前當(dāng)當(dāng)網(wǎng)開源的Dubbo分支Dubbox進(jìn)行了合并,實(shí)現(xiàn)了Dubbo版本的統(tǒng)一整合。 Dubbo與Spring Cloud阿里巴巴負(fù)責(zé)主導(dǎo)了 Dubbo 重啟維護(hù)的研發(fā)工程師劉軍在接受采訪時(shí)表示:當(dāng)前由于 RPC 協(xié)議、注冊(cè)中心元數(shù)據(jù)不匹配等問題,在面臨微服務(wù)基礎(chǔ)框架選型時(shí)Dubbo與Spring Cloud是只能二選一,這也是為什么大家總是拿Dubbo和Spring Cloud做對(duì)比的原因之一。Dubbo之后會(huì)積極尋求適配到Spring Cloud生態(tài),比如作為Spring Cloud的二進(jìn)制通信方案來發(fā)揮Dubbo的性能優(yōu)勢(shì),或者Dubbo通過模塊化以及對(duì)http的支持適配到Spring Cloud。 未來展望2018年1月8日,Dubbo創(chuàng)始人之一梁飛在Dubbo交流群里透露了Dubbo 3.0正在動(dòng)工的消息。Dubbo 3.0內(nèi)核與Dubbo 2.0完全不同,但兼容Dubbo 2.0。Dubbo 3.0將以Streaming為內(nèi)核,不再是Dubbo時(shí)代的RPC,但是RPC會(huì)在Dubbo 3.0中變成遠(yuǎn)程Streaming對(duì)接的一種可選形態(tài)。Dubbo 3.0將支持可選Service Mesh,多加一層IPC,這主要是為了兼容老系統(tǒng),而內(nèi)部則會(huì)優(yōu)先嘗試內(nèi)嵌模式。代理模式Ops可獨(dú)立升級(jí)框架,減少業(yè)務(wù)侵入,而內(nèi)嵌模式可以帶業(yè)務(wù)測(cè)試、部署節(jié)點(diǎn)少、穩(wěn)定性檢測(cè)方便。同時(shí),可以將Dubbo 3.0啟動(dòng)為獨(dú)立進(jìn)程,由dubbo-mesh進(jìn)行IPC,路由、負(fù)載均衡和熔斷機(jī)制將由獨(dú)立進(jìn)程控制。 總結(jié)從 Dubbo 新版本的路線規(guī)劃上可以看出,新版本的Dubbo在原有服務(wù)治理的功能基礎(chǔ)上,將全面擁抱微服務(wù)和Service Mesh。同時(shí),考慮到在阿里云已經(jīng)有了Dubbo的商業(yè)版本,在未來一段時(shí)間內(nèi),Dubbo的更新與維護(hù)應(yīng)該不會(huì)再長(zhǎng)時(shí)間中斷。在我們進(jìn)行服務(wù)治理以及微服務(wù)架構(gòu)設(shè)計(jì)時(shí),新版本Dubbo對(duì)我們廣大開發(fā)者來說都將會(huì)是一個(gè)不錯(cuò)的選擇。
|