服務網格平臺探索性指南

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

開發人員須要確保跨服務的通訊是安全的。他們還須要實施分佈式跟蹤，以告知每次調用須要多長時間。重試，斷路器等分佈式服務的一些最佳實踐爲服務帶來了彈性。微服務一般是多語言的，並使用不一樣的庫和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是最簡單，最快的平臺。