Service mesh是近幾年纔出現的一個新興概念。它可以解決微服務之間通信愈發複雜的問題。那麼什麼是Service mesh？它有什麼具體的功能？它的架構又是如何的呢？它與Kubernetes的關係是怎樣的？所有答案戳文了解！
在數字化轉型的旗幟下，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包含最豐富的功能集，但一切都還在迅速發展中，現在下定論還爲時過早。