*作者：王夕寧*

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

## 什麼是服務網格技術

以 Istio 為代表的 Service Mesh 技術已經存在四五年的時間了，阿里雲也是第一批支援 Service Mesh 雲服務的廠商。在 Service Mesh 技術中，透過把服務治理的能力進行 Sidecar 化，實現與應用程式本身的解耦。這些若干個 Sidecar 代理就形成了一個網狀的資料平面，透過該資料平面可以處理和觀察所有應用服務間的流量。

負責資料平面如何執行的管理元件稱為控制平面，是服務網格的大腦，它為網格使用人員提供公開 API，以便更容易地操縱網路行為。透過 Service Mesh，Dev/Ops/SRE 將以統一的、宣告的方式解決應用服務管理問題。

## 服務網格一種應用感知的雲原生基礎設施

我們認為服務網格是一種應用感知的雲原生基礎設施。它不僅僅是服務治理，而且包括了其他幾個維度的雲原生應用感知的特徵與能力。我們把它分為了 5 個部分，分別是：

-   雲原生應用網路
-   雲原生應用治理
-   雲原生零信任安全
-   雲原生可觀測及應用彈性
-   雲原生應用生態引擎****

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

### 雲原生應用網路

首先來看雲原生應用網路，分為 3 個部分來介紹。

-   Sidecar 模式下的雲原生應用網路
-   資料面 L4 與 L7 代理解耦模式下的網路
-   基於地域可用區資訊的優先路由

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

網路是 Kubernetes 的核心部分，涉及了 Pod 間通訊、Pod 和服務間通訊以及服務與外部系統間的通訊等。Kubernetes 叢集中使用 CNI 外掛來管理其容器網路功能，使用 Kube-proxy 維護節點上的網路規則， 譬如使發往 Service 的流量（透過 ClusterIP 和埠）負載均衡到正確的後端 Pod。

容器網路成為使用者使用 IaaS 網路的新介面，以阿里雲 ACK Terway 網路為例，基於阿里雲 VPC 網路直通彈性網路卡，具備高效能特徵，同時無縫地跟阿里雲 IAAS 網路對接。然而，kube-proxy 設定是全域性的，無法針對每個服務進行細粒度控制，而且 kube-proxy 只是專在網路資料包級別上執行。它無法滿足現代應用程式的需求，如應用層流量管理、跟蹤、身份驗證等。

我們來看服務網格 Sidecar 代理模式下的雲原生應用網路是如何解決這些問題的。服務網格透過 Sidecar 代理將流量控制從 Kubernetes 的服務層中解耦，將代理注入到每個 Pod，並透過控制平面操縱管理這些分散式代理，從而可以更加精細地控制這些服務之間的流量。

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

那麼在 Sidecar 代理下的網路資料包的傳輸是怎樣的過程？

當前 Istio 實現中涉及了 TCP/IP 堆疊的開銷，它使用了 Linux 核心的 netfilter 透過配置 iptables 來攔截流量，並根據配置的規則對進出 sidecar 代理的流量進行路由。客戶端 pod 到伺服器端 pod 之間的典型路徑（即使在同一主機內）至少要遍歷 TCP/IP 堆疊 3 次（出站、客戶端 Sidecar Proxy 到伺服器端 Sidecar Proxy、入站）。

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

為了解決這個網路資料路徑問題，業界透過引入 eBPF 繞過 Linux 核心中的 TCP/IP 網路堆疊來實現網路加速，這不但降低了延遲，同時也提升了吞吐量。當然，eBPF 並不會替換 Envoy 的七層代理能力，在七層流量管理的場景下，仍然是 4 層 eBPF + 7 層 Envoy 代理的融合模式。只有在針對 4 層流量網路的情況下，跳過代理 pod 直接進入網路介面。

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

前面講述的是傳統的 Sidecar 代理模式，除此之外，業界開始探索一種新型的資料平面模式。它的設計理念是：將資料平面分層，4 層用於基礎處理，特點是低資源、高效率；7 層用於高階流量處理，特點是功能豐富（當然也需要更多的資源）。這樣的話， 使用者可以根據所需功能的範圍，以漸進增量的方式採用服務網格技術。

具體來說，在 4 層處理中，主要包括：

-   **流量管理：** TCP 路由
-   **安全：** 面向 4 層的簡單授權策略、雙向 TLS
-   **可觀測：** TCP 監控指標及日誌

在 7 層處理中，則主要包括：

-   **流量管理：** HTTP 路由、負載均衡、熔斷、限流、故障容錯、重試、超時等
-   **安全：** 面向 7 層的精細化授權策略
-   **可觀測：** HTTP 監控指標、訪問日誌、鏈路追蹤

那麼資料面 L4 與 L7 代理的解耦模式下，Service Mesh 的網路拓撲將是什麼形式？

一方面，將 L4 Proxy 能力下移到 CNI 元件中，L4 Proxy 元件以 DaemonSet 的形式執行，分別執行在每個節點上。這意味著它是為一個節點上執行的所有 pod 提供服務的共享基礎元件。

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

另一方面，L7 代理不再以 Sidecar 模式存在，而是解耦出來，我們稱之為 Waypoint Proxy，它是為每一個 Service Account 建立的 7 層代理 pod。

4 層和 7 層代理的配置仍然保持透過 Service Mesh 控制面元件來進行下發管理。

總之，透過這種解耦模式，實現了 Service Mesh 資料平面與應用程式之間的進一步解耦分離。

那麼， 在 Istio 的具體實現中，可以分為 3 個部分：

-   **Waypoint代理：** L7 元件完全獨立於應用程式執行，安全性更高；每個身份（Kubernetes 中的服務賬戶）都有自己專用的 L7 代理（ Waypoint 代理），避免多租戶 L7 代理模式引入的複雜度與不穩定性；同時，透過 K8s Gateway CRD 定義觸發啟用；
-   **ztunnel：** 將 L4 處理下沉到 CNI 級別，來自工作負載的流量被重定向到 ztunnel， 然後 ztunnel 識別工作負載並選擇正確的證照來處理；
-   **與 Sidecar 模式相容：** Sidecar 模式仍然是網格的一等公民，Waypoint 代理可以與部署了 Sidecar 的工作負載進行本地通訊；

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

**Service Mesh 作為雲原生應用網路之場景示例：基於地域可用區資訊的優先路由**

在這個示例中，我們部署了兩套一樣的應用服務到 2 個不同的可用區下，即這個部署架構圖中的可用區 A 和 B。正常情況下，這些應用服務本身是遵循了同 AZ 流量路由優先的機制，也就是說可用區 A 中的應用服務 productpage 會指向本可用區中的 reviews 服務。

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

而當本可用區服務不可用時，譬如 reviews 服務出現故障，容災模式就會自動開啟，這個時候可用區 A 中的應用服務 productpage 會指向另一可用區 B 中的 reviews 服務。

這個流量拓撲是阿里雲 ASM 產品提供的網格拓撲中按可用區資訊展示的呼叫鏈路。在實現同 AZ 路由的過程中， 是不需要修改應用程式碼本身就可以完成的。

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

同樣地，在不需要修改應用程式碼本身的情況下，Service Mesh 自動實現故障轉移以保證高可用。這個拓撲圖中可以看到可用區 A 中的應用服務會自動切換到呼叫可用區B中的服務了。

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

###  雲原生應用治理

接下來看雲原生應用治理，它的內容包含很多維度，這裡重點摘取講述 3 個部分。

-   **服務慢啟動以支援預熱能力**
-   **全鏈路流量管理**
-   **與服務框架的融合**

先來看下啟用預熱模式前後的差異。

**未啟用預熱模式：**

-   不支援新 Pod 的漸進式流量增加。每當新目標 Pod 加入時，請求方都會向該 Pod 傳送一定比例的流量。這對於需要一些預熱時間來提供全部負載的服務可能是不可取的，並且可能會導致請求超時、資料丟失和使用者體驗惡化。
-   作為一個實際示例，上述問題體現在基於 JVM 的 Web 應用程式中，這些應用程式使用水平 pod 自動縮放。當服務剛啟動時，它會被大量請求淹沒，這會導致應用程式預熱時持續超時。因此，每次擴充套件服務時，都會丟失資料。

**啟用預熱模式：**

-   預熱/慢啟動模式又稱漸進式流量增加，使用者可以為他們的服務配置一個時間段。每當一個服務例項啟動時， 請求方會向該例項傳送一部分請求負載，並在配置的時間段內逐步增加請求量。當慢啟動視窗持續時間到達，它就會退出慢啟動模式。
-   在慢啟動模式下，在新增新的目標服務 Pod 時，可以使得他們不會被大量請求壓倒， 這些新目標服務可以根據指定的加速期在接受其均衡策略的請求之前進行預熱。

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

透過這兩個圖也可以看到， 在啟用了預熱模式之後， 新建立的 pod 達到均衡的負載請求所需的時間會拉長，這也反映了在一定的預熱時間內，進入該 pod 的請求是逐步增加的。

**一個實際客戶案例：擴容和滾動更新場景下支援預熱實現服務優雅上線**

**背景：**

-   Java 應用冷啟動時大流量導致 CPU 打滿，呼叫異常
-   應用滾動更新僅僅透過 readiness 無法實現優雅上線

**支援預熱實現服務優雅上線：**

-   ASM 感知例項的上下線，當發現一臺機器剛上線時，自動將其權重給調低，過了一定的時間後（預熱週期）再將權重調到 100%（權重調整比例）；
-   對應用完全沒有侵入性；

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

那這個功能是怎麼在服務網格 ASM 中實現的呢，簡單說，一行配置就可以實現預熱、慢啟動能力。這個拓撲圖也是這個實際案例的脫敏簡化版，可以看到透過預熱功能：

-   能夠實現業務的平滑啟動，完美避免業務抖動問題；
-   啟用預熱功能之後，流量均衡地分佈到 v1 和 v2 版本，相比未啟用熱功能多花費了 1 分 10 秒左右的時間，以此緩衝。

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

**全鏈路流量管理，兩個使用場景**

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

**全鏈路灰度釋出：**

在生產環境正常執行的同時，開始針對部分應用服務進行灰度升級，譬如圖中的 B 和 D 應用進行灰度，在不需要修改應用邏輯的情況下，利用 Service Mesh 技術就可以實現根據請求來源或者請求的頭資訊，動態地路由到不同版本的服務上。譬如，當請求頭中包含 tag1 時，應用 A 就會呼叫灰度版本 B，而 C 並沒有灰度版本，系統就會自動 fallback 回退到原有的版本。

**多版本開發環境：**

類似地，有一個基線環境，其他不同的開發環境可以根據需要，分別部署各自版本的部分應用服務。根據請求來源或者請求的頭資訊，動態地路由到不同版本的服務上。

整個過程中，不需要修改應用程式碼邏輯，只需要針對應用打標，ASM 產品實現了一個 Traffic Label CRD 抽象定義，簡化對流量和應用例項打標。

**應用治理與服務框架融合**

在遺留的應用系統中，仍然還是實現了類似 Spring Cloud 或者 Dubbo 的服務框架，服務網格 ASM 支援了多模服務治理，實現了呼叫互通、監控互通、治理互通。

透過 MCP over xDS 協議將原有註冊中心的服務資訊註冊到 Service Mesh 中，透過 Service Mesh 控制面元件統一管理規則配置，並以 xDS 協議統一下發管理。

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

### 雲原生應用的零信任安全

接下來看雲原生應用的零信任安全，包括：

-   **零信任的基礎 - 工作負載身份**
-   **零信任的載體 - 安全證照**
-   **零信任的引擎 - 策略執行**
-   **零信任的洞察 - 視覺化與分析**

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

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

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

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

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

使用服務網格實現零信任具備如下優勢：

-   Sidecar 代理生命週期獨立
-   動態配置、無需重啟
-   服務網格集中控制，降低開發心智負擔
-   加強身份認證授權系統本身安全保障
-   集中管理並下發 OPA 授權策略
-   簡化接入第三方授權服務、OIDC 身份認證

這是某平臺使用網格零信任安全技術的場景。可以看到，客戶使用中遵循了零信任安全架構的基本原則：

-   工作負載身份標識
-   服務認證
-   服務授權
-   TLS 加密
-   OPA 策略
-   最小許可權訪問策略

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

### 雲原生應用的可觀測及應用彈性

接下來看雲原生應用的可觀測及應用彈性，包括：

-   **網格可觀測中心**
-   **網格診斷**
-   **網格拓撲**

**網格可觀測中心：統一的可觀測性體系和聯動分析（3 個維度）**

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

-   **一是日誌分析。** 透過對資料平面的 AccessLog 採集分析，特別是對入口閘道器日誌的分析，可以分析出服務請求的流量情況、狀態碼比例等，從而可以進一步最佳化這些服務間的呼叫；

-   **第二個可觀測效能力是分散式追蹤能力。** 為分散式應用的開發者提供了完整的呼叫鏈路還原、呼叫請求量統計、鏈路拓撲、應用依賴分析等工具，可以幫助開發者快速分析和診斷分散式應用架構下的效能瓶頸，提高微服務時代下的開發診斷效率；

-   **第三個可觀測效能力是監控能力。** 根據監視的四個維度（延遲，流量，錯誤和飽和度）生成一組服務指標, 來了解、監視網格中服務的行為。

**網格診斷：檢測網格配置的潛在問題及提供改進措施**

根據我們對 Service Mesh 技術的客戶支援和實戰經驗，在服務網格 ASM 中：

-   內建 30+ 項診斷規則、最佳實踐
-   針對每個 Istio 資源物件提供語法的靜態檢查
-   支援多個 Istio 資源物件的執行語義的動態驗證
-   針對診斷出的問題提供相應的改進措施

**網格拓撲：提供對服務網格行為的即時洞察**

除了強大的網格流量拓撲視覺化之外， 還提供了回放功能可以選定過去時間段的流量。

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

### 雲原生應用的生態引擎

接下來看雲原生應用的生態引擎，包括 3 個部分：

-   **外掛市場**
-   **能力中心**
-   **新場景定義**

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

基於內建的模板， 使用者只需要根據對應的引數要求， 進行簡單配置， 就可以部署出對應的 EnvoyFilter 外掛。透過這樣的機制， 使得資料平面成為更易可擴充套件的外掛集合能力。

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

**能力中心:  服務網格與生態系統的整合整合能力**

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

-   **藍綠髮布、 漸進式交付、GitOps、CI/CD**

-   -   支援了與 Argo Rollout、Flagger 以及雲效等系統的整合實現了應用的藍綠或者金絲雀釋出

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

-   **微服務框架相容**

-   -   支援 Spring Boot/Cloud 應用無縫遷移至服務網格進行統一納管和治理。

-   **Serverless**

-   -   支援 Knative 執行於託管的服務網格 ASM 之上, 用於部署和執行 Serverless 工作負載, 並基於服務網格實現了在各個版本之間的流量路由。

-   **AI Serving**

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

-   **Policy As Code**

-   -   OPA（Open Policy Agent）/宣告式策略表達語言 Rego：在使用 Kubernetes Network Policy 實現三層網路安全控制之上，服務網格 ASM 提供了包括工作負載身份、對等身份和請求身份認證能力、Istio 授權策略以及更為精細化管理的基於 OPA(Open Policy Agent) 的策略控制能力。
    -   一般來說，構建基於服務網格的零信任安全能力體系包括了以下幾個方面：零信任的基礎 - 工作負載身份，零信任的載體 - 安全證照，零信任的引擎 - 策略執行，零信任的洞察 - 視覺化與分析。

此外，我們也在探索拓寬服務網格驅動的新場景，我這裡舉一個 AI Serving 示例。

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

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

## 雲原生基礎設施的關鍵層，企業數字化轉型的重要橋樑

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

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

託管式服務網格 ASM 在成為多種型別計算服務統一管理的基礎設施中，提供了統一的流量管理能力、統一的服務安全能力、統一的服務可觀測效能力、以及基於 WebAssembly 實現統一的代理可擴充套件能力，以此構築企業級能力。可以點選文末[“**此處**”](https://www.aliyun.com/product/servicemesh)檢視具體的內容介紹。

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

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

![23.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/607c080b22e94216b9e688d1935948bc~tplv-k3u1fbpfcp-zoom-1.image "23.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

談談我對服務網格的理解

相關文章