[[326170]]

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

那么到底什么是Service Mesh？

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

有了這樣一個(gè)感性的初步認(rèn)知，我們?cè)賮砜吹降资裁词荢ervice Mesh。

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

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

目前業(yè)界跟微服務(wù)相關(guān)的開發(fā)平臺(tái)和框架更是不勝枚舉：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ò)，就能清晰的知道上述的各個(gè)平臺(tái)、框架屬于技術(shù)脈絡(luò)中的哪個(gè)結(jié)點(diǎn)，其間的關(guān)系也就一目了然。

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

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

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

抽象表示如下：

時(shí)代1：原始通信時(shí)代

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

時(shí)代2：TCP時(shí)代

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

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

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

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

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

時(shí)代5：第一代Service Mesh

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

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

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

如果我們從一個(gè)全局視角來看，就會(huì)得到如下部署圖：

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

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

時(shí)代6：第二代Service Mesh

第一代Service Mesh由一系列獨(dú)立運(yùn)行的單機(jī)代理服務(wù)構(gòu)成，為了提供統(tǒng)一的上層運(yùn)維入口，演化出了集中式的控制面板，所有的單機(jī)代理組件通過和控制面板交互進(jìn)行網(wǎng)絡(luò)拓?fù)洳呗缘母潞蛦螜C(jī)數(shù)據(jù)的匯報(bào)。這就是以Istio為代表的第二代Service Mesh。

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

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

現(xiàn)在，我們?cè)倩剡^頭來看Buoyant的CEO William Morgan，也就是Service Mesh這個(gè)詞的發(fā)明人，對(duì)Service Mesh的定義：

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

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

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

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

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

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

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

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