對(duì)于大多數(shù)人來(lái)說(shuō)，“Service Mesh（服務(wù)網(wǎng)格）”仍然是一個(gè)新概念，因此，談?wù)撍摹皻v史”可能看起來(lái)有點(diǎn)滑稽。但事實(shí)上，早在2010年初，在一些大網(wǎng)絡(luò)規(guī)模的公司中，服務(wù)網(wǎng)格的概念就隱約開(kāi)始逐步形成了。因此，服務(wù)網(wǎng)格確實(shí)有一段歷史值得去探索、去理解。

創(chuàng)新互聯(lián)建站為企業(yè)級(jí)客戶提高一站式互聯(lián)網(wǎng)+設(shè)計(jì)服務(wù)，主要包括成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)、手機(jī)APP定制開(kāi)發(fā)、微信小程序開(kāi)發(fā)、宣傳片制作、LOGO設(shè)計(jì)等，幫助客戶快速提升營(yíng)銷能力和企業(yè)形象，創(chuàng)新互聯(lián)各部門都有經(jīng)驗(yàn)豐富的經(jīng)驗(yàn)，可以確保每一個(gè)作品的質(zhì)量和創(chuàng)作周期，同時(shí)每年都有很多新員工加入，為我們帶來(lái)大量新的創(chuàng)意。 

在深入歷史脈絡(luò)之前，讓我們先聊聊“現(xiàn)在”。什么是服務(wù)網(wǎng)格？為什么它突然成為了云原生領(lǐng)域的熱門話題？

服務(wù)網(wǎng)格是用于控制和監(jiān)視微服務(wù)應(yīng)用程序中的內(nèi)部服務(wù)到服務(wù)流量的軟件基礎(chǔ)結(jié)構(gòu)層。它通常采用與應(yīng)用程序代碼一起部署的網(wǎng)絡(luò)代理的“數(shù)據(jù)平面”的形式，以及用于與這些代理交互的“控制平面”。在這個(gè)模型中，開(kāi)發(fā)人員（“服務(wù)所有者”）可以非常幸福地完全意識(shí)不到服務(wù)網(wǎng)格的存在，而運(yùn)營(yíng)商（“平臺(tái)工程師”）則被授予一套新的工具來(lái)確?？煽啃?、安全性和可見(jiàn)性。

服務(wù)網(wǎng)格為什么會(huì)突然流行？簡(jiǎn)而言之，是因?yàn)閷?duì)于許多公司來(lái)說(shuō)，像Docker和Kubernetes這樣的工具已經(jīng)“解決了部署的問(wèn)題”——至少是差不多解決了。但Docker和Kubernetes沒(méi)能解決運(yùn)行時(shí)的問(wèn)題。而這就是服務(wù)網(wǎng)格的用武之地。

 “解決部署問(wèn)題”是什么意思？使用Docker和Kubernetes之類的技術(shù)可以為企業(yè)大大減少部署大量應(yīng)用或服務(wù)時(shí)的操作負(fù)擔(dān)。使用Docker和Kubernetes，部署100個(gè)應(yīng)用程序或服務(wù)的工作量，不再是部署單個(gè)應(yīng)用程序的100倍。這是歷史性的向前邁出的一大步，對(duì)于許多公司來(lái)說(shuō)，它可以極大降低采用微服務(wù)的成本。這可能不僅僅是因?yàn)镈ocker和Kubernetes在所有正確的級(jí)別提供了強(qiáng)大的抽象，更是因?yàn)樗鼈儤?biāo)準(zhǔn)化了整個(gè)組織的打包和部署模式。

但是，一旦應(yīng)用程序運(yùn)行之后呢？畢竟，部署不是生產(chǎn)的最后一步; 部署完之后，應(yīng)用程序還必須運(yùn)行。如此一來(lái)問(wèn)題就變成了：像使用Docker和Kubernete進(jìn)行標(biāo)準(zhǔn)化部署時(shí)一樣，我們還能以同樣的方式來(lái)將應(yīng)用程序的運(yùn)行時(shí)操作也標(biāo)準(zhǔn)化嗎？

為了解決這個(gè)問(wèn)題，服務(wù)網(wǎng)格應(yīng)運(yùn)而生。從本質(zhì)上講，服務(wù)網(wǎng)絡(luò)提供統(tǒng)一的全局方式來(lái)控制和測(cè)量應(yīng)用程序或服務(wù)之間的所有請(qǐng)求流量（在數(shù)據(jù)中心的說(shuō)法中，即“東西向”流量）。對(duì)于采用微服務(wù)的公司而言，此請(qǐng)求流量在運(yùn)行時(shí)行為中起著至關(guān)重要的作用。由于服務(wù)通過(guò)響應(yīng)傳入請(qǐng)求和發(fā)出傳出請(qǐng)求來(lái)工作，因此請(qǐng)求流成為應(yīng)用程序在運(yùn)行時(shí)的行為方式的關(guān)鍵決定因素。因此，將流量管理標(biāo)準(zhǔn)化，則成為將應(yīng)用程序運(yùn)行時(shí)標(biāo)準(zhǔn)化的工具。

通過(guò)提供API來(lái)分析和操作此流量，服務(wù)網(wǎng)絡(luò)為整個(gè)組織的運(yùn)行時(shí)操作提供了標(biāo)準(zhǔn)化機(jī)制——包括確?？煽啃?、安全性和可見(jiàn)性的方法。和任何優(yōu)秀的基礎(chǔ)設(shè)施層一樣，服務(wù)網(wǎng)格（在理想情況下）的工作方式與服務(wù)的構(gòu)建方式無(wú)關(guān)。

那么服務(wù)網(wǎng)格從何而來(lái)？做了一些軟件考古之后，我們發(fā)現(xiàn)服務(wù)網(wǎng)格提供的核心功能——請(qǐng)求級(jí)負(fù)載均衡、斷路、重試、儀器等——基本上并不是新功能。其實(shí)，服務(wù)網(wǎng)格最終是功能的重新包裝，真正發(fā)生轉(zhuǎn)變的是“地方”，而不是“什么”。

服務(wù)網(wǎng)格的起源始于大約2010年三層應(yīng)用程序架構(gòu)模型的興起——這是一種簡(jiǎn)單的架構(gòu)，一度為網(wǎng)絡(luò)上的絕大多數(shù)應(yīng)用程序提供動(dòng)力。在這個(gè)模型中，請(qǐng)求流量發(fā)揮著重要作用（有兩個(gè)躍點(diǎn)?。?。應(yīng)用程序流量首先由“Web層”處理，“web層”又與“app層”對(duì)話，后者又與“數(shù)據(jù)庫(kù)層”對(duì)話。Web層中的Web服務(wù)器旨在處理大量傳入請(qǐng)求，需要非常迅速地將它們小心地交給相對(duì)較慢的應(yīng)用服務(wù)器。（Apache、NGINX和其他流行的Web服務(wù)器都有非常復(fù)雜的邏輯來(lái)處理這種情況。）同樣，應(yīng)用層使用數(shù)據(jù)庫(kù)庫(kù)與后備存儲(chǔ)進(jìn)行通信。這些庫(kù)通常負(fù)責(zé)以針對(duì)此用例優(yōu)化的方式處理緩存、負(fù)載均衡、路由、流控制。

但是，這種三層應(yīng)用程序架構(gòu)模型，在過(guò)載的情況下會(huì)開(kāi)始崩潰——特別是在app層，隨著時(shí)間的推移它的負(fù)載會(huì)變得非常大。像谷歌、Facebook、Netflix、Twitter這樣的大公司學(xué)會(huì)了將單體架構(gòu)拆分成許多獨(dú)立運(yùn)行的塊，從而催生了微服務(wù)的興起。在引入微服務(wù)的那一刻，還引入了東西向流量。在這個(gè)世界上，通信不再是專一的，而是在每一項(xiàng)服務(wù)之間。通信若出錯(cuò)，整個(gè)網(wǎng)站都會(huì)出現(xiàn)故障。

因此，這些公司都以類似的方式做出了回應(yīng)：他們編寫了“胖客戶端”庫(kù)來(lái)處理請(qǐng)求流量。這些庫(kù)——例如谷歌的Stubby、Netflix的Hysterix、Twitter的Finagle——為所有服務(wù)提供了統(tǒng)一的運(yùn)行時(shí)操作方式。開(kāi)發(fā)人員或服務(wù)所有者使用這些庫(kù)向其他服務(wù)發(fā)出請(qǐng)求，而在這個(gè)框架下，這些庫(kù)將負(fù)責(zé)負(fù)載均衡、路由、斷路、遙測(cè)。通過(guò)在應(yīng)用程序中的每個(gè)服務(wù)之間提供統(tǒng)一的行為、可見(jiàn)性和控制點(diǎn)，這些庫(kù)形成了表面上最初的服務(wù)網(wǎng)格——沒(méi)有花哨的名稱。

快進(jìn)到現(xiàn)代的云原生世界。當(dāng)然，這些庫(kù)仍然存在。但是，鑒于進(jìn)程外代理提供的操作便利性，庫(kù)的吸引力顯著降低了——尤其是當(dāng)容器和編排框架的出現(xiàn)使得部署復(fù)雜性大幅下降時(shí)。

代理避免了庫(kù)的許多缺點(diǎn)。例如，當(dāng)一個(gè)庫(kù)發(fā)生變化時(shí)，必須在每個(gè)服務(wù)中部署這些變化，這個(gè)過(guò)程往往需要復(fù)雜的組織層面的協(xié)調(diào)工作。相比之下，代理可以在不重新編譯和重新部署每個(gè)應(yīng)用程序的情況下進(jìn)行升級(jí)。同樣，代理支持多語(yǔ)言系統(tǒng)，在多語(yǔ)言系統(tǒng)中由服務(wù)組成的應(yīng)用程序是用不同語(yǔ)言編寫的——而這種方法對(duì)于庫(kù)而言過(guò)于昂貴。

也許最重要的是，對(duì)于大型組織而言，在代理而不是庫(kù)中實(shí)現(xiàn)服務(wù)網(wǎng)絡(luò)，會(huì)將提供必要功能的責(zé)任，從服務(wù)所有者手上，轉(zhuǎn)移到最終使用該服務(wù)的終端用戶（即平臺(tái)工程團(tuán)隊(duì)）手上。服務(wù)提供者和使用者的這種一致性，將會(huì)讓這些團(tuán)隊(duì)把握自己的命運(yùn)，消除開(kāi)發(fā)和運(yùn)維之間復(fù)雜的依賴關(guān)系。

這些因素都有助于服務(wù)網(wǎng)格的興起。通過(guò)部署代理的分布式“網(wǎng)格”（它可以作為底層基礎(chǔ)架構(gòu)的一部分而不是應(yīng)用程序本身來(lái)進(jìn)行維護(hù)），并通過(guò)提供集中式API來(lái)分析和操作此流量，服務(wù)網(wǎng)格為跨越整個(gè)組織的運(yùn)行時(shí)操作提供了標(biāo)準(zhǔn)化機(jī)制，包括確?？煽啃?、安全性和可見(jiàn)性的方法。

Service Mesh極大地簡(jiǎn)化了用戶體驗(yàn)，并將大中型企業(yè)的Kubernetes落地引領(lǐng)進(jìn)下一個(gè)全新階段，被業(yè)界普遍認(rèn)為是新一代的微服務(wù)架構(gòu)的最佳技術(shù)設(shè)計(jì)。日前，國(guó)內(nèi)外企業(yè)及技術(shù)領(lǐng)域?qū)ervice Mesh技術(shù)的應(yīng)用和探索開(kāi)展的如火如荼，對(duì)大多數(shù)使用容器的企業(yè)而言，Service Mesh仿佛是容器部署中亟待補(bǔ)齊的最后一塊拼圖。

由CNCF舉辦的KubeCon + CloudNativeCon，作為世界范圍的Kubernetes與容器技術(shù)領(lǐng)域的頂級(jí)技術(shù)盛會(huì)，將于今年11月14日-15日登陸上海，這是KubeCon首次來(lái)華舉辦。Rancher Labs攜手華為，將于11月13日和CNCF聯(lián)合舉辦KubeCon同場(chǎng)會(huì)議，同中國(guó)區(qū)眾多企業(yè)客戶一起，推出2018云原生服務(wù)網(wǎng)格（Istio）企業(yè)峰會(huì)。

屆時(shí)，來(lái)自華為、上汽集團(tuán)、Rancher Labs、云宏、興業(yè)銀行、飛貸金融、金風(fēng)科技、樹(shù)維信息等著名企業(yè)的科技負(fù)責(zé)人和微服務(wù)架構(gòu)師，將分享各自在新一代微服務(wù)架構(gòu)建設(shè)和Service Mesh應(yīng)用方面的經(jīng)驗(yàn)和心得。

日期：11月13日，星期二

時(shí)間：上午9:00至下午6:00

地點(diǎn)：上海新發(fā)展亞太JW萬(wàn)豪酒店，長(zhǎng)風(fēng)大宴會(huì)廳

報(bào)名：http://t.cn/RFG85AW

誠(chéng)邀您屆時(shí)蒞臨峰會(huì)，共話容器、微服務(wù)、Kubernetes等新技術(shù)的落地應(yīng)用。

英文原文鏈接：

https://thenewstack.io/history-service-mesh/