一文了解「Service Mesh（服務網格）」的歷史與如今

對於大多數人來講，「Service Mesh（服務網格）」仍然是一個新概念，所以，談論它的「歷史」可能看起來有點滑稽。但事實上，早在2010年初，在一些大網絡規模的公司中，服務網格的概念就隱約開始逐步造成了。所以，服務網格確實有一段歷史值得去探索、去理解。

在深刻歷史脈絡以前，讓咱們先聊聊「如今」。什麼是服務網格？爲何它忽然成爲了雲原生領域的熱門話題？

服務網格是用於控制和監視微服務應用程序中的內部服務到服務流量的軟件基礎結構層。它一般採用與應用程序代碼一塊兒部署的網絡代理的「數據平面」的形式，以及用於與這些代理交互的「控制平面」。在這個模型中，開發人員（「服務全部者」）能夠很是幸福地徹底意識不到服務網格的存在，而運營商（「平臺工程師」）則被授予一套新的工具來確保可靠性、安全性和可見性。

服務網格爲何會忽然流行？簡而言之，是由於對於許多公司來講，像Docker和Kubernetes這樣的工具已經「解決了部署的問題」——至少是差很少解決了。但Docker和Kubernetes沒能解決運行時的問題。而這就是服務網格的用武之地。

「解決部署問題」是什麼意思？使用Docker和Kubernetes之類的技術能夠爲企業大大減小部署大量應用或服務時的操做負擔。使用Docker和Kubernetes，部署100個應用程序或服務的工做量，再也不是部署單個應用程序的100倍。這是歷史性的向前邁出的一大步，對於許多公司來講，它能夠極大下降採用微服務的成本。這可能不只僅是由於Docker和Kubernetes在全部正確的級別提供了強大的抽象，更是由於它們標準化了整個組織的打包和部署模式。

可是，一旦應用程序運行以後呢？畢竟，部署不是生產的最後一步; 部署完以後，應用程序還必須運行。如此一來問題就變成了：像使用Docker和Kubernete進行標準化部署時同樣，咱們還能以一樣的方式來將應用程序的運行時操做也標準化嗎？

爲了解決這個問題，服務網格應運而生。從本質上講，服務網絡提供統一的全局方式來控制和測量應用程序或服務之間的全部請求流量（在數據中心的說法中，即「東西向」流量）。對於採用微服務的公司而言，此請求流量在運行時行爲中起着相當重要的做用。因爲服務經過響應傳入請求和發出傳出請求來工做，所以請求流成爲應用程序在運行時的行爲方式的關鍵決定因素。所以，將流量管理標準化，則成爲將應用程序運行時標準化的工具。

經過提供API來分析和操做此流量，服務網絡爲整個組織的運行時操做提供了標準化機制——包括確保可靠性、安全性和可見性的方法。和任何優秀的基礎設施層同樣，服務網格（在理想狀況下）的工做方式與服務的構建方式無關。

服務網格是如何造成的？

那麼服務網格從何而來？作了一些軟件考古以後，咱們發現服務網格提供的核心功能——請求級負載均衡、斷路、重試、儀器等——基本上並非新功能。其實，服務網格最終是功能的從新包裝，真正發生轉變的是「地方」，而不是「什麼」。

服務網格的起源始於大約2010年三層應用程序架構模型的興起——這是一種簡單的架構，一度爲網絡上的絕大多數應用程序提供動力。在這個模型中，請求流量發揮着重要做用（有兩個躍點！）。應用程序流量首先由「Web層」處理，「web層」又與「app層」對話，後者又與「數據庫層」對話。Web層中的Web服務器旨在處理大量傳入請求，須要很是迅速地將它們當心地交給相對較慢的應用服務器。（Apache、NGINX和其餘流行的Web服務器都有很是複雜的邏輯來處理這種狀況。）一樣，應用層使用數據庫庫與後備存儲進行通訊。這些庫一般負責以針對此用例優化的方式處理緩存、負載均衡、路由、流控制。

可是，這種三層應用程序架構模型，在過載的狀況下會開始崩潰——特別是在app層，隨着時間的推移它的負載會變得很是大。像谷歌、Facebook、Netflix、Twitter這樣的大公司學會了將單體架構拆分紅許多獨立運行的塊，從而催生了微服務的興起。在引入微服務的那一刻，還引入了東西向流量。在這個世界上，通訊再也不是專注的，而是在每一項服務之間。通訊若出錯，整個網站都會出現故障。

所以，這些公司都以相似的方式作出了迴應：他們編寫了「胖客戶端」庫來處理請求流量。這些庫——例如谷歌的Stubby、Netflix的Hysterix、Twitter的Finagle——爲全部服務提供了統一的運行時操做方式。開發人員或服務全部者使用這些庫向其餘服務發出請求，而在這個框架下，這些庫將負責負載均衡、路由、斷路、遙測。經過在應用程序中的每一個服務之間提供統一的行爲、可見性和控制點，這些庫造成了表面上最初的服務網格——沒有花哨的名稱。

Proxy的興起

快進到現代的雲原生世界。固然，這些庫仍然存在。可是，鑑於進程外代理提供的操做便利性，庫的吸引力顯著下降了——尤爲是當容器和編排框架的出現使得部署複雜性大幅降低時。

代理避免了庫的許多缺點。例如，當一個庫發生變化時，必須在每一個服務中部署這些變化，這個過程每每須要複雜的組織層面的協調工做。相比之下，代理能夠在不從新編譯和從新部署每一個應用程序的狀況下進行升級。一樣，代理支持多語言系統，在多語言系統中由服務組成的應用程序是用不一樣語言編寫的——而這種方法對於庫而言過於昂貴。

也許最重要的是，對於大型組織而言，在代理而不是庫中實現服務網絡，會將提供必要功能的責任，從服務全部者手上，轉移到最終使用該服務的終端用戶（即平臺工程團隊）手上。服務提供者和使用者的這種一致性，將會讓這些團隊把握本身的命運，消除開發和運維之間複雜的依賴關係。

這些因素都有助於服務網格的興起。經過部署代理的分佈式「網格」（它能夠做爲底層基礎架構的一部分而不是應用程序自己來進行維護），並經過提供集中式API來分析和操做此流量，服務網格爲跨越整個組織的運行時操做提供了標準化機制，包括確保可靠性、安全性和可見性的方法。

企業級服務網格應用

Service Mesh極大地簡化了用戶體驗，並將大中型企業的Kubernetes落地引領進下一個全新階段，被業界廣泛認爲是新一代的微服務架構的最佳技術設計。日前，國內外企業及技術領域對Service Mesh技術的應用和探索開展的如火如荼，對大多數使用容器的企業而言，Service Mesh彷彿是容器部署中亟待補齊的最後一塊拼圖。

由CNCF舉辦的KubeCon + CloudNativeCon，做爲世界範圍的Kubernetes與容器技術領域的頂級技術盛會，將於今年11月14日-15日登錄上海，這是KubeCon首次來華舉辦。Rancher Labs攜手華爲，將於11月13日和CNCF聯合舉辦KubeCon同場會議，同中國區衆多企業客戶一塊兒，推出2018雲原生服務網格（Istio）企業峯會。

屆時，來自華爲、上汽集團、Rancher Labs、雲宏、興業銀行、飛貸金融、金風科技、樹維信息等著名企業的科技負責人和微服務架構師，將分享各自在新一代微服務架構建設和Service Mesh應用方面的經驗和心得。

日期：11月13日，星期二

時間：上午9:00至下午6:00

地點：上海新發展亞太JW萬豪酒店，長風大宴會廳

報名：http://t.cn/RFG85AW
大會詳情+在線註冊

誠邀您屆時蒞臨峯會，共話容器、微服務、Kubernetes等新技術的落地應用。

英文原文連接：

https://thenewstack.io/histor...