和大部分吃瓜碼農(nóng)一樣,剛開(kāi)始小碼農(nóng)對(duì)此也是一頭霧水。什么是Service Mesh?它與SpringCloud相比有什么優(yōu)勢(shì)呢?在接下來(lái)的內(nèi)容中,就和大家一起初步了解下Service Mesh吧!
微服務(wù)的核心問(wèn)題
在了解Service Mesh之前,我們先來(lái)討論下這樣一個(gè)問(wèn)題:“微服務(wù)架構(gòu)的核心技術(shù)問(wèn)題是什么?“。
我們知道在將整個(gè)軟件系統(tǒng)架構(gòu)升級(jí)為微服務(wù)模式以后,服務(wù)(這里是指獨(dú)立對(duì)外提供服務(wù)的進(jìn)程實(shí)體)的規(guī)模會(huì)越來(lái)越大,少則幾個(gè)到十幾個(gè),多則上百個(gè)。而這,還只是從應(yīng)用拆分本身的數(shù)量上看的,在實(shí)際的生產(chǎn)部署中,單個(gè)微服務(wù)進(jìn)程也不會(huì)以單節(jié)點(diǎn)的方式部署,而多是以集群的方式進(jìn)行部署。
此時(shí)自然就會(huì)產(chǎn)生兩個(gè)核心的問(wèn)題:一是服務(wù)發(fā)現(xiàn),即服務(wù)的消費(fèi)方(Consumer)如何發(fā)現(xiàn)服務(wù)的提供方(Provider)的問(wèn) 題? **二是負(fù)載均衡,即我們的微服務(wù)在以集群方式部署后,服務(wù)的消費(fèi)方如何以某種負(fù)載均衡策略訪問(wèn)集群中的微服務(wù)實(shí)例?
**
在回答以上兩個(gè)問(wèn)題時(shí),我們先來(lái)回顧下目前業(yè)界經(jīng)歷過(guò)的三種服務(wù)發(fā)現(xiàn)及負(fù)載模式:
模式一:傳統(tǒng)集中式代理
這種模式在微服務(wù)架構(gòu)模式興起之前,是業(yè)界非常主流的模式,目前大部分公司的架構(gòu)模型依然采用的是這種模式。
在集中式處理方式中,應(yīng)用系統(tǒng)根據(jù)各自需要進(jìn)行模塊化設(shè)計(jì)與拆分,雖然呈現(xiàn)了一定分布式的特性,但是在服務(wù)間調(diào)用時(shí),仍然需要通過(guò)F5或Nginx這類(lèi)軟硬件負(fù)載均衡器來(lái)進(jìn)行通信,從而保證高可用。
并且這種方式的服務(wù)注冊(cè)更多的是一種 依賴于運(yùn)維人員、手工配置、明確調(diào)用的方式 。在實(shí)踐中一般是通過(guò)DNS域名解析服務(wù)的方式配合實(shí)現(xiàn),通過(guò)在Nginx或F5上建立服務(wù)域名和服務(wù)IP/端口之間的映射關(guān)系,來(lái)實(shí)現(xiàn)消費(fèi)端通過(guò)請(qǐng)求服務(wù)域名,域名指向代理(Nginx/F5),代理通過(guò)解析目標(biāo)IP地址并最終進(jìn)行負(fù)載均衡和服務(wù)調(diào)用。
這種架構(gòu)模式,目前依然是最為普遍的一種方式,即便很多互聯(lián)網(wǎng)公司最終會(huì)轉(zhuǎn)向微服務(wù)時(shí)代的模式二、模式三,但是在其初創(chuàng)期仍然會(huì)選擇這種方式進(jìn)行過(guò)渡。
模式二:客戶端嵌入式代理
這種方式就是目前以SpringCloud框架為代表的微服務(wù)架構(gòu)模式所使用的方式,包括在此之前比較著名的Dubbo框架采用的也這樣的方式。在這種模式下, 服務(wù)發(fā)現(xiàn)和負(fù)載均衡邏輯都是以本地庫(kù)的方式嵌在具體的應(yīng)用中 。
這種模式一般需要獨(dú)立的服務(wù)中心注冊(cè)組件配合,服務(wù)啟動(dòng)時(shí)自動(dòng)注冊(cè)到服務(wù)中心并定期上報(bào)心跳,客戶端代理則通過(guò)注冊(cè)中心進(jìn)行服務(wù)發(fā)現(xiàn)并進(jìn)行負(fù)載均衡。
在之前的文章中(推薦閱讀有鏈接)我們介紹的基于SpringCloud的微服務(wù)架構(gòu)就是通過(guò)采用Consul作為注冊(cè)中心, 客戶端通過(guò)集成SpringCloud提供的相關(guān)本地組件(@EnableDiscoveryClient),進(jìn)行服務(wù)調(diào)用時(shí)通過(guò)FeignClient(底層采用Ribbon)實(shí)現(xiàn)了服務(wù)的發(fā)現(xiàn)與負(fù)載均衡 。
客戶端嵌入的模式,在應(yīng)用本身嵌入了服務(wù)發(fā)現(xiàn)&負(fù)載均衡的邏輯,雖然像SpringCloud這樣的框架提供了很方便快捷的開(kāi)發(fā)集成,但因?yàn)閼?yīng)用本身的業(yè)務(wù)邏輯與底層通信邏輯耦合在了一起,從架構(gòu)角度看會(huì)顯得讓人有點(diǎn)不是很爽的感覺(jué),當(dāng)然這種缺陷,也在某些層面的確限制了很多的能力,在我們具體討論Service Mesh時(shí)再和大家討論。
從目前的實(shí)踐看,因?yàn)槲⒎?wù)架構(gòu)的概念最近幾年才開(kāi)始流行,加上SpringCloud的熱度,以及之前Dubbo等框架的助推,目前很多互聯(lián)網(wǎng)公司的微服務(wù)架構(gòu)體系都是基于這種模式進(jìn)行的。作者所在的公司,目前也主要是基于SpringCloud框架進(jìn)行的一些實(shí)踐,當(dāng)然,因?yàn)樽罱黃ervice Mesh的火熱,也在逐步開(kāi)始進(jìn)行新的架構(gòu)嘗試。
在這里,還需要特別澄清一下,這種模式也并非完全是對(duì)模式一的替代,這種架構(gòu)方式的 主要關(guān)注點(diǎn)在于內(nèi)部服務(wù)的治理 ,對(duì)于需要通過(guò)互聯(lián)網(wǎng)訪問(wèn)的服務(wù),我們依然需要通過(guò)F5/Nginx之類(lèi)軟硬件負(fù)載均衡器進(jìn)行負(fù)載均衡,例如在這種模式下 ApiGateway在向外提供公網(wǎng)服務(wù)時(shí),仍然是通過(guò)DNS+Nginx進(jìn)行的擴(kuò)展 。
模式三:獨(dú)立式進(jìn)程代理
這種模式其實(shí)上面兩種模式的一種折中方案,用于實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和負(fù)載均衡的代理(Proxy)既不是獨(dú)立集中部署(像F5/Nginx),也不是嵌入在客戶應(yīng)用程序中(像Ribbon)。而是 作為一個(gè)獨(dú)立的進(jìn)程部署在每一臺(tái)主機(jī)上,主機(jī)上的多個(gè)消費(fèi)者(Consumer)應(yīng)用可以共用這個(gè)代理來(lái)實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和負(fù)載均衡 。
這種模式相比較于模式二而言,也需要獨(dú)立的服務(wù)注冊(cè)中心組件配合。只是將負(fù)責(zé)服務(wù)發(fā)現(xiàn)、負(fù)載均衡、熔斷限流等相關(guān)邏輯從原有的消費(fèi)客戶端進(jìn)程拆分到單獨(dú)的代理進(jìn)程中了,由這個(gè)獨(dú)立部署的代理來(lái)負(fù)責(zé)服務(wù)發(fā)現(xiàn)、路由分流(負(fù)載均衡)、熔斷限流、安全控制、監(jiān)控等功能。
**Service Mesh(服務(wù)網(wǎng)格)
**
在了解完以上三種模式后,我們?cè)賮?lái)一起探討下什么是Service Mesh?Service Mesh又稱為 服務(wù)網(wǎng)格 ,本質(zhì)上就是我們前面介紹過(guò)的模式三。之所為稱之為服務(wù)網(wǎng)格是因?yàn)榘凑漳J饺慕Y(jié)構(gòu),每個(gè)主機(jī)上同時(shí)運(yùn)行了業(yè)務(wù)邏輯代碼和代理,此時(shí)這個(gè)代理被形象地稱之為 SideCar (業(yè)務(wù)代碼進(jìn)程相當(dāng)于主駕駛,共享一個(gè)代理相當(dāng)于邊車(chē)),服務(wù)之間通過(guò)SideCar發(fā)現(xiàn)和調(diào)用目標(biāo)服務(wù),從而形成服務(wù)之間的一種網(wǎng)絡(luò)狀依賴關(guān)系,然后通過(guò)獨(dú)立部署的一種稱之為 控制平面(ControlPlane) 的獨(dú)立組件來(lái)集中配置這種依賴調(diào)用關(guān)系以及進(jìn)行路由流量調(diào)撥等操作,如果此時(shí)我們把主機(jī)和業(yè)務(wù)邏輯從視覺(jué)圖上剝離,就會(huì)出現(xiàn)一種網(wǎng)絡(luò)狀的架構(gòu),服務(wù)網(wǎng)格由此得名。
在新一代的Service Mesh架構(gòu)中服務(wù)消費(fèi)方和提供方的主機(jī)(或容器)兩邊都會(huì)部署代理SideCar,此時(shí)SideCar與服務(wù)所在的主機(jī)又稱之為 數(shù)據(jù)平面(DataPlane), 與我們前面說(shuō)到的用于依賴關(guān)系配置和流量調(diào)撥操作的控制平面相對(duì)應(yīng)**。**
Istio
通過(guò)上述的內(nèi)容,我們從概念上應(yīng)該是大概理解了什么是Service Mesh。而具體要落地Service Mesh只有概念是遠(yuǎn)遠(yuǎn)不夠的,相反,如果沒(méi)有一種可落地執(zhí)行的開(kāi)源框架,這個(gè)概念也不會(huì)這么快被大家所接受。
Istio就是目前受Google/IBM 等大廠支持和推進(jìn)的一個(gè) ServiceMesh開(kāi)源框架組合。它解決了開(kāi)發(fā)人員和運(yùn)維人員在整體應(yīng)用程序向分布式微服務(wù)體系結(jié)構(gòu)過(guò)渡時(shí)所面臨的挑戰(zhàn)。我們知道無(wú)論是基于SpringCloud的微服務(wù)架構(gòu)體系還是目前我們說(shuō)到的Service Mesh,隨著微服務(wù)規(guī)模的增長(zhǎng)會(huì)帶來(lái)很多的復(fù)雜性,如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、故障恢復(fù)、監(jiān)控,甚至A/B測(cè)試、訪問(wèn)控制等。而要對(duì)涉及這些問(wèn)題的微服務(wù)架構(gòu)體系進(jìn)行管理,如果沒(méi)有成熟的組件的話,就會(huì)需要耗費(fèi)很多的精力去開(kāi)發(fā)一些運(yùn)維工具,而這個(gè)成本是非常高的。
而Istio則提供了一個(gè)完整的解決方案來(lái)滿足微服務(wù)應(yīng)用程序的各種需求。下圖是Istio官網(wǎng)(https://istio.io)所展示的關(guān)于Istio的一張架構(gòu)圖:
在這張架構(gòu)圖中Istio服務(wù)網(wǎng)格在邏輯上還是分為數(shù)據(jù)平面和 控制平面 。數(shù)據(jù)平面中的SideCar代理是由一款叫做Envoy的組件來(lái)承擔(dān)的,它是一款用C++開(kāi)發(fā)的高性能代理,用于協(xié)調(diào)服務(wù)網(wǎng)格中所有服務(wù)的入站和出站流量。
Envoy提供了很多內(nèi)在的特性如:
- 動(dòng)態(tài)服務(wù)發(fā)現(xiàn)
- 負(fù)載均衡
- TLS終止
- HTTP/2和gRPC代理
- 熔斷器
- 健康檢查
- 基于百分比的流量分割
- 故障注入
- 豐富的指標(biāo)
從上面的特性上看實(shí)際上Envoy已經(jīng)提供了很完備的SideCar的功能,只是由于其采用的是C++開(kāi)發(fā)的,目前在國(guó)內(nèi)的落地實(shí)踐中會(huì)有不同的取舍和選擇,如螞蟻金服內(nèi)部在實(shí)踐的過(guò)程中就沒(méi)有使用Istio默認(rèn)集成的Envoy,而是用 Golang 開(kāi)發(fā)了新的 Sidecar,已經(jīng) 開(kāi)源的SOFAMosn ,來(lái)替代 Envoy。
在Istio控制平面中的各個(gè)組件的作用如下:
- Mixer :負(fù)責(zé)收集代理上采集的度量數(shù)據(jù),進(jìn)行集中監(jiān)控;
- Pilot :主要為SideCar提供服務(wù)發(fā)現(xiàn)、智能路由(如A/B測(cè)試)、彈性(超時(shí)、重試、斷路器)的流量管理功能;
-
Citadel :負(fù)責(zé)安全控制數(shù)據(jù)的管理和下發(fā);
以上就是關(guān)于Istio及其組件的一些介紹,具體如何使用Istio進(jìn)行服務(wù)開(kāi)發(fā)及安裝操作,大家可以看看Istio的官網(wǎng) , 另外需要強(qiáng)調(diào)的是kubernetes是目前 Isito 主力支持的容器云環(huán)境。
Service Mesh的優(yōu)勢(shì)
事實(shí)上Service Mesh這種架構(gòu)模式并不新鮮,很早就有公司進(jìn)行過(guò)嘗試,之所以最近又火起來(lái)的原因,主要還是因?yàn)槟J揭弧⒛J蕉拇_有一些固有的缺陷,模式一相對(duì)比較重,有 單點(diǎn)問(wèn)題和性能問(wèn)題 。
而模式二則有客戶端復(fù)雜,支持多語(yǔ)言困難,路由、熔斷、限流等服務(wù)操作無(wú)法集中治理的問(wèn)題。而Service Mesh則正好彌補(bǔ)了二者的不足,它是純分布式的,沒(méi)有單點(diǎn)的問(wèn)題,性能也比較優(yōu)秀并且與開(kāi)發(fā)語(yǔ)言無(wú)關(guān),還可以集中進(jìn)行治理。
此外,隨著微服務(wù)化、多語(yǔ)言和容器化的發(fā)展趨勢(shì),很多公司也迫切需要一種 輕量級(jí)的服務(wù)發(fā)現(xiàn)機(jī)制 ,加上一些大廠如Google/IBM的助推(如kubernetes與Docker的容器之爭(zhēng)),正好Service Mesh迎合了這種趨勢(shì),所以才有今天火熱的局面。
實(shí)踐案例
目前國(guó)內(nèi)如阿里、微博、摩拜等公司都在積極探索Service Mesh的架構(gòu)模式,只是在實(shí)踐中一般具備一定開(kāi)發(fā)能力的公司都會(huì)選擇基于Istio進(jìn)行二次開(kāi)發(fā),如目前阿里開(kāi)源的SOFAMesh/SOFAMosn兩個(gè)項(xiàng)目。
而對(duì)于開(kāi)發(fā)及運(yùn)維能力不強(qiáng)的公司,是否有必要將自己的架構(gòu)體系立刻升級(jí)為Service Mesh模式還是需要好好考慮考慮,因?yàn)楫吘惯@會(huì)帶來(lái)很大的運(yùn)維成本。
-
軟件系統(tǒng)
+關(guān)注
關(guān)注
0文章
61瀏覽量
9470 -
SmartMesh
+關(guān)注
關(guān)注
1文章
29瀏覽量
15112 -
微服務(wù)架構(gòu)
+關(guān)注
關(guān)注
0文章
23瀏覽量
2945
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論