![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/b5e0dbbcefd247f38f1846f29c257d49.png)

作者 | 王夕寧  阿里雲高階技術專家
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/As0cRMNa0cflJs0I1Uq1pg)

本文將介紹如何使用 ORAS 客戶端將具有允許的媒體型別的 Wasm 模組推送到 ACR 註冊庫（一個 OCI 相容的註冊庫）中，然後透過 ASM 控制器將 Wasm Filter 部署到指定工作負載對應的 Pod 中。Wasm Filter 部署中的所有步驟都使用宣告方式，也就是說可以建立一個自定義資源 CRD 來描述 Wasm Filter 的部署。一旦該 CRD 建立之後，ASM 控制器可以將 Wasm 模組載入到資料平面層中的相應 Envoy 代理中，同時在控制平面層中也會建立相應的 Istio EnvoyFilter 自定義資源。

# Envoy Filter 介紹

首先回顧一下 EnvoyProxy 的實現機制。Envoy 的核心是一個 L3/L4 網路代理，並支援 L7 代理，透過提供可插入 filter chain 機制允許開發人員編寫 filter 來執行不同的任務，譬如我們常用到的 HTTP connection manager，將原始位元組轉換為 HTTP 級別的訊息和事件，還處理所有 HTTP 連線和請求共有的功能包括訪問日誌、tracing 等。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/49635b59c8814baba300a4a22787d9aa.png)

上圖可以看到：Downstream 作為連線到 Envoy 併傳送請求以及接收響應的客戶端部分， 監聽器 Listener 元件用於繫結到 IP 地址/埠並接收來自 Downstream 下游的連線。透過配置 Listener，使用者可以啟用透過代理的流量管理能力，然後使用多個 Filter 增強資料流，多個 Filter 構成了一個 Filter Chain。可以看到經過這些 Filter chain 處理之後， 會把請求對映到相應的 Cluster（此處的 Cluster 叢集是指 Envoy 連線到的邏輯上相同的一組上游主機，與下文中提交的 Kubernetes 叢集沒有關係），而 Cluster 的作用是負責連線到一組上游節點服務, 並使用關聯的負載均衡策略轉發這些請求。

根據處理任務的不同，Envoy Filter 分為三類：

- Listener Filter：用於操作處理 L4 連線中的後設資料。
- Network Filter：用於操作處理 L4 連線中的原始資料。
- HTTP Filter：用於操作處理 L7 連線中的 HTTP 請求與響應。

除了這些 built-in Filter 之外，還可以開發自定義的 Filter，可使用 native c++ 編譯方式，或是透過 wasm 技術構建 Filter。
 
此外，Envoy 提供了一組 API，也就是我們常說的 xDS API。透過這些 API，控制平面可以動態地配置 Envoy 代理。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/f53382d9d24142e7b12f3e6795973382.png)

如上圖所示，與進站流量類似，對於出站流量來說，監聽器在配置的地址或者埠進行監聽網路流量的請求。每個監聽器同樣會定義一組位於資料路徑中的 Filter，並形成一組過濾器鏈 Filter Chain。透過這樣的一組過濾器，使用者可以配置 Envoy 來針對出站流量做特定的任務，包括資料協議處理、生成呼叫的統計資訊、執行 RBAC 許可權等。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/0f215e6ea79f4d2aa0575580b8b8d9ea.png)

為了更好地理解這些 Envoy Filter 以及 Filter Chain，下面來看一個實際的例子。這個就是 Istio 官方示例 bookinfo 中的第一個服務 productpage。首先, productpage pod 中 Envoy Proxy 配置了一個監聽 9080 埠的監聽器，進入這個 pod 的埠 9080 上的流量請求都會被攔截到這個 proxy 中，然後請求就會經過這些 Filter Chain 進行處理。具體如下：

- 第一個 filter 是 envoy.filters.network.metadata_exchange，它的主要作用顧名思義，用來在 filter 之間交換後設資料。

- 第二個 filter: envoy.http_connection_manager，它下面通常會有以下幾個跟 http 特定的 filter，包括：

- envoy.filters.http.wasm/envoy.wasm.metadata_exchange（用於後設資料互動）

- Istio_authn filter（用於授權認證）

- envoy.filters.http.cors（處理跨域資源共享的 filter）

- envoy.filters.http.fault（故障注入過濾器，可以用來測試微服務架構中容錯能力，使用者可以自定義錯誤程式碼來實現延時注入或者終止請求，在不同的失敗場景下提供錯誤處理的能力，例如服務失敗、服務過載、服務高延時等情況，這個也是較為常用的 filter）

- envoy.filters.http.wasm/envoy.wasm.stats、envoy.filters.http.wasm/xxx-wasmfilter（使用者自定義的 wasm 實現的filter）

- envoy.filters.http.router（實現 HTTP 轉發，幾乎所有 HTTP 場景下都會使用到這一過濾器）

備註：可以透過請求這個 URL 地址獲取配置資訊：kubectl exec -it [productpage-xxx] -c istio-proxy curl localhost:15000/config_dump

# 新增新的 Filter

Envoy 社群已經提供了若干個 Built-in Filters，具體參見：[https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/http_filters](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/http_filters)。

在服務網格中，可以透過 API 啟用這些 Built-in Filter 能力。

如果這些 Built-in Filter 無法滿足需求，還可以透過自定義 Filter 實現，有以下兩種方式：

- **靜態預編譯**：
   - 將其他過濾器整合到 Envoy 的原始碼中，並編譯新的 Envoy 版本。
   - 這種方法的缺點是您需要維護 Envoy 版本，並不斷使其與官方發行版保持同步。
   - 由於 Envoy 是用 C++ 實現的，因此新開發的過濾器也必須用 C++ 實現。 
- **動態執行時載入**：
   - 在執行時將新的過濾器動態載入到 Envoy 代理中。
   - 為了簡化擴充套件 Envoy 的過程, 透過引入 WebAssembly 技術 - 它是一種有效的可移植二進位制指令格式，提供了可嵌入和隔離的執行環境。

# 使用 Wasm 擴充套件 Envoy Proxy 的優缺點

在實際應用中，會根據以下優缺點來決定是否使用 Wasm 這種方式擴充套件 Envoy Filter。

## Pros

- 敏捷性：過濾器可以動態載入到正在執行的 Envoy 程式中，而無需停止或重新編譯。
- 可維護性：不必更改 Envoy 自身基礎程式碼庫即可擴充套件其功能。
- 多樣性：可以將流行的程式語言（例如 C/C++ 和 Rust）編譯為 WASM，因此開發人員可以選擇實現過濾器的程式語言。
- 可靠性和隔離性：過濾器會被部署到 VM 沙箱中，因此與 Envoy 程式本身是隔離的；即使當 WASM Filter 出現問題導致崩潰時，它也不會影響 Envoy 程式。
- 安全性：過濾器透過預定義 API 與 Envoy 代理進行通訊，因此它們可以訪問並只能修改有限數量的連線或請求屬性。

## Cons

- 效能約為 C++ 編寫的原生靜態編譯的 Filter 的 70％。
- 由於需要啟動一個或多個 WASM 虛擬機器，因此會消耗一定的記憶體使用量。
- The WebAssembly ecosystem is still young。

# envoy-wasm 執行機制

如下圖所示，envoy-wasm 執行機制包括以下幾個步驟：

![4.png](https://ucc.alicdn.com/pic/developer-ecology/53cb1ebc962843118ffd33076aa821e9.png)

- Wasm 二進位制程式碼需要能夠被動態載入進來，無論是透過 local file 方式還是 xds 遠端獲取方式。
- 一個 Wasm filter 是否被允許載入，需要一致性校驗：[https://github.com/proxy-wasm/spec](https://github.com/proxy-wasm/spec)。
- 一旦被載入之後，Wasm filter 就成為 filter chain 的一部分，當新的請求進來之後，還是先進入到原生的 filter，之後進入到 Proxy-Wasm 擴充套件控制器。
- Proxy-Wasm 擴充套件控制器會根據在 filter chain 中定義的 configuration 資訊，呼叫並執行註冊的校驗過的這些 Wasm filter。
- 內建的 Wasm runtime 支援：LLVM-based WAVM ~20MB, and V8 ~10MB。
- 事件驅動模型。
- 相容 native filter 呼叫方式。

如下所示，是下發到 Envoy Proxy 側的一個 Wasm Filter 的配置內容。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/2edc147b92c743eaa793a4e07d6496f8.png)

以上講述了 Envoy Filter 以及透過 Wasm 擴充套件的方式，引出了 Wasm filter 機制，這將是未來的主流方式。

在一個服務網格體系中，如何以有效並且簡單的方式來管理 Wasm filter 的部署執行，將是雲產品需要解決的一個問題。

# OPAS 及 Wasm filter 註冊庫

在 Cloud Native 生態系統中，如何管理一個 Artifact 檔案，相信絕大多數人會想到 oci 規範標準，是否可以像管理 Docker 映象那樣去管理這些 Wasm filter。

ORAS 專案就是用來解決這個問題的，它的全稱為 OCI Registry As Storage。ORAS 是 OCI Artifacts 專案的參考實現，可以顯著地簡化 OCI 註冊庫中任意內容的儲存。

使用 ORAS API/SDK Library 可以構建自定義工具，完成以下功能：

- 將 WebAssembly 模組推入到 OCI 註冊庫中。
- 從 OCI 註冊庫中拉取 WebAssembly 模組。

oras cli 的使用類似於 docker cli，如下所示：

![6.png](https://ucc.alicdn.com/pic/developer-ecology/92cbe4b405e04c3c84f4a55c5ba2b289.png)

以阿里雲容器映象服務企業版 ACR EE 為例，作為企業級雲原生應用製品管理平臺，已經提供了容器映象、Helm Chart 以及符合 OCI 規範的製品的生命週期管理。開通之後，建立一個映象倉庫，會分配一個地址，提供了 vpc 和公網兩種方式。

使用 oras login 命令列登入, 執行以下命令：

oras login --username= acree-1-registry.cn-hangzhou.cr.aliyuncs.com

透過oras push命令推送, 執行以下命令：

oras push acree-1-registry.cn-hangzhou.cr.aliyuncs.com/******/asm-test:v0.1 --manifest-config runtime-config.json:application/vnd.module.wasm.config.v1+json  example-filter.wasm:application/vnd.module.wasm.content.layer.v1+wasm

注意引數 --manifest-config，可以參考 Wasm Artifact 映象規範。

Wasm filter 被推送到 ACR EE 註冊庫中之後，可以檢視相關資訊，如下：

![7.png](https://ucc.alicdn.com/pic/developer-ecology/39ac2aaef238428883882ba46beef401.png)

# 阿里雲服務網格 ASM 架構

在阿里雲服務網格 ASM 產品中是如何使用 Wasm 技術呢？首先我們瞭解一下 ASM 產品的技術架構，如下圖所示。作為業內首個全託管 Istio 相容的服務網格產品，ASM 的定位是專注打造全託管、安全、穩定、易用的服務網格，以及支援跨地域多叢集、多雲混合雲服務的統一治理。控制平面的元件託管在阿里雲側，與資料面側的使用者叢集解耦獨立，降低使用者使用的複雜度，使用者只需要專注於業務應用的開發部署。在託管模式下，保持與 Istio 的相容，支援宣告式的方式定義靈活的路由規則，支援多個 Kubernetes 叢集的統一流量管理。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/b2529a42ddc94f978959949b587ccc71.png)

服務網格 ASM 作為連線上層應用和下層計算基礎設施的重要環節，可以分為 3 個角度來理解：

- 從向下與基礎設施融合的角度
- 服務網格自身的能力建設的角度
- 向上支援應用層以及被整合能力的角度

其中, 從服務網格自身的能力建設來看，ASM 作為一個託管的服務網格產品，提供了柔性架構，可以支援不同版本的、定製的 Istio 控制面與資料面 Proxy 代理。

- 在託管側，將控制面核心元件進行改造託管，並負責整個控制面和資料面元件的生命週期管理。在產品能力方面，ASM 在 Mesh CA、安全審計方面做了增強提升網格例項的安全度；把客戶場景的常見問題形成了診斷規則，使用者可以自行執行診斷分析。

- 在做核心託管側的建設之外，ASM 最佳化整合了阿里雲的多個產品服務，如：在可觀測性方面，整合了 xtrace、arms、日誌服務等；在跨 vpc 網路打通方面整合了 cen，實現多叢集的互聯互通；在限流方面整合了 AHAS 的限流服務。

- ASM 還整合擴充套件了社群開源的元件能力，包括在安全方面的 OPA 安全引擎的支援、spiffe/spire 的支援、envoyfilter 的擴充套件支援等。所以這一部分需要提供一種簡單有效的方式幫助使用者輕鬆擴充套件這些能力。

# 在阿里雲 ASM 中使用 Wasm

隨著新架構的最佳化，WebAssembly 技術被引入服務網格中，解決代理擴充套件的問題。這樣一來， ASM 架構就變成了“託管的高可用彈性控制平面 + 可擴充套件的外掛式的資料平面“的模式。

阿里雲服務網格 ASM 產品中提供了對 WebAssembly（WASM）技術的支援，服務網格使用人員可以把擴充套件的 WASM Filter 透過 ASM 部署到資料面叢集中相應的 Envoy 代理中。透過 ASMFilterDeployment  Controller 元件,  可以支援動態載入外掛、簡單易用、以及支援熱更新等能力。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/95bfdc464304471a8027f973ed2a7979.png)

透過這種過濾器擴充套件機制，可以輕鬆擴充套件 Envoy 的功能並將其在服務網格中的應用推向了新的高度。

下面我們具體來看在 ASM 例項中是怎樣啟用這個能力的？

部署一個 ASM 例項之後，預設該功能是沒有開啟的，使用者需要主動去開啟。例如透過如下 aliyun cli 方式：

```
aliyun servicemesh UpdateMeshFeature  --ServiceMeshId=xxxxxx --WebAssemblyFilterEnabled=true
```

開啟該功能之後，ASM 例項會部署相關元件並執行如下任務：

- 部署一個 DaemonSet(asmwasm-controller) 到 K8s 叢集中。
- asmwasm-controller 監聽一個 configmap，該 configmap 存放要拉取的 wasm filter 的地址，例如：acree-1-registry.cn-hangzhou.cr.aliyuncs.com/*******/sample:v0.1。
- 如果需要授權認證，該 asmwasm-controller 會根據定義的 pullSecret 值獲得相應的 secret 值。
- 然後，呼叫 oras API 從註冊庫中動態拉取 Wasm filter。
- 該 asmwasm-controller 使用 HostPath 方式掛載 volume，所以拉取的 Wasm filter 會落盤到對應的節點上。

啟用了該功能之後，如何開始部署一個 Wasm filter 並掛載到對應 workload 的 Envoy Proxy 中呢？

![10.png](https://ucc.alicdn.com/pic/developer-ecology/3653d94a6f004a93bcb4fa0407549043.png)

阿里雲服務網格 ASM 產品提供了一個新的 CRD ASMFilterDeployment 以及相關的 controller 元件。這個 controller 元件會監聽 ASMFilterDeployment 資源物件的情況，會做 2 個方面的事情：

- 建立出用於控制面的 Istio EnvoyFilter Custom Resource，並推送到對應的 asm 控制面 istiod 中。
- 從 OCI 註冊庫中拉取對應的 wasm filter 映象，並掛載到對應的 workload pod 中。

以下是一個 ASMFilterDeployment CR 示例：

```
apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMFilterDeployment
metadata:
  name: details-v1-wasmfiltersample
spec:
  workload:
    kind: Deployment
    labels:
      app: details
      version: v1
  filter:
    parameters: '{"name":"hello","value":"hello details"}'
    image: 'acree-1-registry.cn-hangzhou.cr.aliyuncs.com/asm/asm-test:v0.1'
    imagePullOptions: 
      pullSecret: 'asmwasm-cache'
    rootID: 'my_root_id'
    id: 'details-v1-wasmfiltersample.default'
```

生成的 Istio Envoy Filter 資源如下所示：

![11.png](https://ucc.alicdn.com/pic/developer-ecology/e9be7c4fe87c4fc48d413bd087ed75d8.png)

其中，match 片段中定義了 envoy.router 這個 filter、patch 片段中定義了 INSERT_BEFORE 操作，插入一個 Wasm filter，如下：

![12.png](https://ucc.alicdn.com/pic/developer-ecology/a542b65852c9456c8923ef93548d50ba.png)

掛載了 Wasm filter 的工作負載定義更新後如下，其中以 hostpath 方式掛載 Wasm filter 檔案到 Proxy 容器中：

```
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
.…
spec:
   ….
   template:
      metadata:
          annotations:
              sidecar.istio.io/userVolume: '[{"name":"wasmfilters-dir","hostPath":{"path":"/var/local/lib/wasm-filters"}}]’
              sidecar.istio.io/userVolumeMount: '[{"mountPath":"/var/local/lib/wasm-filters","name":"wasmfilters-dir"}]'
```

確認 Wasm filter 是否生效。登入到 productpage Pod 的 istio-proxy 容器中，執行以下命令，將一些流量傳送到 details 服務上。在響應中，可以看到過濾器的頭新增到響應頭中。

```
kubectl exec -ti  deploy/productpage-v1 -c istio-proxy -- curl -v http://details:9080/details/123
```

```
*   Trying 172.21.9.191...
* TCP_NODELAY set
* Connected to details (172.21.9.191) port 9080 (#0)
> GET /details/123 HTTP/1.1
> Host: details:9080
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
xxxxxxx
< resp-header-demo: added by our filter
xxxxx
* Connection #0 to host details left intact
xxxxx
```

# 總結

在開發階段：

按照如下流程，使用適當的 wasm sdk/程式語言，建立編譯出一個 wasm 二進位制檔案，透過使用 oras cli 上傳到 oci 映象倉庫中。

![13.png](https://ucc.alicdn.com/pic/developer-ecology/0401668176de43f18912ccf4e4e1c0f7.png)

在部署執行階段：

首先確認已經在 ASM 中開啟 Wasm 支援能力，然後建立一個 ASMFilterDeployment 自定義資源，注意這個 CR 是在服務網格 ASM 例項對應的 apiserver 中建立。一旦建立，相應的 crd controller 會監聽同步相應的資源，一方面生成一個 Istio EnvoyFilter CR 併傳送到 ASM 例項的控制面 apiserver 中，使用者可以檢視生成的這個 Istio Envoyfilter CR 是否滿足期望。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/e1e87febfe7f4fd8a217c60b40ccc5fe.png)

另一方面，確認 Workload 部署變更生效，包括：

- 可以登入到 proxy container 進行檢視 Wasm filter 是否掛載成功。
- 透過調整 wasm log level 來列印相關資訊。

作為業內首個全託管 Istio 相容的服務網格產品，阿里雲服務網格（簡稱 ASM）是一個統一管理微服務應用流量、相容 Istio 的託管式平臺，專注打造全託管、安全、穩定、易用的服務網格，支援跨地域多叢集、多雲混合雲服務的統一治理。透過流量控制、網格觀測以及服務間通訊安全等功能，服務網格 ASM 可以全方位地簡化您的服務治理，併為執行在異構計算基礎設施上的服務提供統一的管理能力，適用於 Kubernetes 叢集、Serverless Kubernetes 叢集、ECS 虛擬機器以及自建叢集。

歡迎登入到[阿里雲服務網格 ASM 產品官網](https://www.aliyun.com/product/servicemesh)進行體驗！

### **作者簡介**

王夕寧  阿里雲高階技術專家，阿里雲服務網格 ASM 技術負責人，專注於 Kubernetes、服務網格以及其他雲原生領域。之前曾在 IBM 中國開發中心工作，曾擔任專利技術評審委員會主席，作為架構師和主要開發人員負責或參與了一系列在 SOA 中介軟體、雲端計算等領域的工作，擁有 50 多項相關領域的國際技術專利。曾在多個技術大會如 Kubecon、ArchSummit、雲棲大會等參與技術分享。編寫《服務網格技術解析與實踐》並在多個技術社群釋出文章若干。

基於 Wasm 和 ORAS 簡化擴充套件服務網格功能

相關文章