原文：Pattern: Service Mesh

作者：Phil Cal?ado

翻譯：雁驚寒

原文：Pattern: Service Mesh

作者：Phil Cal?ado

翻譯：雁驚寒

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

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

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

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

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

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

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

展開全文

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

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

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

一段時間以來，大家寄希望于建立網(wǎng)絡(luò)服務(wù)和應(yīng)用程序的開發(fā)者能夠通過編寫代碼來解決上面提出的挑戰(zhàn)。在我們的這個流程控制示例中，應(yīng)用程序本身必須包含某種邏輯來確保服務(wù)不會因為數(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ò)層中：

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

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

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

這樣的分布式系統(tǒng)給我們帶來了很多有趣的更高級別的案例和好處，但也出現(xiàn)了幾個難題。其中一些是全新的，但其他的只是我們在討論原始網(wǎng)絡(luò)時遇到難題的更高版本而已。

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

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

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

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

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

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

服務(wù)發(fā)現(xiàn)是在滿足給定查詢條件的情況下自動查找服務(wù)實例的過程，例如，一個名叫Teams的服務(wù)需要找到一個名為Players的服務(wù)實例，其中該實例的environment屬性設(shè)置為production。你將調(diào)用一些服務(wù)發(fā)現(xiàn)進(jìn)程，它們會返回一個滿足條件的服務(wù)列表。對于更集中的架構(gòu)而言，這是一個非常簡單的任務(wù)，可以通常使用DNS、負(fù)載均衡器和一些端口號的約定（例如，所有服務(wù)將HTTP服務(wù)器綁定到8080端口）來實現(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對該模式的一些總結(jié)：

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

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

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

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

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

即使是使用像Finagle這樣的庫，項目團(tuán)隊仍然需要投入大量的時間來將這個庫與系統(tǒng)的其他部分結(jié)合起來，這是一個代價非常高的難題。根據(jù)我在SoundCloud和DigitalOcean的經(jīng)驗，我估計在100-250人規(guī)模的工程師組織中，需要有1/10的人員來構(gòu)建模型。有時，這種代價很容易看到，因為工程師被分配到了專門構(gòu)建工具的團(tuán)隊中，但是更多的時候，這種代價是看不見的，因為它表現(xiàn)為在產(chǎn)品研發(fā)上需要花費更多的時間。

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

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

下一個邏輯上的步驟

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

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

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

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

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

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

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

Service Mesh

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

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

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

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

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

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

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

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

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