服務網格(Service Mesh)為服務通信帶來了安全性、彈性、可見性，因此使開發人員不必做這些。

IT在數字化轉型趨勢下發生的變化之一是將大型單片應用程序分解為微服務，這些小型的、離散的功能單元在容器中運行，其軟件包包括服務所有代碼，并可以被隔離，輕松地從一個服務器移動到另一個服務器。  

像這樣的容器化架構很容易在云中進行擴展和運行，并且可以快速部署和迭代各個微服務。然而，隨著應用程序的規模變得越來越大，同一服務的多個實例同時運行，這些微服務之間的通信變得越來越復雜。服務網格是一種新興的架構形式，旨在以減少管理和編程開銷的方式動態連接這些微服務。  

什么是服務網格?   從最廣泛的意義上講，“服務網格”正如Red Hat公司所描述的那樣，“服務網格是一種控制應用程序的不同部分如何共享數據的方法。”   不過這個描述可能包含很多不同的東西。事實上，它聽起來很像大多數開發人員所熟悉的來自客戶端-服務器應用程序的中間件。  

服務網格的獨特之處在于，它是為適應分布式微服務環境的獨特性質而構建的。在由微服務構建的大型應用程序中，可能存在給定服務的多個實例，它們運行在不同的本地或云計算服務器上。顯然，所有這些移動部件都使得單個微服務很難找到他們需要與之通信的其他服務。服務網格會自動處理即時發現和連接服務，這樣開發人員和微服務都不必這樣做。  

將服務網格視為開放式系統互聯(OSI)網絡模型的第7級軟件定義網絡(SDN)的等效物。正如軟件定義網絡(SDN)創建一個抽象層，因此網絡管理員不必處理物理網絡連接，服務網格將應用程序的底層基礎結構與企業交互的抽象體系結構分離。  

隨著開發人員開始努力解決真正龐大的分布式架構的問題，服務網格的概念出現了。 Linkerd是該領域的第一個項目，誕生于Twitter內部項目的分支。Istio是另一個受歡迎的服務網絡，擁有主要的企業支持，起源于Lyft。  

服務網格負載平衡   服務網格提供的一個關鍵特性是負載平衡。人們通常將負載均衡視為網絡功能，企業希望防止任何一個服務器或網絡鏈路被流量淹沒，因此可以相應地路由其數據包。正如Twain Taylor所描述的那樣，服務網格在應用程序級別上做了類似的事情，理解這一點可以讓人們很好地理解服務網格就像是應用程序層的軟件定義的網絡。  

本質上，服務網格的一個工作是跟蹤分布在基礎設施上的各種微服務的哪些實例是“最健康的”。它可能會輪詢以查看它們是如何做的，或跟蹤哪些實例響應緩慢服務請求，并將后續請求發送到其他實例。服務網格可以為網絡路由執行類似的工作，注意到消息需要很長時間才能到達目的地，并采取其他路由進行補償。這些速度慢的原因可能是底層硬件的問題，或者僅僅是服務被請求超載。重要的是，服務網格可以找到相同服務的另一個實例，并將其路由到該實例，從而最有效地利用整個應用程序的容量。  

服務網格與Kubernetes   如果人們對基于容器的架構有些了解，那么可能想知道Kubernetes(流行的開源容器編排平臺)適合這種情況。畢竟，Kubernetes管理容器之間如何通信不是其全部要點嗎?正如Kublr公司在其企業博客上指出的那樣，可以將Kubernetes的服務資源視為一種非常基本的服務網絡，因為它提供服務發現和循環請求平衡。但是功能齊全的服務網格提供了更多功能，如管理安全策略和加密，“線路中斷”以暫停對慢響應實例的請求。  

人們需要了解的是，大多數服務網格確實需要像Kubernetes這樣的編排系統。服務網格提供擴展功能，而不是替代功能。  

服務網格與API網關   每個微服務都將提供一個應用程序編程接口(API)，作為其他服務與之通信的手段。這引發了服務網格與其他更傳統的API管理形式(如API網關)之間的差異問題。正如IBM公司解釋的那樣，VPS租用，API網關位于一組微服務和外部世界之間，根據需要路由服務請求，以便請求者不需要知道它正在處理基于微服務的應用程序。另一方面，服務網格調解微服務應用程序內部的請求，并需要用戶完全了解其環境。  

正如Justin Warren所指出的那樣，另一種思考方式是服務網格用于集群內的東西向流量，而API網關用于進出集群的南北流量。但服務網格的想法仍處于早期階段，并且不斷變化。許多服務網格(包括Linkerd和Istio)現在也提供南北向流量功能。