什么是Service Mesh？Service Mesh的演化形態(tài)

時間：2020-05-05 07:27:01

關(guān)鍵字： MESH SERVICE 分布式組件

手機看文章

掃描二維碼
隨時隨地手機看文章

[導(dǎo)讀] Service Mesh作為下一代微服務(wù)技術(shù)的代名詞，初出茅廬卻深得人心一鳴驚人，大有一統(tǒng)微服務(wù)時代的趨勢。那么，到底什么是Service Mesh？一言以蔽之：Servic

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的文章

這里借用文章的脈絡(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組件可以單獨升級。