*作者：王夕寧*

> 本文內容基於作者在 2022 年雲原生產業大會上的演講內容整理而成。

## 背景

回顧下應用服務架構體系的演進。從服務呼叫方與提供方的處理方式來看, 可以分為 3 個階段。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/19d89f3356d944cb928b7a19a13d561b~tplv-k3u1fbpfcp-zoom-1.image "1.png")

第一個階段是**集中式負載均衡**, 也就是說服務呼叫方是透過一個外部的負載均衡路由到對應的服務提供方。其優勢顯而易見,  對應用本身無侵入, 可以支援多語言多框架來開發實現應用本身, 負載均衡統一集中管理, 整個部署簡單。但劣勢也非常顯著, 因為是集中式所以導致伸縮性受限, 同時這種集中式負載均衡的服務治理能力相對都較弱。

第二階段是指**微服務的分散式治理**, 即服務呼叫方內建治理能力, 以 SDK 庫的方式整合到應用中。帶來的優勢是整個伸縮性較好, 服務治理能力強, 但同時會注意到它的劣勢, 包括對應用本身的侵入、因為依賴於 SDK 所以導致對多語言支援比較困難、分散式管理部署帶來的複雜性等。

第三階段就是現在的**服務網格技術**。透過把這些服務治理的能力 Sidecar 化，就能夠把服務治理的能力與應用程式本身進行了解耦，可以較好地支援多種程式語言、同時這些 Sidecar 能力不需要依賴於某種特定技術框架。這些 Sidecar 代理形成一個網狀的資料平面，透過該資料平面處理和觀察所有服務間的流量。控制面對這些 Sidecar 代理進行統一管理。但因此帶來了一定的複雜度。

下圖是服務網格的架構圖。前面提到, 在服務網格技術下, 每一個應用服務例項都會伴隨了一個 Sidecar 代理, 業務程式碼不感知 Sidecar 的存在。這個 Sidecar 代理負責攔截應用的流量，並且提供流量治理、安全、可觀測三大功能。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/61a72304e07840c190f32cfd274eb01e~tplv-k3u1fbpfcp-zoom-1.image "2.png")

在雲原生應用模型中，一個應用程式可能會包含若干個服務，每個服務又有若干個例項構成，那麼這些成百上千個應用程式的 Sidecar 代理就形成了一個資料面, 也就是圖中的資料平面層。

而如何統一管理這些 Sidecar 代理, 這就是服務網格中的控制平面部分要解決的問題。控制平面是服務網格的大腦，負責為資料平面的 Sidecar 代理下發配置, 管理資料面的元件如何執行, 同時也為網格使用人員提供統一的 API，以便較容易地操縱網格管理能力。

通常來說, 啟用服務網格之後,  開發人員、運維人員以及 SRE 團隊將以統一的、宣告的方式解決應用服務管理問題。

## 服務網格加持下的雲原生應用基礎設施

服務網格作為一種用來管理應用服務通訊的基礎核心技術,  為應用服務間的呼叫帶來了安全、可靠、快速、應用無感知的流量路由、安全、可觀測能力。

可以看到, 服務網格加持下的雲原生應用基礎設施帶來了重要的優勢, 分為六個方面。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e32e9f5de4e7472290bb6360ab428e67~tplv-k3u1fbpfcp-zoom-1.image "3.png")

### 優勢之一：異構服務統一治理

• 多語言多框架的互通與治理、與傳統微服務體系融合的雙模架構

• 精細化的多協議流量控制、東西向與南北向流量的統一管理

• 統一的異構計算基礎設施的自動服務發現

### 優勢之二：端到端的可觀測

• 日誌、監控與跟蹤融合的一體化智慧運維

• 直觀易用的視覺化網格拓撲、基於顏色標識的健康識別體系

• 內建最佳實踐、自助式網格診斷

### 優勢之三：零信任安全

• 端到端 mTLS 加密、基於屬性的訪問控制 (ABAC)

• OPA 宣告式策略引擎、全域性唯一的工作負載身份（Identity）

• 帶有儀表板的完整審計歷史記錄及洞察分析

### 優勢之四：軟硬結合效能最佳化

• 首個基於 Intel Multi-Buffer 技術提升 TLS 加解密的服務網格平臺

• NFD 自動探測硬體特徵, 自適應支援諸如 AVX 指令集、QAT 加速等特性

• 首批透過可信雲服務網格平臺以及效能評測先進級認證

### 優勢之五：SLO 驅動的應用彈性

• 服務級別目標 (SLO) 策略

• 基於可觀測性資料的應用服務的自動彈性伸縮

• 多叢集流量突發下的自動切換與故障容災

### 優勢之六：開箱即用擴充套件&生態相容

• 開箱即用的 EnvoyFilter 外掛市場、WebAssembly 外掛全生命週期管理

• 與 Proxyless 模式的統一融合, 支援 SDK、核心 eBPF 方式

• 相容 Istio 生態系統, 支援 Serverless/Knative, AI Serving/KServe

下圖是服務網格 ASM 產品當前的架構。作為業內首個全託管 Istio 相容的服務網格產品 ASM，一開始從架構上就保持了與社群、業界趨勢的一致性，控制平面的元件託管在阿里雲側，與資料面側的使用者叢集獨立。ASM 產品是基於社群開源的 Istio 定製實現的，在託管的控制面側提供了用於支撐精細化的流量管理和安全管理的元件能力。透過託管模式，解耦了 Istio 元件與所管理的 K8s 叢集的生命週期管理，使得架構更加靈活，提升了系統的可伸縮性。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fe02be85417b4471a1a1c04ef08eed99~tplv-k3u1fbpfcp-zoom-1.image "5.png")

託管式服務網格 ASM 在成為多種異構型別計算服務統一管理的基礎設施中, 提供了統一的流量管理能力、統一的服務安全能力、統一的服務可觀測效能力、以及基於 WebAssembly 實現統一的代理可擴充套件能力, 以此構築企業級能力。

## 服務網格技術的下一站如何發展

Sidecar Proxy 與 Proxyless 模式的融合一句話來總結的話，就是**同一個控制面, 支撐不同的資料面形態**。同一個控制面就是指使用 ASM 託管側元件作為統一的標準形式的控制入口,  這個控制面執行在阿里雲側，屬於 hosted 託管模式。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dce2e87de82645088b00916c969b96e3~tplv-k3u1fbpfcp-zoom-1.image "6.png")

而資料面支援 Sidecar Proxy 與 Proxyless 模式的融合, 其中資料面的元件雖然不是 hosted 託管模式, 但是也是 managed 模式, 也就是說這些元件的生命週期也是由 ASM 統一來管理, 包括分發到資料面、升級、解除安裝等。

具體來說, 在 Sidecar Proxy 模式下, 除了當前標準的Envoy代理之外, 我們的架構可以比較容易地支援其他 Sidecar, 譬如說 Dapr Sidecar, 當前微軟 OSM+Dapr 就是採用了這種雙 Sidecar 模式。

在 Proxyless 模式下,  為了提升 QPS 降低時延, 可以使用 SDK 方式, 譬如 gRPC 已經支援 xDS 協議客戶端, 我們的 Dubbo 團隊也在這條路上。我想今年我和北緯團隊雙方是可以一起在這個點上進行一些突破實現。

另外一個 proxyless 模式, 就是指- 核心 eBPF + Node 級 Proxy 方式。這個模式是對 sidecar 模式的一個根本性改變, 一個節點只有一個 Proxy，並且能力 offload 到節點上。這部分我們今年也會有些產品落地。

圍繞服務網格技術, 業界存在著一系列以應用為中心的生態系統, 其中, 阿里雲託管服務網格 ASM 支援了以下多種生態系統。列舉如下：

### 現代化軟體開發的生命週期管理和 DevOps 創新

服務網格的核心原則（安全性、可靠性和可觀察性）支援了現代化軟體開發的生命週期管理和 DevOps 創新, 為在雲端計算環境下如何進行架構設計、開發、自動化部署和運維提供了靈活性、可擴充套件性和可測試效能力。 由此可見, 服務網格為處理現代軟體開發提供了堅實的基礎，任何為 Kubernetes 構建和部署應用程式的團隊都應該認真考慮實施服務網格。

DevOps 的重要組成部分之一是建立持續整合和部署 (CI/CD)，以更快更可靠地向生產系統交付容器化應用程式程式碼。在 CI/CD  Pipeline 中啟用金絲雀或藍綠部署可為生產系統中的新應用程式版本提供更強大的測試，並採用安全回滾策略。在這種情況下，服務網格有助於在生產系統中進行金絲雀部署。當前阿里雲服務網格 ASM 支援了與 ArgoCD、Argo Rollout、KubeVela 以及雲效、Flagger 等系統的整合實現了應用的藍綠或金絲雀釋出, 具體如下：

ArgoCD **[** **1]** 職責主要是監聽 Git 倉庫中的應用編排的變化，並叢集中應用真實執行狀態進行對比，自動/手動去同步拉取應用編排的變更到部署叢集中。如何在阿里雲服務網格 ASM 中整合 ArgoCD 進行應用程式的釋出、更新，簡化了運維成本。

Argo Rollouts **[** **2]** 提供了更強大的藍綠、金絲雀部署能力。在實踐中可以將兩者結合來提供基於 GitOps 的漸進式交付能力。

KubeVela **[** **3]** 是一個開箱即用的、現代化的應用交付與管理平臺。使用服務網格 ASM 結合 KubeVela 可以實現應用的漸進式灰度釋出，達到平緩升級應用的目的。

阿里云云效流水線 Flow **[** **4]** 提供了基於阿里雲服務網格 ASM 完成 Kubernetes 應用的藍綠髮布。

Flagger **[** **5]** 是另外一種漸進式交付工具，可自動執行在 Kubernetes 上執行的應用程式的釋出過程。它透過在測量指標和執行一致性測試的同時，逐漸將流量轉移到新版本，降低了在生產中引入新軟體版本的風險。阿里雲服務網格 ASM 已經支援透過 Flagger 實現這種漸進式釋出能力。

微服務框架相容[6]

支援 Spring Boot/Cloud 應用無縫遷移至服務網格進行統一納管和治理, 提供了融合過程中出現的典型問題解決能力, 包括容器叢集內外服務如何互通、不同的語言服務之間如何進行互聯互通等常見場景。

Serverless 容器與基於流量模式的自動擴縮[7]

Serverless 和 Service Mesh 是兩種流行的雲原生技術，客戶正在探索如何從中創造價值。 隨著我們與客戶深入研究這些解決方案，問題經常出現在這兩種流行技術之間的交集以及它們如何相互補充上。我們能否利用 Service Mesh 來保護、觀察和公開我們的 Knative 無伺服器應用程式？在一個託管的服務網格 ASM 技術平臺上支援基於 Knative 的 Serverless 容器, 以及基於流量模式的自動擴縮能力, 從中可以替換如何透過託管式服務網格來簡化使用者維護底層基礎設施的複雜度, 讓使用者可以輕鬆地構建自己的 Serverless 平臺。

AI Serving **[** **8]**

****

Kubeflow Serving 是谷歌牽頭髮起的一個基於 Kubernetes 支援機器學習的社群專案，它的下一代名稱改為 KServe, 該專案的目的是可以透過雲原生的方式支援不同的機器學習框架，基於服務網格實現流量控制和模型版本的更新及回滾。

零信任安全及 Policy As Code[9]

在使用 Kubernetes Network Policy 實現三層網路安全控制之上，服務網格 ASM 提供了包括對等身份和請求身份認證能力、Istio 授權策略以及更為精細化管理的基於 OPA(Open Policy Agent) 的策略控制能力。

具體來說, 構建基於服務網格的零信任安全能力體系包括了以下幾個方面：

-   零信任的基礎：**工作負載身份**；如何為雲原生工作負載提供統一的身份；ASM 產品為服務網格下的每一個工作負載提供了簡單易用的身份定義，並根據特定場景提供定製機制用於擴充套件身份構建體系, 同時相容社群 SPIFFE 標準；

-   零信任的載體：**安全證書**，ASM 產品提供瞭如何簽發證書以及管理證書的生命週期、輪轉等機制，透過 X509 TLS 證書建立身份，每個代理都使用該證書。並提供證書和私鑰輪換；

-   零信任的引擎：**策略執行**，基於策略的信任引擎是構建零信任的關鍵核心，ASM 產品除了支援 Istio RBAC 授權策略之外，還提供了基於 OPA 提供更加細粒度的授權策略；

-   零信任的洞察：**視化與分析**，ASM 產品提供了可觀測機制用於監視策略執行的日誌和指標，來判斷每一個策略的執行情況等；

改造為雲原生應用帶來的業務價值非常多，其中一個就是彈性擴縮容，它能夠更好地應對流量峰值和低谷，達到降本提效的目的。服務網格 ASM 為應用服務間通訊提供了一種非侵入式的生成遙測資料的能力, 指標獲取不需要修改應用邏輯本身。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/559fb29052f4453cb4f5611fb7018502~tplv-k3u1fbpfcp-zoom-1.image "7.png")

根據監控的四個黃金指標維度（延遲、流量、錯誤和飽和度），服務網格 ASM 為管理的服務生成一系列指標, 支援多個協議, 包括 HTTP，HTTP/2，GRPC，TCP 等。

此外, 服務網格內建了 20 多個監控標籤, 支援所有 Envoy 代理指標屬性定義、通用表示式語言 CEL,  支援自定義 Istio 生成的指標。

同時，我們也在探索拓寬服務網格驅動的新場景，這裡舉一個AI Serving的示例 **[** **1****0]**  。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/94bc573c8efc4964b0f030162409b443~tplv-k3u1fbpfcp-zoom-1.image "8.png")

這個需求來源也是來自我們的實際客戶, 客戶的使用場景就是希望在服務網格技術之上執行 KServe 來實現 AI 服務。KServe 平滑執行於服務網格之上, 實現模型服務的藍/綠和金絲雀部署、修訂版本之間的流量分配等能力。支援自動伸縮的 Serverless 推理工作負載部署、支援高可擴充套件性、基於併發的智慧負載路由等能力。

## 總結

作為業內首個全託管Istio相容的阿里雲服務網格產品 ASM，一開始從架構上就保持了與社群、業界趨勢的一致性，控制平面的元件託管在阿里雲側，與資料面側的使用者叢集獨立。ASM 產品是基於社群Istio定製實現的，在託管的控制面側提供了用於支撐精細化的流量管理和安全管理的元件能力。透過託管模式，解耦了 Istio  元件與所管理的K8s 叢集的生命週期管理，使得架構更加靈活，提升了系統的可伸縮性。

從 2022 年 4 月 1 日起，阿里雲服務網格 ASM 正式推出商業化版本, 提供了更豐富的能力、更大的規模支援及更完善的技術保障，更好地滿足客戶的不同需求場景。

***參考連結：***

**[1] ArgoCD：**

**<https:>**

**[2] Argo Rollouts：**

**<https:>**

**[3] KubeVela：**

**<https:>**

**[4] 阿里云云效流水線 Flow：**

**<https:>**

**[5] Flagger：**

**<https:>**

**[6] 微服務框架相容：**

**<https:>**

**[7] Serverless 容器與基於流量模式的自動擴縮：**

**<https:>**

**[8] AI Serving：**

**<https:>**

**[9] 零信任安全及 Policy As Code：**

**<https:>**

**[10] AI Serving的示例：**

**<https:>**</https:></https:></https:></https:></https:></https:></https:></https:></https:></https:>

託管式服務網路：雲原生時代的應用體系架構進化

相關文章