原文：Pattern: Service Mesh

作者：Phil Cal?ado

翻譯：雁驚寒

原文：Pattern: Service Mesh

作者：Phil Cal?ado

翻譯：雁驚寒

摘要：本文由簡(jiǎn)到難地介紹了分布式系統(tǒng)到服務(wù)網(wǎng)格的演化過程，從而讓讀者對(duì)服務(wù)網(wǎng)格有一個(gè)感性的認(rèn)識(shí)。以下是譯文。

自從幾十年前第一次引入分布式系統(tǒng)這個(gè)概念以來，出現(xiàn)了很多原來根本想象不到的分布式系統(tǒng)使用案例，但同時(shí)也引入了各種各樣的新問題。

當(dāng)這些系統(tǒng)還是比較少比較簡(jiǎn)單的時(shí)候，工程師可以通過減少遠(yuǎn)程交互的次數(shù)來解決復(fù)雜性問題。處理分布式問題最安全的方法是盡可能避免遠(yuǎn)程交互，雖然這可能意味著要在多個(gè)系統(tǒng)上存放重復(fù)的邏輯和數(shù)據(jù)。

行業(yè)上的需求推動(dòng)著我們前進(jìn)的步伐，分布式系統(tǒng)的組成從幾個(gè)大型的中央電腦發(fā)展成為數(shù)以千計(jì)的小型服務(wù)。在這個(gè)新的世界里，我們必須走出困境，應(yīng)對(duì)新的挑戰(zhàn)和開放性問題。首先，具體問題具體分析，針對(duì)某個(gè)問題給出有針對(duì)性的解決辦法，然后再提供更先進(jìn)更復(fù)雜的解決方案。隨著我們對(duì)問題領(lǐng)域越來越熟悉、提出的解決辦法越來越好，我們開始將一些最常見的需求總結(jié)歸納為模式、庫(kù)，以及最終的平臺(tái)。

當(dāng)我們第一次將電腦聯(lián)網(wǎng)時(shí)，發(fā)生了什么

由于人們首先想到的是讓兩臺(tái)或多臺(tái)電腦相互通訊，因此，他們構(gòu)思出了這樣的東西：

互相之間可以通訊的兩個(gè)服務(wù)可以滿足最終用戶的一些需求。但這個(gè)示意圖顯然過于簡(jiǎn)單了，缺少了包括通過代碼操作的字節(jié)轉(zhuǎn)換和在線路上收發(fā)的電信號(hào)轉(zhuǎn)換在內(nèi)的多個(gè)層。雖然，一定程度上的抽象對(duì)于我們的討論是必需的，但還是讓我們來添加網(wǎng)絡(luò)協(xié)議棧組件以增加一點(diǎn)細(xì)節(jié)內(nèi)容吧：

展開全文

上述這個(gè)修改過的模型自20世紀(jì)50年代以來一直使用至今。一開始，計(jì)算機(jī)很稀少，也很昂貴，所以兩個(gè)節(jié)點(diǎn)之間的每個(gè)環(huán)節(jié)都被精心制作和維護(hù)。隨著計(jì)算機(jī)變得越來越便宜，連接的數(shù)量和數(shù)據(jù)量大幅增加。隨著人們?cè)絹碓揭蕾嚲W(wǎng)絡(luò)系統(tǒng)，工程師們需要保證他們構(gòu)建的軟件能夠達(dá)到用戶所要求的服務(wù)質(zhì)量。

當(dāng)然，還有許多問題急需解決以達(dá)到用戶要求的服務(wù)質(zhì)量水平。人們需要找到解決方案讓機(jī)器互相發(fā)現(xiàn)、通過同一條線路同時(shí)處理多個(gè)連接、允許機(jī)器在非直連的情況下互相通信、通過網(wǎng)絡(luò)對(duì)數(shù)據(jù)包進(jìn)行路由、加密流量等等。

在這其中，有一種叫做流量控制的東西，下面我們以此為例。流量控制是一種防止一臺(tái)服務(wù)器發(fā)送的數(shù)據(jù)包超過下游服務(wù)器可以承受上限的機(jī)制。這是必要的，因?yàn)樵谝粋€(gè)聯(lián)網(wǎng)的系統(tǒng)中，你至少有兩個(gè)不同的、獨(dú)立的計(jì)算機(jī)，彼此之間互不了解。 計(jì)算機(jī)A以給定的速率向計(jì)算機(jī)B發(fā)送字節(jié)，但不能保證B可以連續(xù)地以足夠快的速度來處理接收到的字節(jié)。例如，B可能正在忙于并行運(yùn)行其他任務(wù)，或者數(shù)據(jù)包可能無序到達(dá)，并且B可能被阻塞以等待本應(yīng)該第一個(gè)到達(dá)的數(shù)據(jù)包。這意味著A不僅不知道B的預(yù)期性能，而且還可能讓事情變得更糟，因?yàn)檫@可能會(huì)讓B過載，B現(xiàn)在必須對(duì)所有這些傳入的數(shù)據(jù)包進(jìn)行排隊(duì)處理。

一段時(shí)間以來，大家寄希望于建立網(wǎng)絡(luò)服務(wù)和應(yīng)用程序的開發(fā)者能夠通過編寫代碼來解決上面提出的挑戰(zhàn)。在我們的這個(gè)流程控制示例中，應(yīng)用程序本身必須包含某種邏輯來確保服務(wù)不會(huì)因?yàn)閿?shù)據(jù)包而過載。這種重聯(lián)網(wǎng)的邏輯與業(yè)務(wù)邏輯一樣重要。在我們的抽象示意圖中，它是這樣的：

幸運(yùn)的是，技術(shù)的發(fā)展日新月異，隨著像TCP/IP這樣的標(biāo)準(zhǔn)的橫空出世，流量控制和許多其他問題的解決方案被融入進(jìn)了網(wǎng)絡(luò)協(xié)議棧本身。這意味著這些流量控制代碼仍然存在，但已經(jīng)從應(yīng)用程序轉(zhuǎn)移到了操作系統(tǒng)提供的底層網(wǎng)絡(luò)層中：

這個(gè)模型相當(dāng)?shù)爻晒?。幾乎任何一個(gè)組織都能夠使用商業(yè)操作系統(tǒng)附帶的TCP/IP協(xié)議棧來驅(qū)動(dòng)他們的業(yè)務(wù)，即使有高性能和高可靠性的要求。

當(dāng)我們第一次使用微服務(wù)時(shí)，發(fā)生了什么

多年以來，計(jì)算機(jī)變得越來越便宜，并且到處可見，而上面提到的網(wǎng)絡(luò)協(xié)議棧已被證明是用于可靠連接系統(tǒng)的事實(shí)上的工具集。隨著節(jié)點(diǎn)和穩(wěn)定連接的數(shù)量越來越多，行業(yè)中出現(xiàn)了各種各樣的網(wǎng)絡(luò)系統(tǒng)，從細(xì)粒度的分布式代理和對(duì)象到由較大但重分布式組件組成的面向服務(wù)的架構(gòu)。

這樣的分布式系統(tǒng)給我們帶來了很多有趣的更高級(jí)別的案例和好處，但也出現(xiàn)了幾個(gè)難題。其中一些是全新的，但其他的只是我們?cè)谟懻撛季W(wǎng)絡(luò)時(shí)遇到難題的更高版本而已。

在90年代，Peter Deutsch和他在Sun公司的同事工程師們撰寫了“分布式計(jì)算的八大錯(cuò)誤”一文，其中列出了人們?cè)谑褂梅植际较到y(tǒng)時(shí)通常會(huì)做出的一些假設(shè)。Peter認(rèn)為，這些假設(shè)在更原始的網(wǎng)絡(luò)架構(gòu)或理論模型中可能是真實(shí)的，但在現(xiàn)代世界中是不成立的：

大家把上面這個(gè)列表斥為“謬論”，因此，工程師們不能忽視這些問題，必須明確地處理這些問題。

為了處理更復(fù)雜的問題，需要轉(zhuǎn)向更加分散的系統(tǒng)（我們通常所說的微服務(wù)架構(gòu)），這在可操作性方面提出了新的要求。 之前我們已經(jīng)詳細(xì)討論了一些內(nèi)容，但下面則列出了一個(gè)必須要處理的東西：

因此，盡管數(shù)十年前開發(fā)的TCP/IP協(xié)議棧和通用網(wǎng)絡(luò)模型仍然是計(jì)算機(jī)之間相互通訊的有力工具，但更復(fù)雜的架構(gòu)引入了另一個(gè)層面的要求，這再次需要由在這方面工作的工程師來實(shí)現(xiàn)。

例如，對(duì)于服務(wù)發(fā)現(xiàn)和斷路器，這兩種技術(shù)已用于解決上面列出的幾個(gè)彈性和分布式問題。

歷史往往會(huì)重演，第一批基于微服務(wù)構(gòu)建的系統(tǒng)遵循了與前幾代聯(lián)網(wǎng)計(jì)算機(jī)類似的策略。這意味著落實(shí)上述需求的責(zé)任落在了編寫服務(wù)的工程師身上。

服務(wù)發(fā)現(xiàn)是在滿足給定查詢條件的情況下自動(dòng)查找服務(wù)實(shí)例的過程，例如，一個(gè)名叫Teams的服務(wù)需要找到一個(gè)名為Players的服務(wù)實(shí)例，其中該實(shí)例的environment屬性設(shè)置為production。你將調(diào)用一些服務(wù)發(fā)現(xiàn)進(jìn)程，它們會(huì)返回一個(gè)滿足條件的服務(wù)列表。對(duì)于更集中的架構(gòu)而言，這是一個(gè)非常簡(jiǎn)單的任務(wù)，可以通常使用DNS、負(fù)載均衡器和一些端口號(hào)的約定（例如，所有服務(wù)將HTTP服務(wù)器綁定到8080端口）來實(shí)現(xiàn)。而在更分散的環(huán)境中，任務(wù)開始變得越來越復(fù)雜，以前可以通過盲目信任DNS來查找依賴關(guān)系的服務(wù)現(xiàn)在必須要處理諸如客戶端負(fù)載均衡、多種不同環(huán)境、地理位置上分散的服務(wù)器等問題。如果之前只需要一行代碼來解析主機(jī)名，那么現(xiàn)在你的服務(wù)則需要很多行代碼來處理由分布式引入的各種問題。

斷路器是由Michael Nygard在其編寫的“Release It”一書中引入的模式。我非常喜歡Martin Fowler對(duì)該模式的一些總結(jié)：

斷路器背后的基本思路非常簡(jiǎn)單。將一個(gè)受保護(hù)的函數(shù)調(diào)用包含在用于監(jiān)視故障的斷路器對(duì)象中。一旦故障達(dá)到一定閾值，則斷路器跳閘，并且對(duì)斷路器的所有后續(xù)調(diào)用都將返回錯(cuò)誤，并完全不接受對(duì)受保護(hù)函數(shù)的調(diào)用。通常，如果斷路器發(fā)生跳閘，你還需要某種監(jiān)控警報(bào)。

斷路器背后的基本思路非常簡(jiǎn)單。將一個(gè)受保護(hù)的函數(shù)調(diào)用包含在用于監(jiān)視故障的斷路器對(duì)象中。一旦故障達(dá)到一定閾值，則斷路器跳閘，并且對(duì)斷路器的所有后續(xù)調(diào)用都將返回錯(cuò)誤，并完全不接受對(duì)受保護(hù)函數(shù)的調(diào)用。通常，如果斷路器發(fā)生跳閘，你還需要某種監(jiān)控警報(bào)。

這些都是非常簡(jiǎn)單的設(shè)備，它們能為服務(wù)之間的交互提供更多的可靠性。然而，跟其他的東西一樣，隨著分布式水平的提高，它們也會(huì)變得越來越復(fù)雜。系統(tǒng)發(fā)生錯(cuò)誤的概率隨著分布式水平的提高呈指數(shù)級(jí)增長(zhǎng)，因此即使簡(jiǎn)單的事情，如“如果斷路器跳閘，則監(jiān)控警報(bào)”，也就不那么簡(jiǎn)單了。一個(gè)組件中的一個(gè)故障可能會(huì)在許多客戶端和客戶端的客戶端上產(chǎn)生連鎖反應(yīng)，從而觸發(fā)數(shù)千個(gè)電路同時(shí)跳閘。而且，以前可能只需幾行代碼就能處理某個(gè)問題，而現(xiàn)在需要編寫大量的代碼才能處理這些只存在于這個(gè)新世界的問題。

事實(shí)上，上面舉的兩個(gè)例子可能很難正確實(shí)現(xiàn)，這也是大型復(fù)雜庫(kù)，如Twitter的Finagle和Facebook的Proxygen，深受歡迎的原因，它們能避免在每個(gè)服務(wù)中重寫相同的邏輯。

大多數(shù)采用微服務(wù)架構(gòu)的組織都遵循了上面提到的那個(gè)模型，如Netflix、Twitter和SoundCloud。隨著系統(tǒng)中服務(wù)數(shù)量的增加，他們發(fā)現(xiàn)了這種方法存在著各種弊端。

即使是使用像Finagle這樣的庫(kù)，項(xiàng)目團(tuán)隊(duì)仍然需要投入大量的時(shí)間來將這個(gè)庫(kù)與系統(tǒng)的其他部分結(jié)合起來，這是一個(gè)代價(jià)非常高的難題。根據(jù)我在SoundCloud和DigitalOcean的經(jīng)驗(yàn)，我估計(jì)在100-250人規(guī)模的工程師組織中，需要有1/10的人員來構(gòu)建模型。有時(shí)，這種代價(jià)很容易看到，因?yàn)楣こ處煴环峙涞搅藢ｉT構(gòu)建工具的團(tuán)隊(duì)中，但是更多的時(shí)候，這種代價(jià)是看不見的，因?yàn)樗憩F(xiàn)為在產(chǎn)品研發(fā)上需要花費(fèi)更多的時(shí)間。

第二個(gè)問題是，上面的設(shè)置限制了可用于微服務(wù)的工具、運(yùn)行時(shí)和語言。用于微服務(wù)的庫(kù)通常是為特定平臺(tái)編寫的，無論是編程語言還是像JVM這樣的運(yùn)行時(shí)。如果開發(fā)團(tuán)隊(duì)使用了庫(kù)不支持的平臺(tái)，那么通常需要將代碼移植到新的平臺(tái)。這浪費(fèi)了本來就很短的工程時(shí)間。工程師沒辦法再把重點(diǎn)放在核心業(yè)務(wù)和產(chǎn)品上，而是不得不花時(shí)間來構(gòu)建工具和基礎(chǔ)架構(gòu)。那就是為什么一些像SoundCloud和DigitalOcean這樣的中型企業(yè)認(rèn)為其內(nèi)部服務(wù)只需支持一個(gè)平臺(tái)，分別是Scala或者Go。

這個(gè)模型最后一個(gè)值得討論的問題是管理方面的問題。庫(kù)模型可能對(duì)解決微服務(wù)架構(gòu)需求所需功能的實(shí)現(xiàn)進(jìn)行抽象，但它本身仍然是需要維護(hù)的組件。必須要確保數(shù)千個(gè)服務(wù)實(shí)例所使用的庫(kù)的版本是相同的或至少是兼容的，并且每次更新都意味著要集成、測(cè)試和重新部署所有服務(wù)，即使服務(wù)本身沒有任何改變。

下一個(gè)邏輯上的步驟

類似于我們?cè)诰W(wǎng)絡(luò)協(xié)議棧中看到的那樣，大規(guī)模分布式服務(wù)所需的功能應(yīng)該放到底層的平臺(tái)中。

人們使用高級(jí)協(xié)議（如HTTP）編寫非常復(fù)雜的應(yīng)用程序和服務(wù)，甚至無需考慮TCP是如何控制網(wǎng)絡(luò)上的數(shù)據(jù)包的。這種情況就是微服務(wù)所需要的，那些從事服務(wù)開發(fā)工作的工程師可以專注于業(yè)務(wù)邏輯的開發(fā)，從而避免浪費(fèi)時(shí)間去編寫自己的服務(wù)基礎(chǔ)設(shè)施代碼或管理整個(gè)系統(tǒng)的庫(kù)和框架。

將這個(gè)想法結(jié)合到我們的圖表中，我們可以得到如下所示的內(nèi)容：

不幸的是，通過改變網(wǎng)絡(luò)協(xié)議棧來添加這個(gè)層并不是一個(gè)可行的任務(wù)。許多人的解決方案是通過一組代理來實(shí)現(xiàn)。這個(gè)的想法是，服務(wù)不會(huì)直接連接到它的下游，而是讓所有的流量都將通過一個(gè)小小的軟件來透明地添加所需功能。

在這個(gè)領(lǐng)域第一個(gè)有記載的進(jìn)步使用了邊三輪（sidecars）這個(gè)概念。“邊三輪”是一個(gè)輔助進(jìn)程，它與主應(yīng)用程序一起運(yùn)行，并為其提供額外的功能。在2013年，Airbnb寫了一篇有關(guān)Synapse和Nerve的文章，這是“邊三輪”的一個(gè)開源實(shí)現(xiàn)。一年后，Netflix推出了Prana，專門用于讓非JVM應(yīng)用程序從他們的NetflixOSS生態(tài)系統(tǒng)中受益。在SoundCloud，我們構(gòu)建了可以讓遺留的Ruby程序使用我們?yōu)镴VM微服務(wù)構(gòu)建的基礎(chǔ)設(shè)施的“邊三輪”。

雖然有這么幾個(gè)開源的代理實(shí)現(xiàn)，但它們往往被設(shè)計(jì)為需要與特定的基礎(chǔ)架構(gòu)組件配合使用。例如，在服務(wù)發(fā)現(xiàn)方面，Airbnb的Nerve和Synapse假設(shè)了服務(wù)是在Zookeeper中注冊(cè)，而對(duì)于Prana，則應(yīng)該使用Netflix自己的Eureka服務(wù)注冊(cè)表 。

隨著微服務(wù)架構(gòu)的日益普及，我們最近看到了一波新的代理浪潮，它們足以靈活地適應(yīng)不同的基礎(chǔ)設(shè)施組件和偏好。 這個(gè)領(lǐng)域中第一個(gè)廣為人知的系統(tǒng)是Linkerd，它由Buoyant創(chuàng)建出來，源于他們的工程師先前在Twitter微服務(wù)平臺(tái)上的工作。很快，Lyft的工程團(tuán)隊(duì)宣布了Envoy的發(fā)布，它遵循了類似的原則。

Service Mesh

在這種模式中，每個(gè)服務(wù)都配備了一個(gè)代理“邊三輪”。由于這些服務(wù)只能通過代理“邊三輪”進(jìn)行通信，我們最終會(huì)得到類似于下圖的部署方案：

Buoyant的首席執(zhí)行官威廉·摩根表示，代理之間的互連形成了服務(wù)網(wǎng)格。 2017年初，威廉寫下了這個(gè)平臺(tái)的定義，并稱它為服務(wù)網(wǎng)格：

服務(wù)網(wǎng)格是用于處理服務(wù)到服務(wù)通信的專用基礎(chǔ)設(shè)施層。它負(fù)責(zé)通過復(fù)雜的服務(wù)拓?fù)鋪砜煽康貍鬟f請(qǐng)求。實(shí)際上，服務(wù)網(wǎng)格通常被實(shí)現(xiàn)為與應(yīng)用程序代碼一起部署的輕量級(jí)網(wǎng)絡(luò)代理矩陣，并且它不會(huì)被應(yīng)用程序所感知。

服務(wù)網(wǎng)格是用于處理服務(wù)到服務(wù)通信的專用基礎(chǔ)設(shè)施層。它負(fù)責(zé)通過復(fù)雜的服務(wù)拓?fù)鋪砜煽康貍鬟f請(qǐng)求。實(shí)際上，服務(wù)網(wǎng)格通常被實(shí)現(xiàn)為與應(yīng)用程序代碼一起部署的輕量級(jí)網(wǎng)絡(luò)代理矩陣，并且它不會(huì)被應(yīng)用程序所感知。

這個(gè)定義最強(qiáng)大的地方可能就在于它不再把代理看作是孤立的組件，并承認(rèn)它們本身就是一個(gè)有價(jià)值的網(wǎng)絡(luò)。

隨著微服務(wù)部署被遷移到更為復(fù)雜的運(yùn)行時(shí)中去，如Kubernetes和Mesos，人們開始使用一些平臺(tái)上的工具來實(shí)現(xiàn)網(wǎng)格網(wǎng)絡(luò)這一想法。他們實(shí)現(xiàn)的網(wǎng)絡(luò)正從互相之間隔離的獨(dú)立代理，轉(zhuǎn)移到一個(gè)合適的并且有點(diǎn)集中的控制面上來。

來看看這個(gè)鳥瞰圖，實(shí)際的服務(wù)流量仍然直接從代理流向代理，但是控制面知道每個(gè)代理實(shí)例。控制面使得代理能夠?qū)崿F(xiàn)諸如訪問控制和度量收集這樣的功能，但這需要它們之間進(jìn)行合作：

最近公布的Istio項(xiàng)目是這類系統(tǒng)中最著名的例子。

完全理解服務(wù)網(wǎng)格在更大規(guī)模系統(tǒng)中的影響還為時(shí)尚早，但這種架構(gòu)已經(jīng)凸顯出兩大優(yōu)勢(shì)。首先，不必編寫針對(duì)微服務(wù)架構(gòu)的定制化軟件，即可讓許多小公司擁有以前只有大型企業(yè)才能擁有的功能，從而創(chuàng)建出各種有趣的案例。第二，這種架構(gòu)可以讓我們最終實(shí)現(xiàn)使用最佳工具或語言進(jìn)行工作的夢(mèng)想，并且不必?fù)?dān)心每個(gè)平臺(tái)的庫(kù)和模式的可用性。