向微服務的轉變面臨着一系列挑戰。如果認為微服務的架構，設計和開發很複雜，那麼部署和管理它們也同樣複雜。

開發人員需要確保跨服務的通信是安全的。他們還需要實施分佈式跟蹤，以告知每次調用需要多長時間。重試，斷路器等分佈式服務的一些最佳實踐為服務帶來了彈性。微服務通常是多語言的，並使用不同的庫和SDK。編寫通用的可重用軟件來管理跨HTTP，gRPC和GraphQL等不同協議的服務內通信非常複雜，昂貴且耗時。

部署基於微服務的應用程序後，上線之後的運維將由DevOps團隊執行。他們需要監視服務運行狀況，延遲，日誌，事件和跟蹤。 DevOps團隊還有望實施基於策略的路由，以配置藍/綠部署，金絲雀版本和滾動升級。最後，需要將源自多個微服務的指標，事件，日誌和警報進行彙總，並與現有的可觀察性和監視技術棧集成。

服務網格是雲原生和微服務世界中的一種新現象，它試圖為開發人員和運營商解決這些問題。在容器編排之後，如果有一項技術引起了開發人員和操作員的注意，那麼絕對是服務網格。雲原生倡導者建議在生產環境中運行微服務時使用服務網格。

服務網格使開發人員無需構建特定於語言的SDK和工具來管理服務內通信。對於運營商而言，服務網格可提供即用型流量策略，可觀察性以及來自堆棧的洞察力。

服務網格的最好之處在於它是一種“零侵入”軟件，不會強制更改代碼或配置。通過利用sidecar的模式，服務網格將代理注入到每個服務中，充當主機服務的代理。由於代理會攔截每個入站和出站調用，因此它可以在調用堆棧中獲得無與倫比的可見性。與服務相關聯的每個代理將從調用堆棧收集的遙測發送到集中式組件，該組件還充當控制平面。運營商配置流量策略時，會將其提交到控制平面，控制平面將該策略推送到代理中以影響流量。軟件可靠性工程師（SRE）利用服務網格的可觀察性來深入瞭解應用程序。

服務網格與現有的API網關或Kubernetes入口控制器集成在一起。 API網關和入口處理南北流量時，服務網格負責東西向流量。

總而言之，服務網格是實現安全的服務到服務通信的基礎結構層。它依賴於與每個微服務一起部署的輕量級網絡代理。集中式控制平面協調代理以管理流量策略，安全性和可觀察性。

即使服務網格主要與打包為容器的微服務一起使用，它也可以與VM甚至物理服務器集成。通過有效利用服務網格的流量策略，可以無縫集成跨多個環境運行的應用程序。這個因素使服務網格成為混合雲和多雲的關鍵推動因素之一。

有多種服務網格可供企業選擇。本文試圖幫助比較和對比雲原生生態系統中可用的一些主流服務網格平台。

AWS App Mesh

AWS App Mesh在AWS re：Invent 2018上推出，旨在將服務網格的優勢帶到Amazon Web Services的計算和容器服務中。可以使用Amazon EC2，Amazon ECS，AWS Fargate，Amazon EKS甚至AWS Outposts輕鬆配置它。

由於App Mesh可以充當VM和容器的服務網格，因此Amazon基於虛擬服務，虛擬節點，虛擬路由器和虛擬路由創建了一個抽象層。

虛擬服務代表部署在VM或容器中的實際服務。虛擬服務的每個版本都映射到一個虛擬節點。虛擬服務和虛擬節點之間存在一對多關係。部署新版本的微服務後，只需將其配置為虛擬節點即可。類似於網絡路由器，虛擬路由器充當虛擬節點的端點。虛擬路由器具有一條或多條遵循流量策略和重試策略的虛擬路由。網格對象充當所有相關實體和服務的邏輯邊界。

代理與參與網格的每個服務相關聯，該代理處理網格內流動的所有流量。

假設我們在AWS中運行兩項服務：servicea.apps.local和serviceb.apps.local。

我們可以輕鬆地啓用這些服務的網格，而無需修改代碼。

我們注意到，serviceb.apps.local具有虛擬服務，一個虛擬節點，一個具有兩個虛擬路由的虛擬路由器，這些虛擬路由決定了發送到微服務的v1和v2的流量的百分比。

與大多數服務網格平台一樣，AWS App Mesh也依賴於開源Envoy代理數據平面。 App Mesh控制平面在構建時考慮了AWS計算服務。亞馬遜還定製了Envoy代理以支持此控制平面。

將AWS App Mesh與Amazon EKS結合使用時，您將獲得自動sidecar注入的好處以及在YAML中定義App Mesh實體的能力。亞馬遜為EKS構建了CRD，以簡化帶有標準Kubernetes對象的App Mesh的配置。

AWS App Mesh生成的遙測可以與Amazon CloudWatch集成。指標可以導出到第三方服務（例如Splunk，Prometheus和Grafana）以及開放式跟蹤解決方案（例如Zipkin和LightStep）。

對於使用AWS計算服務的客户，AWS App Mesh是免費的。 AWS App Mesh不收取任何額外費用。

Consul Connect

HashiCorp的Consul作為具有內置鍵/值數據庫的服務發現平台而啓動。它充當在同一主機或分佈式環境中運行的服務的高效，輕量級負載均衡器。Consul公開用於發現註冊服務的DNS查詢接口。它還對所有註冊的服務執行健康檢查。

在容器和Kubernetes成為主流之前就已經創建了Consul。但是微服務和服務網格的興起促使HashiCorp將Consul擴展為功能完善的服務網格平台。服務網格擴展Consul Connect使用相互傳輸層安全性（TLS）提供服務到服務的連接授權和加密。

有關實施Consul的詳細説明和分步指南，請參閲我的Consul Service Discovery和Consult Connect教程。

由於sidecar模式是服務網格的首選方法，因此Consul Connect帶有自己的代理來處理入站和出站服務連接。基於插件體系結構，Envoy可以用作Consul Connect的替代代理。

Consul Connect向Consul添加了兩個基本功能-安全性和可觀察性。

默認情況下，Consul將TLS證書添加到服務端點以實現相互TLS（mTLS）。這樣可以確保始終對服務之間的通信進行加密。安全策略是通過intentions實現的，這些intentions定義了服務的訪問控制並用於控制哪些服務可以建立連接。intentions可以拒絕或允許來自特定服務的流量。例如，數據庫服務可以拒絕直接來自Web服務的入站流量，但允許通過業務邏輯服務發出的請求。

當Envoy用作Consul Connect的代理時，它將利用L7的可觀察性功能。可以將與Consul Connect集成的Envoy配置為將遙測發送到各種來源，包括statsd，dogstatsd和Prometheus。

根據上下文，Consul可以充當客户端（代理）或服務器，當與Nomad和Kubernetes等編排器集成時，它支持Sidecar注入。有一張Helm chart可以在Kubernetes中部署Consul Connect。 Consul Connect配置和元數據作為註釋添加到提交給Kubernetes的pod規範中。它可以與Ambassador集成，後者是Datawire的入口控制器，用於處理南北向流量。

Consul缺乏用於實施藍/綠部署或Canary版本的高級流量路由和拆分功能。與其他服務網格選擇相比，它的安全流量策略不是很靈活。通過Envoy的集成，可以配置一些高級路由策略。但是，Consul Connect沒有為此提供接口。

總體而言，Consul和Consul Connect是健壯的服務發現和網格平台，易於管理。

Istio

Istio是由Google，IBM和Red Hat支持的最受歡迎的開源服務網格平台之一。

Istio還是最早使用Envoy作為代理的服務網格技術之一。它遵循與微服務關聯的集中式控制平面和分佈式數據平面的標準方法。

儘管Istio可以與虛擬機一起使用，但是它主要與Kubernetes集成。可以將部署在特定名稱空間中的Pod配置為具有自動sidecar注入功能，其中Istio會將數據平面組件附加到Pod。

Istio為微服務開發人員和運營商提供了四種主要功能：

• 流量管理：Istio簡化了諸如斷路器，超時和重試之類的服務級別屬性的配置，並使其易於實現基於百分比的流量拆分的配置，如A/B測試，canary部署和分段式部署。它還提供了開箱即用的故障恢復功能，有助於使您的應用程序更強大，以防止相關服務或網絡的故障。 Istio帶有自己的Ingress，可處理南北向流量。
• 擴展性：WebAssembly 是一種沙盒技術，可以用於擴展 Istio 代理（Envoy）的能力。Proxy-Wasm 沙盒 API 取代了 Mixer 作為 Istio 主要的擴展機制。在 Istio 1.6 中將會為 Proxy-Wasm 插件提供一種統一的配置 API。
• 安全：Istio為服務內通信提供了開箱即用的安全功能。它提供了基礎安全通信通道，並大規模管理服務通信的身份驗證，授權和加密。藉助Istio，默認情況下就可以保護服務通信，從而使開發人員和操作員可以在各種協議和運行時之間一致地執行策略，而無需更改代碼或配置。
• 可觀察性：由於Istio的數據平面攔截了入站和出站流量，因此可以瞭解當前的部署狀態。 Istio提供了強大的跟蹤，監視和日誌記錄功能，可深入瞭解服務網格部署。 Istio帶有集成的和預先配置的Prometheus和Grafana儀表板，以提高可觀察性。

Google和IBM將託管的Istio作為其託管Kubernetes平台的一部分提供。 Google將Knative構建為基於Istio的無服務器計算環境。對於Anthos和Cloud Run等Google服務，Istio已成為其核心基礎。與其他產品相比，Istio被認為是一個複雜而繁重的服務網格平台。但是可擴展性和豐富的功能使其成為企業的首選平台。

Kuma

Kuma於2019年9月啓動，是服務網格生態系統的最新參與者之一。它是由API網關公司Kong，Inc開發和維護的，該公司以相同的名稱Kong來構建開源和商業產品。

Kuma是對Kong API網關的邏輯擴展。前者處理南北流量，而後者處理東西向流量。

像大多數服務網格平台一樣，Kuma帶有單獨的數據平面和控制平面組件。控制平面是服務網格的核心支持者，它支持所有服務配置的基本原理，並且可以無限擴展以管理整個組織中的成千上萬的服務。 Kuma將快速數據平面與高級控制平面相結合，允許用户通過Kubernetes或REST API中的自定義資源定義（CRD）輕鬆設置權限，公開指標並設置路由策略。

Kuma的數據平面與Envoy代理緊密集成，使數據平面可以在Kubernetes中部署的虛擬機或容器中運行。 Kuma有兩種部署模式：

1）通用
2）Kubernetes。

在Kubernetes中運行時，Kuma利用API服務器和etcd數據庫存儲配置。在通用模式下，它需要外部PostgreSQL作為數據存儲。

控制平面組件Kuma-cp管理一個或多個數據平面組件kuma-dp。在網格上註冊的每個微服務都運行kuma-dp的唯一副本。在Kubernetes中，kuma-cp在kuma系統名稱空間內作為CRD運行。為kuma註釋的名稱空間可以將數據平面注入每個pod中。

Kuma附帶了一個GUI，可提供部署概述，包括向控制平面註冊的每個數據平面的狀態。可以使用相同的界面查看來自附加到微服務的代理的運行狀況檢查，流量策略，路由和跟蹤。

Kuma服務網格具有內置的CA，用於基於mTLS加密流量。可以基於與微服務關聯的標籤來配置流量許可。跟蹤可以與Zipkin集成，而指標可以重定向到Prometheus。

Kuma缺少一些先進的彈性功能，例如斷路，重試，故障注入和延遲注入。

Kuma是精心設計的乾淨的服務網格實現。它與Kong Gateway的集成可能會推動其在現有用户和客户中的採用。

Linkerd 2.x

Linkerd 2.x是Buoyant專為Kubernetes構建的開源服務網格。它獲得了Apache V2的許可，並且是一個Cloud Native Computing Foundation孵化項目。

Linkerd是一個超輕便，易於安裝的服務網格平台。它具有三個組件– 1）CLI和UI，2）控制平面和3）數據平面。

一旦將CLI安裝在可以與Kubernetes羣集通信的計算機上，就可以使用單個命令安裝控制平面。控制平面的所有組件都作為Kubernetes部署安裝在linkerd名稱空間中。 Web和CLI工具使用控制器的API服務器。目標組件將路由信息告知運行數據平面的代理。注入器是Kubernetes准入控制器，每次創建Pod時都會接收Webhook請求。該服務用於將代理作為sidecar注入到命名空間中啓動的每個pod。身份組件負責管理對實現代理之間的mTLS連接至關重要的證書。點擊組件從CLI和Web UI接收請求，以實時監視請求和響應。

Linkerd隨附了預配置的Prometheus和Grafana組件，提供了現成的儀表板。

數據平面具有輕量級代理，可將其作為輔助工具附加到服務。有一個Kubernetes初始化容器來配置iptables來定義流量，並將代理連接到控制平面。

Linkerd符合服務網格的所有屬性-流量路由/拆分，安全性和可觀察性。

有趣的是，Linkerd並未使用Envoy作為代理。相反，它依賴於用Rust編程語言編寫的專用輕量級代理。 Linkerd的堆棧中沒有內置入口，但可以與入口控制器配合使用。

在Istio之後，Linkerd是流行的服務網格平台之一。考慮到輕量級且易於使用的服務網格，它吸引了開發人員和運營商的注意力。

Maesh

Maesh來自於Containous，該公司建立了流行的 ingress Traefik。與Kong，Inc類似，Containous建立了Maesh以補充Traefik。當Maesh處理微服務中的東西向流量時，Traefik則驅動着南北向流量。與Kuma一樣，Maesh也可以與其他入口控制器一起使用。

與其他服務網格平台相比，Maesh採用了不同的方法。它不使用邊車模式來操縱流量。相反，它為每個Kubernetes節點部署了一個Pod，以提供定義良好的服務端點。即使部署了Maesh，微服務也可以繼續工作。但是，當他們使用Maesh公開的替代終結點時，他們可以利用服務網格功能。

Maesh的目標是提供一種非侵入性和非侵入性的基礎架構，為開發人員提供選擇功能。但這也意味着該平台缺少某些關鍵功能，例如透明TLS加密。

Maesh支持服務網格的基本功能，包括路由和可觀察性（安全性除外）。它支持Service Mesh Interface（SMI）項目定義的最新規範。

在我在Kubernetes中部署的所有服務網格技術中，我發現Maesh是最簡單，最快的平台。