看看服務網格可以做的所有事情

服務網格的採用率持續增長，一些組織仍在試圖全面瞭解服務網格可以做什麼和不能做什麼。

他們可能沒有意識到服務網格不僅僅是另一個單一用途的工具，而是一個能夠滿足各種網路需求的工具。服務網格實際上可能有助於整合多個現有工具，以幫助減少管理工作量和成本。

看看這兩種多雲網路架構。

將網路服務和安全相關功能自動化並解除安裝到與雲無關的服務網格上，可以幫助簡化多雲環境中的管理。

使用雲供應商特定網路解決方案的多雲架構：

使用雲不可知服務網格：

許多服務網格產品包括服務發現、零信任網路和負載均衡功能，而其他一些服務網格產品則進一步擴充套件，以提供多雲/多執行時連線、網路自動化和南北流量控制。讓我們看看雲不可知服務網格的功能，以及它在跨環境整合現有工具以幫助減少管理工作和費用方面的潛力。

服務發現

服務發現允許開發人員對其網路上所有註冊服務的網路位置和執行狀況進行編目和跟蹤。在服務不斷增加和減少的動態環境中，它是一種重要的功能。這通常是為網格應用服務的第一步。

有許多方法可以獲得服務發現功能。但Kubernetes、Amazon EKS、Azure AKS、Google GKE或AWS Cloud Map和Configuration Management Database(CMDB)等服務發現工具中內建的常用功能通常特定於其執行的平臺或雲。它們可以發現的服務範圍僅限於其特定平臺或雲的邊界。然而，如今，大多陣列織跨多個平臺或雲環境執行應用程式，這意味著需要學習、安裝和管理多個服務發現解決方案。

更好的方法是一個可以跨多個執行時的雲不可知服務網格。例如，HashiCorp Consor是一個不可知服務網格，包括對Kubernetes、虛擬機器、Amazon ECS和HashiCorp Nomad的支援，允許組織跨多個異構環境集中全域性服務發現。

透過將服務發現整合到服務網格中，平臺團隊可以將服務發現作為全球共享服務提供，與依靠單個團隊在沒有任何監督的情況下執行和管理自己的服務發現工具相比，降低了成本，提高了合規性並簡化了管理。

零信任網路

組織越來越多地尋求零信任網路來保護其網路和基礎設施，而不是僅僅依靠傳統的方法來保護網路外圍。

與傳統的城堡和護城河安全方法不同(依賴於保護在現代基於雲的環境中可能不存在的外圍)，零信任安全認為，在授權和驗證之前，不應授予任何服務訪問許可權，無論是在外圍內部還是外部，並且所有通訊都是加密的。

應用身份驗證、授權和加密的零信任網路原則是一種主要的服務網格功能。服務網格透過代理(通常是代理)自動重定向服務之間的進出流量。這允許將授權、身份驗證和加密責任轉移到代理上。

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

管理員可以配置將由代理強制執行的單個拒絕所有策略，以阻止所有服務到服務的通訊。開發人員可以新增更細粒度的策略，以授權特定服務根據需要進行通訊。

服務網格代理還將確保所有服務對服務通訊自動進行身份驗證和加密。在任何服務通訊之前，代理確保交換TLS證照，並加密網路上的所有流量。這導致了更安全的網路，即使在網路中斷髮生後，也可以防止服務之間的橫向移動。

最後，服務網格透過在開發週期的早期為管理員和開發人員提供授權、身份驗證和加密其網路服務的能力，從本質上幫助組織左移。透過向左移，組織可以在投入生產之前減少由於不可預見的安全漏洞而導致的最後一刻延遲的風險。此外，使用服務網格左移可以使網路管理員將精力放在保護網路外圍而不是管理單個IP地址上。

服務網格是網路管理員的力量倍增器，也是一個抽象層，允許開發人員專注於他們的應用程式，而不是安全邏輯，並避免管理和旋轉證照和金鑰的繁重工作。

負載均衡

由於服務網格上的資料流量流經代理，因此服務網格還可以控制流量整形等功能。一個簡單的例子是服務的多個例項之間的負載均衡。服務網格允許在例項之間直接分佈自定義流量模式，而不是透過單獨的負載均衡裝置進行額外的網路跳躍。即使在例項放大或縮小時，服務網格也可以動態調整流量分佈。使用服務網格可以大大降低跨多個不同環境和雲管理多個不同負載均衡裝置的成本和複雜性。

與：

多雲連線

許多組織擁有不同的團隊和服務，分佈在給定雲的不同網路和區域。許多公司還跨多個雲環境部署了服務。跨不同的雲網路安全地連線這些服務是一項非常理想的功能，通常需要網路團隊付出巨大努力。此外，子網之間需要非重疊無類域間路由(CIDR)範圍的限制可能會阻止虛擬專用雲(VPC)和虛擬網路(VNET)之間的網路連線。服務網格產品可以安全地連線在不同雲網路上執行的服務。

例如，HashiCorp-consu支援多資料中心拓撲，該拓撲使用網狀閘道器在跨雲執行的不同網路中的多個Consul部署之間建立安全連線。團隊A可以在EKS上部署一個Consul叢集。團隊B可以在AKS上部署一個單獨的Consul叢集。團隊C可以在私有內部資料中心的虛擬機器上部署Consul叢集。可以在三個Consul叢集之間建立多資料中心配置，允許EKS、AKS和虛擬機器之間執行的服務安全連線，而無需額外的網路配置，如VPN、Direct Connect或ExpressRoutes。即使IP範圍跨網路重疊，Consul網格閘道器也允許對多個Consul部署進行叢集。

自動化

自動化在動態環境中尤其有利。波動的需求要求運維人員擴充套件服務例項的數量，這是一項相當簡單的任務。然而，可能需要更新網路防火牆、負載均衡器或其他網路基礎設施，以便可以訪問新例項。類似地，新的應用程式服務可能需要更新網路裝置，然後客戶端才能訪問它們。

由於大多陣列織都有獨立的網路和安全團隊，因此這些工作流通常涉及手動申請網路裝置更新，可能需要數小時甚至數天才能完成。縮減服務規模或使其退役可能會導致更多的擔憂。這是因為網路團隊從網路裝置中刪除IP地址的請求很容易被忽略，從而導致潛在的安全漏洞。

為了應對這些挑戰，一些服務網格與基礎設施配置工具(如HashiCorp Terraform)構建了獨特的整合。Consul與Terraform具有獨特的整合，可以自動觸發網路裝置更新和重新設定。運維人員可以配置Consu Terraform Sync(CTS)，根據Consul目錄中服務的變化自動更新防火牆和負載均衡器等裝置。這些任務的自動化減少了對手動系統的依賴，提高了工作流效率，並加強了組織的安全態勢。

南北流量管制

除了在組織網路內的服務之間整形和路由流量外，還需要提供從外部客戶端對這些服務的訪問。對於不打算擴充套件到單個雲之外的組織來說，雲原生選項(如AWS API Gateway、Azure API Management和Google Cloud API Gateway)可能是不錯的選擇。然而，對於在多個雲上執行的組織來說，在單個公共平臺上進行標準化是有價值的。

包括Consul在內的一些不可知服務網格具有內建API閘道器，可以提供與雲原生選項類似的功能。這使組織可以使用一個一致的管理平面來管理服務網格流量(東西)內的流量以及來自外部客戶端(南北)的流量，從而無需跨不同環境部署多個不同的API閘道器。

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

如果服務網格可以幫助整合不同執行時之間的許多不同工具，那麼每個組織是否應該將服務網格合併到其基礎架構中?那要看情況了。

對於86%已經在或計劃在多個雲中的組織來說，服務網格無疑可以幫助遏制工具的蔓延。

即使是專注於單個雲提供商的組織也可能要處理不同開發團隊選擇的不同執行時。在服務網格上標準化以提供全域性服務發現、零信任網路和負載均衡，也可以幫助這些組織減少工具擴充套件。像Consul這樣的不可知服務網格可以透過內建功能提供進一步的工具整合，以連線雲之間的服務，自動化網路裝置更新，並控制對外部客戶端服務的訪問。

雖然一些較小的組織可能看不到工具的顯著整合，但至少，他們仍然可以透過採用服務網格作為力倍增器來受益，以改善其整體安全態勢，而不會對開發人員、平臺工程師或網路工程師施加額外的努力。