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

在過去的一年中，Service Mesh已經(jīng)成為云原生技術(shù)棧里的一個關(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)中的演變過程。我會解釋Service Mesh與API網(wǎng)關(guān)、邊緣代理（Edge Proxy）和企業(yè)服務(wù)總線之間的區(qū)別。最后，我會描述Service Mesh將何去何從以及我們可以作何期待。

什么是Service Mesh？

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

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

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

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

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

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

Service Mesh可以做什么？

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

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

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

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

Linkerd的這些特性可以保證局部的彈性和應(yīng)用層面的彈性。大規(guī)模分布式系統(tǒng)有一個共性：局部故障累積到一定程度就會造成系統(tǒng)層面的災(zāi)難。Service Mesh的作用就是在底層系統(tǒng)的負(fù)載達(dá)到上限之前通過分散流量和快速失效來防止這些故障破壞到整個系統(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ù)邏輯層和存儲邏輯層。層與層之間的交互雖然也不算簡單，但復(fù)雜性是很有限的，畢竟一個請求最多只需要兩個跳轉(zhuǎn)。雖然這里不存在“網(wǎng)格”，但仍然存在跳轉(zhuǎn)通信邏輯。

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

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

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

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

Service Mesh的未來

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

結(jié)論

Service Mesh是云原生技術(shù)棧中一個非常關(guān)鍵的組件。Linkerd項(xià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?