Service Mesh（服務(wù)網(wǎng)格）是一個(gè)基礎(chǔ)設(shè)施層，讓服務(wù)之間的通信更安全、快速和可靠。如果你在構(gòu)建云原生應(yīng)用，那么就需要Service Mesh。

在過去的一年中，Service Mesh已經(jīng)成為云原生技術(shù)棧里的一個(gè)關(guān)鍵組件。很多擁有高負(fù)載業(yè)務(wù)流量的公司都在他們的生產(chǎn)應(yīng)用里加入了Service Mesh，如PayPal、Lyft、Ticketmaster和Credit Karma等。今年一月份，Service Mesh組件Linkerd成為CNCF（Cloud Native Computing Foundation）的官方項(xiàng)目。不過話說回來，Service Mesh到底是什么？為什么它突然間變得如此重要？

在這篇文章里，我將給出Service Mesh的定義，并追溯過去十年間Service Mesh在應(yīng)用架構(gòu)中的演變過程。我會(huì)解釋Service Mesh與API網(wǎng)關(guān)、邊緣代理（Edge Proxy）和企業(yè)服務(wù)總線之間的區(qū)別。最后，我會(huì)描述Service Mesh將何去何從以及我們可以作何期待。

什么是Service Mesh？

Service Mesh是一個(gè)基礎(chǔ)設(shè)施層，用于處理服務(wù)間通信。云原生應(yīng)用有著復(fù)雜的服務(wù)拓?fù)洌琒ervice Mesh保證請(qǐng)求可以在這些拓?fù)渲锌煽康卮┧蟆Ｔ趯?shí)際應(yīng)用當(dāng)中，Service Mesh通常是由一系列輕量級(jí)的網(wǎng)絡(luò)代理組成的，它們與應(yīng)用程序部署在一起，但應(yīng)用程序不需要知道它們的存在。

隨著云原生應(yīng)用的崛起，Service Mesh逐漸成為一個(gè)獨(dú)立的基礎(chǔ)設(shè)施層。在云原生模型里，一個(gè)應(yīng)用可以由數(shù)百個(gè)服務(wù)組成，每個(gè)服務(wù)可能有數(shù)千個(gè)實(shí)例，而每個(gè)實(shí)例可能會(huì)持續(xù)地發(fā)生變化。服務(wù)間通信不僅異常復(fù)雜，而且也是運(yùn)行時(shí)行為的基礎(chǔ)。管理好服務(wù)間通信對(duì)于保證端到端的性能和可靠性來說是非常重要的。

Service Mesh是一種網(wǎng)絡(luò)模型嗎？

Service Mesh實(shí)際上就是處于TCP/IP之上的一個(gè)抽象層，它假設(shè)底層的L3/L4網(wǎng)絡(luò)能夠點(diǎn)對(duì)點(diǎn)地傳輸字節(jié)（當(dāng)然，它也假設(shè)網(wǎng)絡(luò)環(huán)境是不可靠的，所以Service Mesh必須具備處理網(wǎng)絡(luò)故障的能力）。

從某種程度上說，Service Mesh有點(diǎn)類似TCP/IP。TCP對(duì)網(wǎng)絡(luò)端點(diǎn)間傳輸字節(jié)的機(jī)制進(jìn)行了抽象，而Service Mesh則是對(duì)服務(wù)節(jié)點(diǎn)間請(qǐng)求的路由機(jī)制進(jìn)行了抽象。Service Mesh不關(guān)心消息體是什么，也不關(guān)心它們是如何編碼的。應(yīng)用程序的目標(biāo)是“將某些東西從A傳送到B”，而Service Mesh所要做的就是實(shí)現(xiàn)這個(gè)目標(biāo)，并處理傳送過程中可能出現(xiàn)的任何故障。

與TCP不同的是，Service Mesh有著更高的目標(biāo)：為應(yīng)用運(yùn)行時(shí)提供統(tǒng)一的、應(yīng)用層面的可見性和可控性。Service Mesh將服務(wù)間通信從底層的基礎(chǔ)設(shè)施中分離出來，讓它成為整個(gè)生態(tài)系統(tǒng)的一等公民——它因此可以被監(jiān)控、托管和控制。

Service Mesh可以做什么？

在云原生應(yīng)用中傳輸服務(wù)請(qǐng)求是一項(xiàng)非常復(fù)雜的任務(wù)。以Linkerd為例，它使用了一系列強(qiáng)大的技術(shù)來管理這種復(fù)雜性：回路斷路器、負(fù)載均衡、延遲感知、最終一致性服務(wù)發(fā)現(xiàn)、重試和超時(shí)。這些技術(shù)需要組合在一起，并互相協(xié)調(diào)，它們與環(huán)境之間的交互也非常微妙。

舉個(gè)例子，當(dāng)一個(gè)請(qǐng)求流經(jīng)Linkerd時(shí)，會(huì)發(fā)生如下的一系列事件。

Linkerd根據(jù)動(dòng)態(tài)路由規(guī)則確定請(qǐng)求是發(fā)給哪個(gè)服務(wù)的，比如是發(fā)給生產(chǎn)環(huán)境里的服務(wù)還是發(fā)給staging環(huán)境里的服務(wù)？是發(fā)給本地?cái)?shù)據(jù)中心的服務(wù)還是發(fā)給云端的服務(wù)？是發(fā)給最新版本的服務(wù)還是發(fā)給舊版本的服務(wù)？這些路由規(guī)則可以動(dòng)態(tài)配置，可以應(yīng)用在全局的流量上，也可以應(yīng)用在部分流量上。在確定了請(qǐng)求的目標(biāo)服務(wù)后，Linkerd從服務(wù)發(fā)現(xiàn)端點(diǎn)獲取相應(yīng)的服務(wù)實(shí)例。如果服務(wù)實(shí)例的信息出現(xiàn)了偏差，Linkerd需要決定哪個(gè)信息來源更值得信任。Linkerd基于某些因素（比如最近處理請(qǐng)求的延遲情況）選擇更有可能快速返回響應(yīng)的實(shí)例。Linkerd向選中的實(shí)例發(fā)送請(qǐng)求，并把延遲情況和響應(yīng)類型記錄下來。如果選中的實(shí)例發(fā)生宕機(jī)、沒有響應(yīng)或無法處理請(qǐng)求，Linkerd就把請(qǐng)求發(fā)給另一個(gè)實(shí)例（前提是請(qǐng)求必須是冪等的）。如果一個(gè)實(shí)例持續(xù)返回錯(cuò)誤，Linkerd就會(huì)將其從負(fù)載均衡池中移除，并在稍后定時(shí)重試（這個(gè)實(shí)例有可能只是臨時(shí)發(fā)生故障）。如果請(qǐng)求超時(shí)，Linkerd會(huì)主動(dòng)放棄請(qǐng)求，不會(huì)進(jìn)行額外的重試。Linkerd以度量指標(biāo)和分布式日志的方式記錄上述各種行為，然后將度量指標(biāo)發(fā)送給中心度量指標(biāo)系統(tǒng)。

除此之外，Linkerd還能發(fā)起和終止TLS、執(zhí)行協(xié)議升級(jí)、動(dòng)態(tài)調(diào)整流量、在數(shù)據(jù)中心之間進(jìn)行失效備援。

Linkerd的這些特性可以保證局部的彈性和應(yīng)用層面的彈性。大規(guī)模分布式系統(tǒng)有一個(gè)共性：局部故障累積到一定程度就會(huì)造成系統(tǒng)層面的災(zāi)難。Service Mesh的作用就是在底層系統(tǒng)的負(fù)載達(dá)到上限之前通過分散流量和快速失效來防止這些故障破壞到整個(gè)系統(tǒng)。

為什么我們需要Service Mesh？

Service Mesh并非新出現(xiàn)的功能。一直以來，Web應(yīng)用程序需要自己管理復(fù)雜的服務(wù)間通信，從過去十多年間應(yīng)用程序的演化就可以看到Service Mesh的影子。

2000年左右的中型Web應(yīng)用一般使用了三層模型：應(yīng)用邏輯層、Web服務(wù)邏輯層和存儲(chǔ)邏輯層。層與層之間的交互雖然也不算簡單，但復(fù)雜性是很有限的，畢竟一個(gè)請(qǐng)求最多只需要兩個(gè)跳轉(zhuǎn)。雖然這里不存在“網(wǎng)格”，但仍然存在跳轉(zhuǎn)通信邏輯。

隨著規(guī)模的增長，這種架構(gòu)就顯得力不從心了。像Google、Netflix、Twitter這樣的公司面臨著大規(guī)模流量的挑戰(zhàn)，他們實(shí)現(xiàn)了一種高效的解決方案，也就是云原生應(yīng)用的前身：應(yīng)用層被拆分為多個(gè)服務(wù)（也叫作微服務(wù)），這個(gè)時(shí)候?qū)泳妥兂闪艘环N拓?fù)浣Y(jié)構(gòu)。這樣的系統(tǒng)需要一個(gè)通用的通信層，以一個(gè)“富客戶端”包的形式存在，如Twitter的Finagle、Netflix的Hystrix和Google的Stubby。

一般來說，像Finagle、Stubby和Hystrix這樣的包就是最初的Service Mesh。云原生模型在原先的微服務(wù)模型中加入了兩個(gè)額外的元素：容器（比如Docker）和編排層（如Kubernetes）。容器提供了資源隔離和依賴管理，編排層對(duì)底層的硬件進(jìn)行抽象池化。

這三個(gè)組件讓應(yīng)用程序在云環(huán)境中具備了伸縮能力和處理局部故障的能力。但隨著服務(wù)和實(shí)例的數(shù)量增長，編排層需要無時(shí)不刻地調(diào)度實(shí)例，請(qǐng)求在服務(wù)拓?fù)溟g穿梭的路線也變得異常復(fù)雜，再加上可以使用任意語言來開發(fā)不同的服務(wù)，所以之前那種“富客戶端”包的方式就行不通了。

這種復(fù)雜性和迫切性催生了服務(wù)間通信層的出現(xiàn)，這個(gè)層既不會(huì)與應(yīng)用程序的代碼耦合，又能捕捉到底層環(huán)境高度動(dòng)態(tài)的特點(diǎn)，它就是Service Mesh。

Service Mesh的未來

盡管Service Mesh在云原生系統(tǒng)方面的應(yīng)用已經(jīng)有了快速的增長，但仍然存在巨大的提升空間。無服務(wù)器(Serverless)計(jì)算（如Amazon的Lambda）正好需要Service Mesh的命名和鏈接模型，這讓Service Mesh在云原生生態(tài)系統(tǒng)中的角色得到了彰顯。服務(wù)識(shí)別和訪問策略在云原生環(huán)境中仍顯初級(jí)，而Service Mesh毫無疑問將成為這方面不可或缺的基礎(chǔ)。就像TCP/IP一樣，Service Mesh將在底層基礎(chǔ)設(shè)施這條道上更進(jìn)一步。

結(jié)論

Service Mesh是云原生技術(shù)棧中一個(gè)非常關(guān)鍵的組件。Linkerd項(xiàng)目在啟動(dòng)一年多之后正式成為CNCF的官方項(xiàng)目，并擁有了眾多的貢獻(xiàn)者和用戶。Linkerd的用戶橫跨初創(chuàng)公司（如Monzo）到大規(guī)模的互聯(lián)網(wǎng)公司（如PayPal、Ticketmaster、Credit Karma），再到擁有數(shù)百年歷史的老牌公司（如Houghton Mifflin Harcourt）。

查看英文原文：WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE?