30
什麼是服務網格以及為什麼我們需要服務網格？
Service Mesh（服務網格）是一個基礎設施層，讓服務之間的通信更安全、快速和可靠。如果你在構建雲原生應用，那麼就需要Service Mesh。
在過去的一年中，Service Mesh已經成為雲原生技術棧裏的一個關鍵組件。很多擁有高負載業務流量的公司都在他們的生產應用裏加入了Service Mesh，如PayPal、Lyft、Ticketmaster和Credit Karma等。今年一月份，Service Mesh組件Linkerd成為CNCF（Cloud Native Computing Foundation）的官方項目。不過話說回來，Service Mesh到底是什麼？為什麼它突然間變得如此重要？
在這篇文章裏，我將給出Service Mesh的定義，並追溯過去十年間Service Mesh在應用架構中的演變過程。我會解釋Service Mesh與API網關、邊緣代理（Edge Proxy）和企業服務總線之間的區別。最後，我會描述Service Mesh將何去何從以及我們可以作何期待。
什麼是Service Mesh？
Service Mesh是一個基礎設施層，用於處理服務間通信。雲原生應用有著複雜的服務拓撲，Service Mesh保證請求可以在這些拓撲中可靠地穿梭。在實際應用當中，Service Mesh通常是由一係列輕量級的網絡代理組成的，它們與應用程序部署在一起，但應用程序不需要知道它們的存在。
隨著雲原生應用的崛起，Service Mesh逐漸成為一個獨立的基礎設施層。在雲原生模型裏，一個應用可以由數百個服務組成，每個服務可能有數千個實例，而每個實例可能會持續地發生變化。服務間通信不僅異常複雜，而且也是運行時行為的基礎。管理好服務間通信對於保證端到端的性能和可靠性來說是非常重要的。
Service Mesh是一種網絡模型嗎？
Service Mesh實際上就是處於TCP/IP之上的一個抽象層，它假設底層的L3/L4網絡能夠點對點地傳輸字節（當然，它也假設網絡環境是不可靠的，所以Service Mesh必須具備處理網絡故障的能力）。
從某種程度上說，Service Mesh有點類似TCP/IP。TCP對網絡端點間傳輸字節的機製進行了抽象，而Service Mesh則是對服務節點間請求的路由機製進行了抽象。Service Mesh不關心消息體是什麼，也不關心它們是如何編碼的。應用程序的目標是“將某些東西從A傳送到B”，而Service Mesh所要做的就是實現這個目標，並處理傳送過程中可能出現的任何故障。
與TCP不同的是，Service Mesh有著更高的目標：為應用運行時提供統一的、應用層麵的可見性和可控性。Service Mesh將服務間通信從底層的基礎設施中分離出來，讓它成為整個生態係統的一等公民——它因此可以被監控、托管和控製。
Service Mesh可以做什麼？
在雲原生應用中傳輸服務請求是一項非常複雜的任務。以Linkerd為例，它使用了一係列強大的技術來管理這種複雜性：回路斷路器、負載均衡、延遲感知、最終一致性服務發現、重試和超時。這些技術需要組合在一起，並互相協調，它們與環境之間的交互也非常微妙。
舉個例子，當一個請求流經Linkerd時，會發生如下的一係列事件。
Linkerd根據動態路由規則確定請求是發給哪個服務的，比如是發給生產環境裏的服務還是發給staging環境裏的服務？是發給本地數據中心的服務還是發給雲端的服務？是發給最新版本的服務還是發給舊版本的服務？這些路由規則可以動態配置，可以應用在全局的流量上，也可以應用在部分流量上。在確定了請求的目標服務後，Linkerd從服務發現端點獲取相應的服務實例。如果服務實例的信息出現了偏差，Linkerd需要決定哪個信息來源更值得信任。Linkerd基於某些因素（比如最近處理請求的延遲情況）選擇更有可能快速返回響應的實例。Linkerd向選中的實例發送請求，並把延遲情況和響應類型記錄下來。如果選中的實例發生宕機、沒有響應或無法處理請求，Linkerd就把請求發給另一個實例（前提是請求必須是冪等的）。如果一個實例持續返回錯誤，Linkerd就會將其從負載均衡池中移除，並在稍後定時重試（這個實例有可能隻是臨時發生故障）。如果請求超時，Linkerd會主動放棄請求，不會進行額外的重試。Linkerd以度量指標和分布式日誌的方式記錄上述各種行為，然後將度量指標發送給中心度量指標係統。除此之外，Linkerd還能發起和終止TLS、執行協議升級、動態調整流量、在數據中心之間進行失效備援。
Linkerd的這些特性可以保證局部的彈性和應用層麵的彈性。大規模分布式係統有一個共性：局部故障累積到一定程度就會造成係統層麵的災難。Service Mesh的作用就是在底層係統的負載達到上限之前通過分散流量和快速失效來防止這些故障破壞到整個係統。
為什麼我們需要Service Mesh？
Service Mesh並非新出現的功能。一直以來，Web應用程序需要自己管理複雜的服務間通信，從過去十多年間應用程序的演化就可以看到Service Mesh的影子。
2000年左右的中型Web應用一般使用了三層模型：應用邏輯層、Web服務邏輯層和存儲邏輯層。層與層之間的交互雖然也不算簡單，但複雜性是很有限的，畢竟一個請求最多隻需要兩個跳轉。雖然這裏不存在“網格”，但仍然存在跳轉通信邏輯。
隨著規模的增長，這種架構就顯得力不從心了。像Google、Netflix、Twitter這樣的公司麵臨著大規模流量的挑戰，他們實現了一種高效的解決方案，也就是雲原生應用的前身：應用層被拆分為多個服務（也叫作微服務），這個時候層就變成了一種拓撲結構。這樣的係統需要一個通用的通信層，以一個“富客戶端”包的形式存在，如Twitter的Finagle、Netflix的Hystrix和Google的Stubby。
一般來說，像Finagle、Stubby和Hystrix這樣的包就是最初的Service Mesh。雲原生模型在原先的微服務模型中加入了兩個額外的元素：容器（比如Docker）和編排層（如Kubernetes）。容器提供了資源隔離和依賴管理，編排層對底層的硬件進行抽象池化。
這三個組件讓應用程序在雲環境中具備了伸縮能力和處理局部故障的能力。但隨著服務和實例的數量增長，編排層需要無時不刻地調度實例，請求在服務拓撲間穿梭的路線也變得異常複雜，再加上可以使用任意語言來開發不同的服務，所以之前那種“富客戶端”包的方式就行不通了。
這種複雜性和迫切性催生了服務間通信層的出現，這個層既不會與應用程序的代碼耦合，又能捕捉到底層環境高度動態的特點，它就是Service Mesh。
Service Mesh的未來
盡管Service Mesh在雲原生係統方麵的應用已經有了快速的增長，但仍然存在巨大的提升空間。無服務器(Serverless)計算（如Amazon的Lambda）正好需要Service Mesh的命名和鏈接模型，這讓Service Mesh在雲原生生態係統中的角色得到了彰顯。服務識別和訪問策略在雲原生環境中仍顯初級，而Service Mesh毫無疑問將成為這方麵不可或缺的基礎。就像TCP/IP一樣，Service Mesh將在底層基礎設施這條道上更進一步。
結論
Service Mesh是雲原生技術棧中一個非常關鍵的組件。Linkerd項目在啟動一年多之後正式成為CNCF的官方項目，並擁有了眾多的貢獻者和用戶。Linkerd的用戶橫跨初創公司（如Monzo）到大規模的互聯網公司（如PayPal、Ticketmaster、Credit Karma），再到擁有數百年曆史的老牌公司（如Houghton Mifflin Harcourt）。
本文轉自d1net（轉載）
最後更新：2017-11-10 14:35:23