在數字化轉型的旗幟下，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包含最豐富的功能集，但一切都還在迅速發展中，現在下定論還為時過早。