Service Mesh是什么？

和大部分吃瓜碼農(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)榘凑漳Ｊ饺慕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)槟Ｊ揭弧⒛Ｊ蕉拇_有一些固有的缺陷，模式一相對(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)維成本。