[[317278]]

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

那么，到底什么是Service Mesh?

一言以蔽之：Service Mesh是微服務時代的TCP協(xié)議。有了這樣一個感性的初步認知，我們再來看到底什么是Service Mesh。

提到Service Mesh，就不得不提微服務。根據(jù)維基百科的定義：微服務(Microservices)是一種軟件架構風格，它是以專注于單一責任與功能的小型功能區(qū)塊(Small Building Blocks)為基礎，利用模塊化的方式組合出復雜的大型應用程序，各功能區(qū)塊使用與語言無關(Language-Independent /Language agnostic)的API集相互通信。

目前業(yè)界跟微服務相關的開發(fā)平臺和框架更是不勝枚舉：Spring Cloud、Service Fabric、Linkerd、Envoy、Istio等等這些紛繁的產品和Sevice Mesh有什么樣的關聯(lián)?哪些屬于Service Mesh的范疇?

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

了解清楚了技術的主要脈絡，就能清晰的知道上述的各個平臺、框架屬于技術脈絡中的哪個結點，其間的關系也就一目了然。

Phil Calçado的文章

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

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

抽象表示如下：

時代1：原始通信時代

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

時代2：TCP時代

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

時代3：第一代微服務

在TCP出現(xiàn)之后，機器之間的網(wǎng)絡通信不再是一個難題，以GFS/BigTable/MapReduce為代表的分布式系統(tǒng)得以蓬勃發(fā)展。

這時，分布式系統(tǒng)特有的通信語義又出現(xiàn)了，如熔斷策略、負載均衡、服務發(fā)現(xiàn)、認證和授權、quota限制、trace和監(jiān)控等等，于是服務根據(jù)業(yè)務需求來實現(xiàn)一部分所需的通信語義。

時代4：第二代微服務

為了避免每個服務都需要自己實現(xiàn)一套分布式系統(tǒng)通信的語義功能，隨著技術的發(fā)展，一些面向微服務架構的開發(fā)框架出現(xiàn)了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等等。

這些框架實現(xiàn)了分布式系統(tǒng)通信需要的各種通用語義功能：如負載均衡和服務發(fā)現(xiàn)等，因此一定程度上屏蔽了這些通信細節(jié)，使得開發(fā)人員使用較少的框架代碼就能開發(fā)出健壯的分布式系統(tǒng)。

時代5：第一代Service Mesh

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

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

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

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

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

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

時代6：第二代Service Mesh

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

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

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

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

服務網(wǎng)格是一個基礎設施層，用于處理服務間通信。云原生應用有著復雜的服務拓撲，服務網(wǎng)格保證請求在這些拓撲中可靠地穿梭。

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

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

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

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

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

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

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