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

 

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

 

 

從最廣泛的意義上講，“服務網格”正如Red Hat公司所描述的那樣，“服務網格是一種控制應用程序的不同部分如何共享數據的方法。”

 

不過這個描述可能包含很多不同的東西。事實上，它聽起來很像大多數開發人員所熟悉的來自客戶端-服務器應用程序的中間件。

 

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

 

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

 

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

 

 

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

 

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

 

 

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

 

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

 

 

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

 

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

 

 

服務網格的概念最近幾年才出現，并且有許多不同的方法來解決“服務網格”問題，即管理微服務的通信。Aspen Mesh公司的Andrew Jenkins確定了三種可能的選擇，即服務網格創建的通信層可能存在的位置：

 

•在每個微服務導入的庫中。

 

•在為特定節點上的所有容器提供服務的節點代理程序中。

 

•在與應用程序容器一起運行的Sidecar容器中。

 

Sidecar是將應用程序的組件部署到單獨的進程或容器中,以提供隔離和封裝。基于Sidecar的模式是最流行的服務網格模式之一，以至于它在某些方面通常成為服務網格的同義詞。雖然這并非嚴格，但是Sidecar容器方法已經引起了很大的關注，這是人們需要仔細研究的架構。

 

 

“Sidecars容器與其應用容器一起運行”是什么?Red Hat公司對此給出一個很好的解釋。這種類型的服務網格中的每個微服務容器都有另一個與之對應的代理容器。服務到服務通信所需的所有邏輯都從微服務中抽象出來并放入Sidecars中。

 

這可能看起來很復雜，畢竟，企業的應用程序中容器的數量實際上增加了一倍。但也在使用一種設計模式，這是簡化分布式應用程序的關鍵。通過將所有的網絡和通信代碼放在一個單獨的容器中，已經將其作為基礎設施的一部分，并使開發人員不再將其作為應用程序的一部分來實現。

 

從本質上講，剩下的是可以聚焦于其業務邏輯的微服務。微服務不需要知道如何在復雜的環境中與其他所有服務進行通信。它只需要知道如何與Sidecars溝通，而Sidecars則負責處理其余的事情。

 

服務網格：Linkerd、Envio、Istio、Consul

 

那么有哪些可用的服務網格?沒有現成的商業產品。大多數服務網格都是開放源碼項目，需要進行一些最終的實現。一些比較知名的產品是：

 

•Linkerd——于2016年發布，因此是最早的產品，Linkerd從Twitter開發的圖書館中分離出來。這個領域的另一位主要的產品，即Conduit，已經進入了Linkerd項目，并構成了Linkerd 2.0的基礎。

 

•Envio——在Lyft創建，Envoy占據服務網格的“數據平臺”部分。要提供全服務網格，需要與“控制平臺” 配對。

 

•Istio——由Lyft、IBM、Google合作開發，Istio是一項服務代理的服務計劃，如Envoy。雖然Istio和Envoy是默認的配對，但每個都可以與其他平臺配對。

 

•HashiCorp Consul——與Consul 1.2一起推出，這項名為Connect的功能為HashiCorp的分布式系統添加了服務加密和基于身份的授權，用于服務發現和配置，將其轉??變為一個完整的服務網格。

 

那么更適合采用哪種服務網格?很難進行比較，但這些產品都已在大型且苛刻的環境中得到驗證。Linkerd和Istio擁有最廣泛的功能集，但都在迅速發展。

 

另外請記住，新的競爭對手可能隨時出現在市場中。例如，在2018年11月，亞馬遜公司開始提供AWS服務網格的公開預覽。考慮到大量用戶采用亞馬遜的公共云，因此AWS App Mesh的推出應該會產生重大影響。