[[326170]]

Service Mesh作為下一代微服務(wù)技術(shù)的代名詞，初出茅廬卻深得人心一鳴驚人，大有一統(tǒng)微服務(wù)時代的趨勢。

那么到底什么是Service Mesh？

一言以蔽之：Service Mesh是微服務(wù)時代的TCP協(xié)議。

有了這樣一個感性的初步認知，我們再來看到底什么是Service Mesh。

提到Service Mesh，就不得不提微服務(wù)。根據(jù)維基百科的定義：

微服務(wù)（Microservices）是一種軟件架構(gòu)風格，它是以專注于單一責任與功能的小型功能區(qū)塊（Small Building Blocks）為基礎(chǔ)，利用模塊化的方式組合出復(fù)雜的大型應(yīng)用程序，各功能區(qū)塊使用與語言無關(guān)（Language-Independent/Language agnostic）的API集相互通信。

目前業(yè)界跟微服務(wù)相關(guān)的開發(fā)平臺和框架更是不勝枚舉：Spring Cloud、Service Fabric、Linkerd、Envoy、Istio……

這些紛繁的產(chǎn)品和Sevice Mesh有什么樣的關(guān)聯(lián)？哪些屬于Service Mesh的范疇？

為了理清這些繁復(fù)的產(chǎn)品和概念，我們先來了解下微服務(wù)和Service Mesh技術(shù)的歷史發(fā)展脈絡(luò)。

了解清楚了技術(shù)的主要脈絡(luò)，就能清晰的知道上述的各個平臺、框架屬于技術(shù)脈絡(luò)中的哪個結(jié)點，其間的關(guān)系也就一目了然。

Phil Calçado的文章《Pattern: Service Mesh》，詳細的介紹了從開發(fā)者視角來看，服務(wù)開發(fā)模式和Service Mesh技術(shù)的演化過程，個人認為是非常經(jīng)典的學(xué)習(xí)Service Mesh的資料。

這里借用文章的脈絡(luò)，結(jié)合自己的理解并予以簡化，試圖說清楚ServiceMesh的概念和這項技術(shù)誕生的歷史必然性。

時代0：開發(fā)人員想象中，不同服務(wù)間通信的方式

抽象表示如下：

時代1：原始通信時代

然而現(xiàn)實遠比想象的復(fù)雜，在實際情況中，通信需要底層能夠傳輸字節(jié)碼和電子信號的物理層來完成，在TCP協(xié)議出現(xiàn)之前，服務(wù)需要自己處理網(wǎng)絡(luò)通信所面臨的丟包、亂序、重試等一系列流控問題，因此服務(wù)實現(xiàn)中，除了業(yè)務(wù)邏輯外，還夾雜著對網(wǎng)絡(luò)傳輸問題的處理邏輯。

時代2：TCP時代

為了避免每個服務(wù)都需要自己實現(xiàn)一套相似的網(wǎng)絡(luò)傳輸處理邏輯，TCP協(xié)議出現(xiàn)了，它解決了網(wǎng)絡(luò)傳輸中通用的流量控制問題，將技術(shù)棧下移，從服務(wù)的實現(xiàn)中抽離出來，成為操作系統(tǒng)網(wǎng)絡(luò)層的一部分。

時代3：第一代微服務(wù)

在TCP出現(xiàn)之后，機器之間的網(wǎng)絡(luò)通信不再是一個難題，以GFS/BigTable/MapReduce為代表的分布式系統(tǒng)得以蓬勃發(fā)展。這時，分布式系統(tǒng)特有的通信語義又出現(xiàn)了，如熔斷策略、負載均衡、服務(wù)發(fā)現(xiàn)、認證和授權(quán)、quota限制、trace和監(jiān)控等等，于是服務(wù)根據(jù)業(yè)務(wù)需求來實現(xiàn)一部分所需的通信語義。

時代4：第二代微服務(wù)

為了避免每個服務(wù)都需要自己實現(xiàn)一套分布式系統(tǒng)通信的語義功能，隨著技術(shù)的發(fā)展，一些面向微服務(wù)架構(gòu)的開發(fā)框架出現(xiàn)了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等等，這些框架實現(xiàn)了分布式系統(tǒng)通信需要的各種通用語義功能：如負載均衡和服務(wù)發(fā)現(xiàn)等，因此一定程度上屏蔽了這些通信細節(jié)，使得開發(fā)人員使用較少的框架代碼就能開發(fā)出健壯的分布式系統(tǒng)。

時代5：第一代Service Mesh

第二代微服務(wù)模式看似完美，但開發(fā)人員很快又發(fā)現(xiàn)，它也存在一些本質(zhì)問題：

•  其一，雖然框架本身屏蔽了分布式系統(tǒng)通信的一些通用功能實現(xiàn)細節(jié)，但開發(fā)者卻要花更多精力去掌握和管理復(fù)雜的框架本身，在實際應(yīng)用中，去追蹤和解決框架出現(xiàn)的問題也絕非易事；
•  其二，開發(fā)框架通常只支持一種或幾種特定的語言，回過頭來看文章最開始對微服務(wù)的定義，一個重要的特性就是語言無關(guān)，但那些沒有框架支持的語言編寫的服務(wù)，很難融入面向微服務(wù)的架構(gòu)體系，想因地制宜的用多種語言實現(xiàn)架構(gòu)體系中的不同模塊也很難做到；
•  其三，框架以lib庫的形式和服務(wù)聯(lián)編，復(fù)雜項目依賴時的庫版本兼容問題非常棘手，同時，框架庫的升級也無法對服務(wù)透明，服務(wù)會因為和業(yè)務(wù)無關(guān)的lib庫升級而被迫升級。

因此以Linkerd，Envoy，Ngixmesh為代表的代理模式（邊車模式）應(yīng)運而生，這就是第一代Service Mesh，它將分布式服務(wù)的通信抽象為單獨一層，在這一層中實現(xiàn)負載均衡、服務(wù)發(fā)現(xiàn)、認證授權(quán)、監(jiān)控追蹤、流量控制等分布式系統(tǒng)所需要的功能，作為一個和服務(wù)對等的代理服務(wù)，和服務(wù)部署在一起，接管服務(wù)的流量，通過代理之間的通信間接完成服務(wù)之間的通信請求，這樣上邊所說的三個問題也迎刃而解。

如果我們從一個全局視角來看，就會得到如下部署圖：

如果我們暫時略去服務(wù)，只看Service Mesh的單機組件組成的網(wǎng)絡(luò)：

相信現(xiàn)在，大家已經(jīng)理解何所謂Service Mesh，也就是服務(wù)網(wǎng)格了。它看起來確實就像是一個由若干服務(wù)代理所組成的錯綜復(fù)雜的網(wǎng)格。

時代6：第二代Service Mesh

第一代Service Mesh由一系列獨立運行的單機代理服務(wù)構(gòu)成，為了提供統(tǒng)一的上層運維入口，演化出了集中式的控制面板，所有的單機代理組件通過和控制面板交互進行網(wǎng)絡(luò)拓撲策略的更新和單機數(shù)據(jù)的匯報。這就是以Istio為代表的第二代Service Mesh。

只看單機代理組件（數(shù)據(jù)面板）和控制面板的Service Mesh全局部署視圖如下：

至此，見證了6個時代的變遷，大家一定清楚了Service Mesh技術(shù)到底是什么，以及是如何一步步演化到今天這樣一個形態(tài)。

現(xiàn)在，我們再回過頭來看Buoyant的CEO William Morgan，也就是Service Mesh這個詞的發(fā)明人，對Service Mesh的定義：

服務(wù)網(wǎng)格是一個基礎(chǔ)設(shè)施層，用于處理服務(wù)間通信。云原生應(yīng)用有著復(fù)雜的服務(wù)拓撲，服務(wù)網(wǎng)格保證請求在這些拓撲中可靠地穿梭。在實際應(yīng)用當中，服務(wù)網(wǎng)格通常是由一系列輕量級的網(wǎng)絡(luò)代理組成的，它們與應(yīng)用程序部署在一起，但對應(yīng)用程序透明。

這個定義中，有四個關(guān)鍵詞：

•  基礎(chǔ)設(shè)施層+請求在這些拓撲中可靠穿梭：這兩個詞加起來描述了Service Mesh的定位和功能，是不是似曾相識？沒錯，你一定想到了TCP；
•  網(wǎng)絡(luò)代理：這描述了Service Mesh的實現(xiàn)形態(tài)；
•  對應(yīng)用透明：這描述了Service Mesh的關(guān)鍵特點，正是由于這個特點，Service Mesh能夠解決以Spring Cloud為代表的第二代微服務(wù)框架所面臨的三個本質(zhì)問題。

總結(jié)一下，Service Mesh具有如下優(yōu)點：

•  屏蔽分布式系統(tǒng)通信的復(fù)雜性（負載均衡、服務(wù)發(fā)現(xiàn)、認證授權(quán)、監(jiān)控追蹤、流量控制等等），服務(wù)只用關(guān)注業(yè)務(wù)邏輯；
•  真正的語言無關(guān)，服務(wù)可以用任何語言編寫，只需和Service Mesh通信即可；
•  對應(yīng)用透明，Service Mesh組件可以單獨升級。

當然，Service Mesh目前也面臨一些挑戰(zhàn)：

•  Service Mesh組件以代理模式計算并轉(zhuǎn)發(fā)請求，一定程度上會降低通信系統(tǒng)性能，并增加系統(tǒng)資源開銷；
•  Service Mesh組件接管了網(wǎng)絡(luò)流量，因此服務(wù)的整體穩(wěn)定性依賴于Service Mesh，同時額外引入的大量Service Mesh服務(wù)實例的運維和管理也是一個挑戰(zhàn)；

歷史總是驚人的相似。為了解決端到端的字節(jié)碼通信問題，TCP協(xié)議誕生，讓多機通信變得簡單可靠；微服務(wù)時代，Service Mesh 應(yīng)運而生，屏蔽了分布式系統(tǒng)的諸多復(fù)雜性，讓開發(fā)者可以回歸業(yè)務(wù)，聚焦真正的價值。