服務網格怎么實現

發布時間： 2021-07-22 09:40:52

服務網格怎么實現？“服務網格( Service Mesh )”是時下最流行的應用微服務基礎架構，它的核心功能是實現微服務實例之間的互聯和互通。

Istio 是最著名的服務網格開源項目，它支持多集群Kubernetes ，但大多數部署與 Kubernetes 集群是一對一的關系，多個集群之間不可避免地存在著“網隔”。

VMware Tanzu Service Mesh(簡稱 TSM )與NSX的全局名稱服務( GSLB )相結合，可以將多個云和應用程序聯合以連接彼此隔離的服務集群。因此，不妨將 VMware 的 TSM 解釋為“ Terminator of Seperated Mesh ——網隔終結者 ”。

微服務和服務網格

Linux 容器和來自 Kubernetes 的容器編排的出現，通過高度自動化方法，大大提高了部署速度。單個服務可以打包為在 Kubernetes Pod 中運行的容器，并帶有各自的語言運行時，這就是“微”服務架構。

微服務架構，可以說是應用開發領域的“解耦合”革命，解耦之后的應用開發將更少受到特定基礎環境和資源的限制，但更加依賴服務之間的標準化、自動化、安全化的連接。

因為“微型化”和“解耦合”不是目的，新的架構的終極目標還是要將這些分散開發和部署的“微組件”進行更快、更好、更強的組合，形成可以面向最終用戶的應用和服務，并不斷迭代以適應最終用戶的新需求和新變化。

微服務是在以 Kubernetes 為基礎架構的平臺上發展并日益成熟的。Kubernetes 為復雜的分布式、多語言應用程序提供應用程序可用性、彈性和整體管理，提供基本的負載平衡，但不涉及在其 Pod 中運行的每個應用程序組件如何與其他組件連接和交互。

網絡是將微服務結合在一起以交付應用程序的粘合劑。微服務必須通過網絡進行大量通信——它是應用程序微服務之間的連接。Kubernetes 在網絡、安全和負載均衡方面，一直依賴于外部組件提供的服務。

“服務網格”( Service Mesh )應運而生，來填補“微服務連接”這個空白區間。從某種意義上，可以將 Serive Mesh 稱之為“連接即服務( Connection as a Service )”。

使用服務網格，我們可以將這些微服務之間所需的連接功能抽象為一個單獨的實體，稱為“代理”。“代理”位于每個微服務的前面，所有通信都通過它傳遞。“代理”負責連接詳細信息、流量管理、錯誤和故障處理以及出于可觀察性目的收集指標。

當“代理”與其他“代理”通信時，就會形成一個網格狀邏輯拓撲，這就是這個架構被稱為“服務網格”原因。在服務網格中，代理通過“ Sidecar ”來實現。容器在 Pod 中運行，其中的“ Sidecar ”充當主容器的“輔助容器”，主容器運行業務邏輯。

傳統上，企業網絡的設計和構建是為了提供冗余，但是微服務化的應用程序邏輯中增加了對網絡的依賴，網絡(以及應用程序)故障的可能性與應用程序所依賴的連接數量成正比。

圖1 服務網格采用 Sidecar 代理微服務之間的連接

VMware Tanzu Service Mesh

VMware 的Tanzu Service Mesh (以下簡稱為“TSM”)建立在 Istio 和 Envoy 等認可度高開源產品基礎之上。Istio 專注于服務，用戶可以從開源基礎中受益，并獲得服務的發現、連接、可觀察性和安全性等功能：

服務到服務通信

控制服務之間的流量和 API 調用

對服務通信實施授權和加密

服務的遙測數據(跟蹤、指標、日志)以實現可觀察性

除了 Istio 在單集群中提供的基礎功能之外，TSM 有能力為單云和多云環境中的應用程序提供端到端的連接性、連續性、彈性、安全性和可觀察性——為企業提供從應用程序最終用戶到微服務和數據的可見性和策略控制。TSM 的適用場景包括但不限于：

應用程序連續性：通過與 NSX 軟件定義的應用交付相集成，確保應用程序連續性，以支持多區域和多區域高可用性和災難恢復

應用程序彈性：通過自動自動擴展策略確保應用程序彈性，以實現多云應用程序的服務級別目標( SLO )

應用程序安全性：通過定義基于屬性的授權策略，來實現服務到服務的訪問控制，從而保護應用程序和數據

API安全性：增強跨應用程序最終用戶、微服務/ API 和敏感數據的 TSM 可見性和控制

圖2 TSM 總體架構

全局命名空間GNS

TSM 通過稱為全局命名空間(Global Namespace)的抽象層，使操作和集成工作負載變得更容易。該抽象層通過 TSM 與 NSX 的全局負載均衡( GSLB )功能相結合，允許企業跨云和工作負載連接、管理和保護應用程序。這提供了完整的服務和應用程序移動性。

全局命名空間 GNS 是 TSM 與其他服務網格產品的主要區別點之一。TSM 與 NSX GSLB 的結合，現在被稱為“ VMware Modern Apps Connectivity ” 解決方案。應用程序需要在混合傳統和微服務架構的多集群、多云環境中運行。在這種情況下，企業的平臺、基礎設施和運維團隊面臨著一系列多云環境下的需求和挑戰，包括但不限于：

職責分離(服務由不同業務部門開發)

將無狀態和有狀態服務分配到不同的 Kubernetes 集群

服務消費(使用一個云中的數據服務和不同云中的應用服務)

業務連續性

減小擴散半徑

使用 TSM 可以在 GNS 級別配置并啟用應用策略，例如基于高可用性、安全目標和流量分配目標的策略。以下是將 GNS 與不同集群上的 TSM 聯合使用的兩個場景。

例1 云爆發

隨著我們公共服務的流量增加(模擬數據達到峰值)，并且當本地站點(下圖中的 On-Prem )上的集群資源耗盡或超過某個閾值時，用戶現在可以觸發應用程序在云站點(下圖中的 Cloud )上的擴展部署(手動或由觸發自動部署)。

而且，由于在我們的設置云站點集群是相同的全局域名服務的一部分，在這個域名下添加新的服務節點，會自動觸發 TSM 更新 GSLB 配置，但新的服務節點指向到云上的集群，并根據 GSLB 配置的策略將流量轉移到新端點。