?譯者 | 布加迪

審校 | 孫淑娟

下面看看這兩種多云網絡架構。實現網絡服務和安全相關功能自動化，并將這些功能卸載到與云無關的服務網格上，就有助于簡化多云環境的管理。

針對特定云供應商的網絡解決方案的多云架構：

圖1

與云無關的服務網格：

圖2

許多服務網格產品包括服務發現、零信任網絡和負載均衡功能，其他一些服務網格產品甚至更進一步，提供多云/多運行時環境連接、網絡自動化和南北流量控制。不妨看一下與云無關的服務網格的功能，及其跨環境整合現有工具以幫助減少管理工作和成本的潛力。

服務發現

服務發現讓開發人員可以登記和跟蹤其網絡上所有已注冊服務的網絡位置和健康狀況。在服務不斷增加或減少的動態環境中，這是一項重要的功能。這常常是向采用服務網格邁出的第一步。

有很多方法可以獲得服務發現功能。但Kubernetes、Amazon EKS、Azure AKS、Google GKE或服務發現工具（比如AWS Cloud Map和配置管理數據庫即CMDB）中內置的常用功能通常是它們在其中運行的平臺或云所特有的。它們可以發現的服務范圍局限于其特定平臺或云的邊界。然而，如今大多數組織在多個平臺或云環境上運行應用程序，這意味著它們需要學習、安裝和管理多個服務發現解決方案。

更好的方法是可以跨越多個運行時環境的與云無關的服務網格。比如說，HashiCorp Consul是一種中立的服務網格，支持Kubernetes、虛擬機、Amazon ECS和HashiCorp Nomad，允許組織跨多個異構環境集中處理全球服務發現。

如果將服務發現整合到服務網格中，平臺團隊可以將服務發現作為全球共享服務來提供，與依靠各個團隊在沒有任何監督的情況下運行和管理各自的服務發現工具相比，可以降低成本、改進合規并簡化管理。

零信任網絡

組織不再僅僅依賴保護網絡邊界的傳統方法，而是日益尋求零信任網絡來保護其網絡和基礎設施。

不像傳統的城堡和護城河安全方法有賴于防護現代云環境中可能不存在的邊界，零信任安全認為，任何服務（無論在邊界內部還是外部）都不應被授予訪問權限，除非它獲得授權和身份驗證，所有通信都經過加密。

運用零信任網絡的幾個原則：身份驗證、授權和加密是服務網格的主要功能。服務網格通過代理（通常是Envoy）自動重定向服務之間的進出流量。這可以將授權、身份驗證和加密等任務扔給代理。

服務網格使用服務身份而不是IP地址作為允許或拒絕授權的單位，極大地簡化了管理服務到服務通信的工作。

管理員可以配置將由代理強制執行的一概拒絕的單一策略，以阻止所有服務到服務的通信。開發人員可以添加更精細化的策略，根據需要授權特定服務進行通信。

服務網格代理還將確保所有服務到服務的通信都自動進行身份驗證和加密。在進行任何服務通信之前，代理確保交換TLS證書，并加密網絡上的所有流量。這帶來了更安全的網絡，即使在發生網絡安全事件后也能防止服務之間的橫向移動。

最后，服務網格讓管理員和開發人員能夠在開發周期早期授權、驗證和加密其網絡服務，天生幫助組織向左移（shift left）。通過向左移，組織可以降低在部署到生產環境之前因不可預見的安全漏洞而導致最后一刻鐘延誤的風險。此外，使用服務網格向左移使網絡管理員可以專注于保護網絡邊界，而不是管理單個IP地址。

服務網格是網絡管理員的力量倍增器，也是抽象層，好讓開發人員專注于其應用程序、而不是安全邏輯，并避免管理和輪換證書和密鑰帶來的麻煩。

負載均衡

由于服務網格上的數據流量流經代理，服務網格還可以控制流量整形等功能。一個簡單的例子是服務的多個實例之間的負載均衡。服務網格允許自定義流量模式直接在實例之間分布，而不是通過不同的負載均衡設備完成額外的網絡跳躍（hop）。即使實例增加或減少，服務網格也可以動態調整流量分布。使用服務網格可以大大降低跨多個不同環境和云管理多個不同負載均衡設備的成本和復雜性。

圖3

對比：

圖4

多云連接

許多組織的不同團隊和服務分散在不同網絡和某個云的多個區域。許多組織的服務還部署在多個云環境上。跨不同云網絡安全地連接這些服務是一項大受歡迎的功能，通常需要網絡團隊花很大的精力。此外，要求子網之間無類域間路由（CIDR）范圍不重疊的限制可能會阻止虛擬專用云（VPC）和虛擬網絡（VNET）之間的網絡連接。服務網格產品可以安全地連接在不同云網絡上運行的服務，無需花一樣大的精力。

比如說，HashiCorp Consul支持多數據中心拓撲結構，該拓撲結構使用網狀網關在跨云的不同網絡中運行的多個Consul部署環境之間建立安全連接。A團隊可以在EKS上部署Consul集群。B團隊可以在AKS上部署單獨的Consul集群。C團隊可以在專有本地數據中心的虛擬機上部署Consul集群。可以在這三個Consul集群之間建立多數據中心配置，從而為在EKS、AKS和虛擬機之間運行的服務提供安全連接，無需額外的網絡配置，比如VPN、Direct Connect或ExpressRoute。即使IP范圍在網絡之間出現重疊，Consul網狀網關也允許對多個Consul部署環境進行集群。

自動化

自動化在動態環境中尤其有利。波動的需求要求操作人員擴展服務實例的數量，這是比較簡單的任務。然而，可能需要更新網絡防火墻、負載均衡系統或其他網絡基礎設施，才能訪問新實例。同樣，新的應用程序服務可能需要更新網絡設備，然后客戶端才能訪問它們。

由于大多數組織都有獨立的網絡團隊和安全團隊，這種工作流程常常需要手動提交工單，請求更新網絡設備，這可能需要數小時甚至數天才能完成。縮減或停用服務可能導致另外的問題。這是由于很容易忽視要求網絡團隊從網絡設備中刪除IP地址的請求，從而導致潛在的安全漏洞。

為了應對這些挑戰，一些服務網格與HashiCorp Terraform等基礎設施配置工具建立了獨特的集成。Consul與Terraform有獨特的集成，可以自動觸發網絡設備更新和重新配置。操作人員可以配置Consul-Terraform-Sync（CTS），根據Consul目錄中的服務出現的更改，自動更新防火墻和負載均衡系統等設備。自動處理這些任務減少了對手動工單系統的依賴，提高了工作流程效率，并加強了組織的安全狀況。

南北流量控制

除了在組織網絡內的服務之間整形和路由流量外，還需要確保可以從外部客戶端訪問這些服務。如果組織不打算擴展到單一云之外的云環境，AWS API Gateway、Azure API Management和Google Cloud API Gateway等云原生方案可能是不錯的選擇。對于在多個云上運行的組織而言，統一使用單個通用平臺有其價值。

一些與云無關的服務網格（包括Consul）有內置的API網關，可以提供與云原生方案相似的功能。這讓組織可以使用一個統一的管理平面來管理服務網格內部的流量（東西向）以及來自外部客戶端的流量（南北向），因而不需要在不同環境上部署多個不同的API網關。

誰從服務網格的工具整合中受益？

既然服務網格有助于整合不同運行時環境之間的許多不同工具，是不是每家組織都應該將服務網格整合到基礎設施中？這要看情況。

對于86%的已經使用或計劃使用多個云的組織而言，服務網格絕對有助于遏制工具散亂現象。

就連致力于單一云提供商的組織也可能在處理不同的開發團隊選擇的不同運行時環境。統一使用服務網格以提供全球服務發現、零信任網絡和負載均衡等功能，也能幫助這些組織緩解工具散亂現象。Consul等與云無關的服務網格可以通過內置功能提供進一步的工具整合，以連接云之間的服務、自動實現網絡設備更新以及控制來自外部客戶端的服務訪問。

雖然一些小組織可能看不到整合工具的顯著意義，但至少可以得益于采用服務網格作為力量倍增器，從而改善整體安全狀況，不需要開發人員、平臺工程師或網絡工程師花另外的精力。

原文標題：??All the Things a Service Mesh Can Do???，作者：Van Phan?