微服务架构基础之Service Mesh
ServiceMesh(服務(wù)網(wǎng)格) 概念在社區(qū)里頭非常火,有人提出 2018 年是 ServiceMesh 年,還有人提出 ServiceMesh 是下一代的微服務(wù)架構(gòu)基礎(chǔ)。
那么到底什么是 ServiceMesh?它的誕生是為了解決什么問題?企業(yè)是否適合引入 ServiceMesh?
?
微服務(wù)架構(gòu)的核心技術(shù)問題
?
在業(yè)務(wù)規(guī)模化和研發(fā)效能提升等因素的驅(qū)動(dòng)下,從單塊應(yīng)用向微服務(wù)架構(gòu)的轉(zhuǎn)型 (如下圖所示),已經(jīng)成為很多企業(yè) (尤其是互聯(lián)網(wǎng)企業(yè)) 數(shù)字化轉(zhuǎn)型的趨勢。
在微服務(wù)模式下,企業(yè)內(nèi)部服務(wù)少則幾個(gè)到幾十個(gè),多則上百個(gè),每個(gè)服務(wù)一般都以集群方式部署,這時(shí)自然產(chǎn)生兩個(gè)問題 (如下圖所示):
?
一、服務(wù)發(fā)現(xiàn):?服務(wù)的消費(fèi)方 (Consumer) 如何發(fā)現(xiàn)服務(wù)的提供方 (Provider)?
二、負(fù)載均衡:?服務(wù)的消費(fèi)方如何以某種負(fù)載均衡策略訪問集群中的服務(wù)提供方實(shí)例?
作為架構(gòu)師,如果你理解了這兩個(gè)問題,也就理解了微服務(wù)架構(gòu)在技術(shù)上最核心問題。
?
三種服務(wù)發(fā)現(xiàn)模式
?
服務(wù)發(fā)現(xiàn)和負(fù)載均衡并不是新問題,業(yè)界其實(shí)已經(jīng)探索和總結(jié)出一些常用的模式,這些模式的核心其實(shí)是代理 (Proxy,如下圖所以),以及代理在架構(gòu)中所處的位置。
?
在服務(wù)消費(fèi)方和服務(wù)提供方之間增加一層代理,由代理負(fù)責(zé)服務(wù)發(fā)現(xiàn)和負(fù)載均衡功能,消費(fèi)方通過代理間接訪問目標(biāo)服務(wù)。根據(jù)代理在架構(gòu)上所處的位置不同,當(dāng)前業(yè)界主要有三種不同的服務(wù)發(fā)現(xiàn)模式:
模式一:傳統(tǒng)集中式代理
?
?
這是最簡單和傳統(tǒng)做法,在服務(wù)消費(fèi)者和生產(chǎn)者之間,代理作為獨(dú)立一層集中部署,由獨(dú)立團(tuán)隊(duì) (一般是運(yùn)維或框架) 負(fù)責(zé)治理和運(yùn)維。常用的集中式代理有硬件負(fù)載均衡器 (如 F5),或者軟件負(fù)載均衡器 (如 Nginx),F5(4 層負(fù)載)+Nginx(7 層負(fù)載) 這種軟硬結(jié)合兩層代理也是業(yè)內(nèi)常見做法,兼顧配置的靈活性 (Nginx 比 F5 易于配置)。
這種方式通常在 DNS 域名服務(wù)器的配合下實(shí)現(xiàn)服務(wù)發(fā)現(xiàn),服務(wù)注冊(cè) (建立服務(wù)域名和 IP 地址之間的映射關(guān)系) 一般由運(yùn)維人員在代理上手工配置,服務(wù)消費(fèi)方僅依賴服務(wù)域名,這個(gè)域名指向代理,由代理解析目標(biāo)地址并做負(fù)載均衡和調(diào)用。
國外知名電商網(wǎng)站 eBay,雖然體量巨大,但其內(nèi)部的服務(wù)發(fā)現(xiàn)機(jī)制仍然是基于這種傳統(tǒng)的集中代理模式,國內(nèi)公司如攜程,也是采用這種模式。
模式二:客戶端嵌入式代理
?
這是很多互聯(lián)網(wǎng)公司比較流行的一種做法,代理 (包括服務(wù)發(fā)現(xiàn)和負(fù)載均衡邏輯) 以客戶庫的形式嵌入在應(yīng)用程序中。這種模式一般需要獨(dú)立的服務(wù)注冊(cè)中心組件配合,服務(wù)啟動(dòng)時(shí)自動(dòng)注冊(cè)到注冊(cè)中心并定期報(bào)心跳,客戶端代理則發(fā)現(xiàn)服務(wù)并做負(fù)載均衡。
Netflix 開源的 Eureka(注冊(cè)中心)[附錄 1] 和 Ribbon(客戶端代理)[附錄 2] 是這種模式的典型案例,國內(nèi)阿里開源的 Dubbo 也是采用這種模式。
模式三:主機(jī)獨(dú)立進(jìn)程代理
這種做法是上面兩種模式的一個(gè)折中,代理既不是獨(dú)立集中部署,也不嵌入在客戶應(yīng)用程序中,而是作為獨(dú)立進(jìn)程部署在每一個(gè)主機(jī)上,一個(gè)主機(jī)上的多個(gè)消費(fèi)者應(yīng)用可以共用這個(gè)代理,實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和負(fù)載均衡,如下圖所示。這個(gè)模式一般也需要獨(dú)立的服務(wù)注冊(cè)中心組件配合,作用同模式二。
阿里、微博、摩拜、唯品會(huì)等公司都在積極探索Service Mesh的架構(gòu)模式,只是在實(shí)踐中一般具備一定開發(fā)能力的公司都會(huì)選擇基于Istio進(jìn)行二次開發(fā),如目前阿里開源的SOFAMesh/SOFAMosn兩個(gè)項(xiàng)目。
?
?Service Mesh(服務(wù)網(wǎng)格)
?
?Service Mesh又稱為服務(wù)網(wǎng)格,本質(zhì)上就是我們前面介紹過的模式三。之所為稱之為服務(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)于邊車),服務(wù)之間通過SideCar發(fā)現(xiàn)和調(diào)用目標(biāo)服務(wù),從而形成服務(wù)之間的一種網(wǎng)絡(luò)狀依賴關(guān)系,然后通過獨(dú)立部署的一種稱之為控制平面(ControlPlane)的獨(dú)立組件來集中配置這種依賴調(diào)用關(guān)系以及進(jìn)行路由流量調(diào)撥等操作,如果此時(shí)我們把主機(jī)和業(yè)務(wù)邏輯從視覺圖上剝離,就會(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),與我們前面說到的用于依賴關(guān)系配置和流量調(diào)撥操作的控制平面相對(duì)應(yīng)。
?
Istio
?
通過上述的內(nèi)容,我們從概念上應(yīng)該是大概理解了什么是Service Mesh。而具體要落地Service Mesh只有概念是遠(yuǎn)遠(yuǎn)不夠的,相反,如果沒有一種可落地執(zhí)行的開源框架,這個(gè)概念也不會(huì)這么快被大家所接受。
?Istio就是目前受Google/IBM 等大廠支持和推進(jìn)的一個(gè) ServiceMesh開源框架組合。它解決了開發(fā)人員和運(yùn)維人員在整體應(yīng)用程序向分布式微服務(wù)體系結(jié)構(gòu)過渡時(shí)所面臨的挑戰(zhàn)。我們知道無論是基于SpringCloud的微服務(wù)架構(gòu)體系還是目前我們說到的Service Mesh,隨著微服務(wù)規(guī)模的增長會(huì)帶來很多的復(fù)雜性,如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、故障恢復(fù)、監(jiān)控,甚至A/B測試、訪問控制等。而要對(duì)涉及這些問題的微服務(wù)架構(gòu)體系進(jìn)行管理,如果沒有成熟的組件的話,就會(huì)需要耗費(fèi)很多的精力去開發(fā)一些運(yùn)維工具,而這個(gè)成本是非常高的。
?
而Istio則提供了一個(gè)完整的解決方案來滿足微服務(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的組件來承擔(dān)的,它是一款用C++開發(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++開發(fā)的,目前在國內(nèi)的落地實(shí)踐中會(huì)有不同的取舍和選擇,如螞蟻金服內(nèi)部在實(shí)踐的過程中就沒有使用Istio默認(rèn)集成的Envoy,而是用 Golang 開發(fā)了新的 Sidecar,已經(jīng)開源的SOFAMosn,來替代 Envoy。
?
在Istio控制平面中的各個(gè)組件的作用如下:
Mixer:負(fù)責(zé)收集代理上采集的度量數(shù)據(jù),進(jìn)行集中監(jiān)控;
Pilot:主要為SideCar提供服務(wù)發(fā)現(xiàn)、智能路由(如A/B測試)、彈性(超時(shí)、重試、斷路器)的流量管理功能;
Citadel:負(fù)責(zé)安全控制數(shù)據(jù)的管理和下發(fā);
?
以上就是關(guān)于Istio及其組件的一些介紹,具體如何使用Istio進(jìn)行服務(wù)開發(fā)及安裝操作,大家可以看看Istio的官網(wǎng),另外需要強(qiáng)調(diào)的是kubernetes是目前 Isito 主力支持的容器云環(huán)境。
?
Service Mesh的優(yōu)勢
?
事實(shí)上Service Mesh這種架構(gòu)模式并不新鮮,很早就有公司進(jìn)行過嘗試,之所以最近又火起來的原因,主要還是因?yàn)槟J揭弧⒛J蕉拇_有一些固有的缺陷,模式一相對(duì)比較重,有單點(diǎn)問題和性能問題。
?
而模式二則有客戶端復(fù)雜,支持多語言困難,路由、熔斷、限流等服務(wù)操作無法集中治理的問題。而Service Mesh則正好彌補(bǔ)了二者的不足,它是純分布式的,沒有單點(diǎn)的問題,性能也比較優(yōu)秀并且與開發(fā)語言無關(guān),還可以集中進(jìn)行治理。
?
此外,隨著微服務(wù)化、多語言和容器化的發(fā)展趨勢,很多公司也迫切需要一種輕量級(jí)的服務(wù)發(fā)現(xiàn)機(jī)制,加上一些大廠如Google/IBM的助推(如kubernetes與Docker的容器之爭),正好Service Mesh迎合了這種趨勢,所以才有今天火熱的局面。
原文地址:https://www.cnblogs.com/tianyamoon/p/10106587.html
.NET社區(qū)新聞,深度好文,歡迎訪問公眾號(hào)文章匯總 http://www.csharpkit.com
總結(jié)
以上是生活随笔為你收集整理的微服务架构基础之Service Mesh的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: eShopOnContainers 看微
- 下一篇: dotnet core调试docker下