[[317278]]

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

那么，到底什么是Service Mesh?

一言以蔽之：Service Mesh是微服務(wù)時(shí)代的TCP協(xié)議。有了這樣一個(gè)感性的初步認(rèn)知，我們再來看到底什么是Service 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ā)平臺和框架更是不勝枚舉：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è)平臺、框架屬于技術(shù)脈絡(luò)中的哪個(gè)結(jié)點(diǎn)，其間的關(guān)系也就一目了然。

Phil Calçado的文章

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

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

抽象表示如下：

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

然而現(xiàn)實(shí)遠(yuǎn)比想象的復(fù)雜，在實(shí)際情況中，通信需要底層能夠傳輸字節(jié)碼和電子信號的物理層來完成，在TCP協(xié)議出現(xiàn)之前，服務(wù)需要自己處理網(wǎng)絡(luò)通信所面臨的丟包、亂序、重試等一系列流控問題，因此服務(wù)實(shí)現(xiàn)中，除了業(yè)務(wù)邏輯外，還夾雜著對網(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ā)框架通常只支持一種或幾種特定的語言，回過頭來看文章最開始對微服務(wù)的定義，一個(gè)重要的特性就是語言無關(guān)，但那些沒有框架支持的語言編寫的服務(wù)，很難融入面向微服務(wù)的架構(gòu)體系，想因地制宜的用多種語言實(shí)現(xiàn)架構(gòu)體系中的不同模塊也很難做到;
• 其三，框架以lib庫的形式和服務(wù)聯(lián)編，復(fù)雜項(xiàng)目依賴時(shí)的庫版本兼容問題非常棘手，同時(shí)，框架庫的升級也無法對服務(wù)透明，服務(wù)會因?yàn)楹蜆I(yè)務(wù)無關(guān)的lib庫升級而被迫升級。

因此以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ù)對等的代理服務(wù)，和服務(wù)部署在一起，接管服務(wù)的流量，通過代理之間的通信間接完成服務(wù)之間的通信請求，這樣上邊所說的三個(gè)問題也迎刃而解。

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

如果我們暫時(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)在，我們再回過頭來看Buoyant的CEO William Morgan，也就是Service Mesh這個(gè)詞的發(fā)明人，對Service Mesh的定義：

服務(wù)網(wǎng)格是一個(gè)基礎(chǔ)設(shè)施層，用于處理服務(wù)間通信。云原生應(yīng)用有著復(fù)雜的服務(wù)拓?fù)洌?wù)網(wǎng)格保證請求在這些拓?fù)渲锌煽康卮┧蟆?/p>

在實(shí)際應(yīng)用當(dāng)中，服務(wù)網(wǎng)格通常是由一系列輕量級的網(wǎng)絡(luò)代理組成的，它們與應(yīng)用程序部署在一起，但對應(yīng)用程序透明。這個(gè)定義中，有四個(gè)關(guān)鍵詞：

• 基礎(chǔ)設(shè)施層+請求在這些拓?fù)渲锌煽看┧螅哼@兩個(gè)詞加起來描述了Service Mesh的定位和功能，是不是似曾相識?沒錯(cuò)，你一定想到了TCP;
• 網(wǎng)絡(luò)代理：這描述了Service Mesh的實(shí)現(xiàn)形態(tài);
• 對應(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通信即可;
• 對應(yīng)用透明，Service Mesh組件可以單獨(dú)升級。

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

• Service Mesh組件以代理模式計(jì)算并轉(zhuǎn)發(fā)請求，一定程度上會降低通信系統(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ī)通信變得簡單可靠;微服務(wù)時(shí)代，Service Mesh應(yīng)運(yùn)而生，屏蔽了分布式系統(tǒng)的諸多復(fù)雜性，讓開發(fā)者可以回歸業(yè)務(wù)，聚焦真正的價(jià)值。