服務網格可以做從服務發現到零信任安全、負載均衡、多雲連接配接、自動化和南北流量的所有事情。
即使服務網格的采用持續增長，一些組織仍在嘗試全面了解服務網格可以做什麼和不能做什麼。
他們可能沒有意識到服務網格不僅是一種單一用途的工具，而且可以滿足各種網絡需求。服務網格實際上可能有助于整合多個現有工具，以幫助減少管理工作和成本。
看看這兩種多雲網絡架構：
哪個看起來不那麼複雜？
如果您選擇的服務網格與雲無關，則可以大大簡化多雲架構。不僅如此，許多服務網格産品還包括服務發現、安全的服務到服務通信、負載均衡功能以及包含漸進式傳遞模式的 L7 和 L4 網絡管理功能。
其他一些服務網格産品進一步擴充以提供多雲/多運作時連接配接、網絡基礎設施自動化和南北流量控制。讓我們看一下與雲無關的服務網格的功能，以及它在跨環境整合現有工具以減少開支方面的潛力。
服務發現
服務發現允許開發人員編目和跟蹤其網絡上所有已注冊服務的網絡位置和健康狀況。在服務不斷擴大和縮小的動态環境中，這是一項重要的能力。這通常是服務網格采用之旅的第一步。
有很多方法可以獲得服務發現能力。但 Kubernetes、Amazon EKS、Azure AKS、Google GKE 或 AWS 雲地圖和配置管理資料庫 (CMDB) 等服務發現工具中内置的常用功能通常特定于它們所運作的平台或雲。他們可以發現的服務範圍僅限于其特定平台或雲的邊界。然而，今天，大多數組織跨多個平台或雲環境運作應用程式，這意味着他們需要學習、安裝和管理多個服務發現解決方案。
更好的方法是可以跨越多個運作時的與雲無關的服務網格。例如，HashiCorp Consul是一個不可知的服務網格，包括對 Kubernetes、虛拟機、Amazon ECS 和 HashiCorp Nomad 的支援，允許組織跨多個異構環境集中全局服務發現。
通過将服務發現整合到服務網格中，平台團隊可以将服務發現作為全局共享服務提供，與依靠單個團隊在沒有任何監督的情況下運作和管理自己的服務發現工具相比，這可以降低成本、提高合規性并簡化管理。
零信任網絡
組織不再僅僅依賴于保護網絡邊界的傳統方法，而是越來越多地尋求零信任網絡來保護他們的網絡和基礎設施。
與依賴于防禦現代雲環境中可能不存在的邊界的傳統城堡和護城河安全方法不同，零信任安全認為任何服務（無論是在邊界内部還是外部）都不應被授予通路權限，直到它被授權和身份驗證，所有通信都經過加密。
應用身份驗證、授權和加密的零信任網絡原則是服務網格的主要功能。服務網格通過代理（通常是Envoy）自動重定向服務之間的入口和出口流量。這允許将授權、身份驗證和加密職責轉移到代理上。
服務網格使用服務身份而不是 IP 位址作為允許或拒絕授權的機關，極大地簡化了服務到服務通信的管理。
管理者可以配置一個單一的拒絕所有政策，該政策将由代理強制執行，以阻止所有服務到服務的通信。開發人員可以添加更精細的政策來授權特定服務根據需要進行通信。
服務網格代理還将確定所有服務到服務的通信都自動進行身份驗證和加密。在進行任何服務通信之前，代理會確定交換 TLS 證書并加密網絡上的所有流量。這導緻網絡更加安全，即使在發生網絡破壞後也能防止服務之間的橫向移動。
最後，服務網格通過為管理者和開發人員提供在開發周期早期授權、驗證和加密其網絡服務的能力，從本質上幫助組織左移，通過左移，組織可以在投入生産之前降低由于不可預見的安全漏洞而導緻的最後一分鐘延誤的風險。此外，使用服務網格向左移動使網絡管理者可以專注于保護網絡邊界，而不是管理單個 IP 位址。
服務網格是網絡管理者的力量倍增器和抽象層，允許開發人員專注于他們的應用程式而不是安全邏輯，并避免管理和輪換證書和密鑰的麻煩。
負載均衡
由于服務網格上的資料流量流經代理，服務網格還可以控制流量整形等功能。一個簡單的例子是服務的多個執行個體之間的負載均衡。服務網格允許自定義流量模式直接在執行個體之間分布，而不是通過單獨的負載均衡裝置進行額外的網絡躍點。即使執行個體向上或向下擴充，服務網格也可以動态調整流量分布。使用服務網格可以大大降低跨多個不同環境和雲管理多個不同負載均衡裝置的成本和複雜性。
這是一個傳統的負載均衡拓撲，在服務 A 與服務 B 對話之前，負載均衡器有一個額外的網絡躍點：
在像 Consul 這樣的服務網格中，沒有額外的躍點，因為 sidecar 代理直接通信并且 Consul 集中管理每個代理之間的流量平衡：
多雲連接配接
許多組織擁有分散在給定雲的不同網絡和區域中的不同團隊和服務。許多還跨多個雲環境部署服務。跨不同雲網絡安全地連接配接這些服務是一項非常理想的功能，通常需要網絡團隊付出大量努力。此外，要求子網之間不重疊的無類域間路由 (CIDR) 範圍的限制可能會阻止虛拟私有雲 (VPC) 和虛拟網絡 (VNET) 之間的網絡連接配接。服務網格産品可以安全地連接配接在不同雲網絡上運作的服務，而無需付出同樣的努力。
例如，HashiCorp Consul 支援多資料中心拓撲，該拓撲使用網狀網關在跨雲的不同網絡中運作的多個 Consul 部署之間建立安全連接配接。團隊 A 可以在 EKS 上部署 Consul 叢集。團隊 B 可以在 AKS 上部署一個獨立的 Consul 叢集。團隊 C 可以在私有的内部資料中心的虛拟機上部署 Consul 叢集。可以在三個 Consul 叢集之間建立多資料中心配置，允許在 EKS、AKS 和虛拟機之間運作的服務進行安全連接配接，而無需額外的網絡配置(如 vpn、Direct Connects 或 ExpressRoutes)。Consul 網狀網關允許将多個 Consul 部署叢集化，即使 IP 範圍在網絡中重疊。
自動化
自動化在動态環境中尤其有利。波動的需求要求營運商擴充服務執行個體的數量，這是一項相當微不足道的任務。但是，可能需要更新網絡防火牆、負載均衡器或其他網絡基礎設施，才能通路新執行個體。類似地，新的應用程式服務可能需要更新網絡裝置，然後用戶端才能通路它們。
由于大多數組織都有獨立的網絡和安全團隊，是以這些工作流程通常涉及網絡裝置更新的手動工單請求，這可能需要數小時甚至數天才能完成。縮減或停用服務可能會導緻額外的問題。這是因為網絡團隊從網絡裝置中删除 IP 位址的請求很容易被忽視，進而導緻潛在的安全漏洞。
為了應對這些挑戰，一些服務網格與 HashiCorp Terraform 等基礎設施供應工具建立了獨特的內建。Consul 與 Terraform 具有獨特的內建，可以自動觸發網絡裝置更新和重新配置。營運商可以配置Consul-Terraform-Sync (CTS)以根據 Consul 目錄中服務的更改自動更新防火牆和負載均衡器等裝置。自動化這些任務減少了對手動票務系統的依賴，提高了工作流程效率，并加強了組織的安全狀況。
南北交通管制
除了在組織網絡内的服務之間調整和路由流量外，還需要從外部用戶端提供對這些服務的通路。AWS API Gateway、Azure API Management 和 Google Cloud API Gateway 等雲原生選項對于不打算擴充到單一雲的組織來說可能是不錯的選擇。然而，對于在多個雲上運作的組織而言，在單個通用平台上進行标準化是有價值的。
一些不可知的服務網格，包括 Consul，有一個内置的API 網關，可以提供與雲原生選項類似的功能。這使組織可以使用一個一緻的管理平面來管理服務網格流量（東西向）以及來自外部用戶端（南北向）的流量，進而無需在不同環境中部署多個不同的 API 網關。
誰從服務網格的工具整合中受益？
如果服務網格可以幫助整合不同運作時之間的許多不同工具，那麼每個組織都應該将服務網格整合到他們的基礎設施中嗎？這取決于：
對于81% 已經使用或計劃使用多雲的組織而言，服務網格絕對可以幫助遏制工具的蔓延。
即使是緻力于單一雲提供商的組織也可能要處理由不同開發團隊選擇的不同運作時。對服務網格進行标準化以提供全局服務發現、零信任網絡和負載均衡也可以幫助這些組織減少工具蔓延。像 Consul 這樣的服務網格可以通過内置特性提供進一步的工具整合，以連接配接雲之間的服務、自動化網絡裝置更新以及控制外部用戶端對服務的通路。