全方位詳解Service Mesh（服務網格）

在數字化轉型的旗幟下，IT界的一大變化是大型單體應用程序被分解爲微服務架構，即小型、離散的功能單元，而且這些應用程序在容器中運行。包含全部服務代碼以及依賴項的軟件包被隔離起來，而且能輕鬆從一個服務器遷移到另外一個。

像這樣的容器化架構很容易在雲中擴展和運行，而且可以快速迭代和推出每一個微服務。然而，當應用程序愈來愈大而且在同一個服務上同時運行多個實例時，微服務之間通訊將會變得愈發複雜。Service mesh的出現將解決這一問題，它是一個新興的架構形式，旨在以減小管理和編程開銷的形式來鏈接這些微服務。

什麼是Service mesh？

關於Service mesh的定義，最爲普遍接受的觀點是：它是一種控制應用程序不一樣部分彼此共享數據的方式。這一描述包含了service mesh的方方面面。事實上，它聽起來更像是大多數開發人員從客戶端-服務器應用程序中熟悉的中間件。

Service mesh也有其獨特之處：它可以適應分佈式微服務環境的獨特性質。在搭建在微服務中的大規模應用程序中，有許多既定的服務實例，它們跨本地和雲服務器運行。全部這些移動部件顯然使得各個微服務難以找到他們須要與之通訊的其餘服務。Service mesh能夠在短期內自動處理髮現和鏈接服務，而無需開發人員以及各個微服務自行匹配。

咱們能夠將service mesh等同爲軟件定義網絡（SDN）的OSI網絡模型第7層。正如SDN建立一個抽象層後網絡管理員沒必要處理物理網絡鏈接，service mesh將解耦在抽象架構中的與你交互的應用程序的底層基礎架構。

隨着開發人員開始努力解決真正龐大的分佈式架構的問題，service mesh的概念適時地出現了。這一領域的第一個項目是Linkerd，它一開始是Twitter內部項目的一個分支。Istio是另外一個十分流行的service mesh項目，它起源於Lyft，如今這一項目得到了許多企業的支持。

Service mesh負載均衡

Service mesh其中一個關鍵功能是負載均衡。咱們經常將負載均衡視爲網絡功能——你想要防止服務器或網絡連接被流量淹沒，所以相應地你會路由你的數據包，而Service mesh在應用程序層面也在執行相似的事情。

本質上，Service mesh的工做之一是跟蹤分佈在基礎設施上的各類微服務的哪些實例是「最健康的」。它可能對他們進行調查來查看它們如何工做的或跟蹤哪些實例對服務請求響應緩慢並將後續請求發送到其餘實例。此外，service mesh也會爲網絡路由作相似的工做，若是發現當消息須要很長時間才能送達，那麼service mesh將會採用其餘路由進行補償。這些減速多是因爲底層硬件出現問題，或者僅僅是因爲服務因請求過載或處理能力不足致使的。但沒有關係，service mesh會找到另外一個相同服務的實例，而後將其路由以替代響應緩慢的實例，高效利用了整個應用程序的資源。

Service mesh vs Kubernetes

若是你稍微熟悉基於容器的架構，你可能會想Kubernetes這個流行的開源容器編排平臺可否適合這種狀況。畢竟，Kubernetes不就是管理着你的容器之間如何互相通訊的嗎？你可將Kubernetes「服務」資源視爲很是基礎的service mesh，由於它提供服務發現和請求的輪詢調度均衡。可是完整的service mesh則提供更豐富的功能，如管理安全策略和加密、「斷路」以暫停對緩慢響應的實例的請求以及如上所述的負載均衡等。

請記住，大多數service mesh確實須要像Kubernetes這樣的編排系統。Service mesh只是提供擴展功能，而非替代編排平臺。

Service mesh vs API 網關

每一個微服務都會提供一個API，它會做爲其餘服務與其通訊的手段。這引起了service mesh與其餘更傳統的API管理形式（如API網關）之間的差別問題。API網關位於一組微服務和「外部」世界之間，它根據須要路由服務請求，以便請求者不須要知道它正在處理基於微服務的應用程序便可完成請求。而service mesh調解微服務應用程序內部的請求，各類組件徹底瞭解其環境。

另外一方面，service mesh用於優化集羣內東西流量（server-server流量），API網關用於進出集羣的南北流量（server-client流量）。但service mesh目前依舊處於早期階段還在不斷髮展變化中。許多service mesh（包括Linkerd和Istio）如今已經能夠提供南北功能。

Service mesh 架構

Service mesh這一律念其實出現的時間並不長，而且已經有至關數量的不一樣的方法來解決「service mesh」的問題，如管理微服務通訊。目前，肯定了三種service mesh建立的通訊層可能存在的位置：

• 每一個微服務導入的library
• 在特定節點提供服務給全部容器的節點agent
• 與應用程序容器一塊兒運行的sidecar容器

基於sidecar的模式目前是service mesh最受歡迎的模式之一，以致於它在某種程度上已經成爲了service mesh的代名詞。儘管這種說法並不嚴謹，可是sidecar已經引發了很大的關注，咱們將在下文更詳細地研究這一架構。

Sidecar

Sidecar容器與你的應用程序容器一塊兒運行意味着什麼呢？在這類service mesh中每一個微服務容器都有另外一個proxy容器與之相對應。全部的服務間通訊的需求都會被抽象出微服務以外而且放入sidecar。

這彷佛很複雜，畢竟你有效地將應用程序中的容器數量增長了1倍。但你使用的這一種設計模式對於簡化分佈式應用程序相當重要。經過將全部的網絡和通訊代碼放到單獨的容器中，將其做爲基礎架構的一部分，並使開發人員無需將其做爲應用程序的一部分實現。

本質上，你所留下的是一個聚焦於業務邏輯的微服務。這個微服務不須要知道如何在其運行的環境中與全部其餘服務進行通訊。它只須要知道如何與sidecar進行通訊便可，剩下的將由sidecar完成。

Service mesh明星項目：Linkerd、Envio、Istio、Consul

那麼說了這麼多，什麼是可用的service mesh呢？目前，這一領域尚未出現徹底現成的商業產品。大部分的service mesh只是開源項目，須要經過必定的操做步驟才能實現，如今比較知名的項目有：

• Linkerd：2016年發佈，是這些項目中最老的。Linkerd是從Twitter開發的library中分離出來的。在這一領域另外一位重量型選手，Conduit，已經進入了Linkerd項目並構成了Linkerd 2.0的基礎。

• Envoy：由Lyft建立，爲了可以提供完整的service mesh功能，Envoy佔據「數據平面」的部分，與其進行匹配。

• Istio：由Lyft、IBM與google聯合開發，Istio能夠在不修改微服務源代碼的狀況下，輕鬆爲其加上如負載均衡、身份驗證等功能，它能夠經過控制Envoy等代理服務來控制全部的流量。此外，Istio提供容錯、金絲雀部署、A/B測試、監控等功能，而且支持自定義的組件和集成。Rancher 2.3 Preview2版本上開始支持Istio，用戶能夠直接在UI界面中啓動Istio而且能夠爲每一個命名空間注入自動sidecar。Rancher內置了一個支持Kiali的儀表盤，簡化Istio的安裝和配置。這一切讓部署和管理Istio變得簡單而快速。

• HashiCorp Consul：與Consul 1.2一塊兒推出了一項名爲Connect的功能，爲HashiCorp的分佈式系統添加了服務加密和基於身份的受權，可用於服務發現和配置。

哪一個service mesh適合你？若是要進行一個全面的比較的話，超出了本文所涉及的範圍。但上述的全部產品都已經在大型且嚴苛的環境中獲得驗證。目前，Linkerd和Istio包含最豐富的功能集，但一切都還在迅速發展中，如今下定論還爲時過早。