1 Wasm为Envoy带来新的扩展性
Envoy是一个高性能、可编程的L3/L4和L7网络代理，许多服务网格和网关都采用Envoy作为数据面。
Envoy通过监听器（Listener）捕获网络数据包，根据数据包的内容匹配某个过滤器链（Filter Chain）中，之后按顺序执行该链中的过滤器（Network Filter）对捕获的数据包进行操作，实现用户定义的各种流量治理策略。Envoy本身自带很多种类的过滤器，这些开箱即用的过滤器 cover了大部分的应用场景，但是在某些需要自定义功能的场景下，用户必须实现自己的过滤器。
Envoy filter chains
在Wasm出现之前，添加过滤器有两种方式：
- 修改Envoy代码，使用C++语言编写原生的过滤器（Native C++ filters）。在早期（2019年初），Envoy是一个静态编译的二进制文件，其所有扩展都在构建时编译。这意味着提供自定义扩展的项目必须维护和分发自己的二进制文件。这种方式需要开发者熟悉C++语言和Envoy过滤器的开发模式，在开发完成后重新编译一个新的Envoy二进制且维护它与上游社区的版本。目前Istio社区采用的就是这种方式，Istio fork了上游的Envoy，在其基础之上添加了自己定制的一些插件。然而，这种方式对开发者要求较高，且需要花费额外的精力维护。
- 使用Lua脚本编写过滤器。这种方式相比于上一种更加简单，用户可以直接在xDS配置中直接编写Lua脚本（inline）或指定本地的一个Lua脚本文件，适合过滤器逻辑非常简单的情况。然而，这种方式并不适用于过滤器逻辑复杂的情况，而且需要用户在Istio中手动创建EnvoyFilter进行额外的配置。
可以看出，上述两种扩展Envoy的方式都不是非常“优雅”。为了解决这个问题，Envoy社区提出了Wasm Filter特性，在Envoy中内嵌了一个Wasm运行时，通过proxy-wasm定义的网络代理相关接口来运行Wasm二进制。这意味着Envoy可以在运行中动态地加载用户开发的Wasm模块，并将其作为一个过滤器插入到过滤器链中。Wasm能够解决上述传统方式的各种问题，用户能够用任何支持的语言开发自己的Wasm过滤器，对Envoy本身无侵入。Envoy发起者称“Wasm是Envoy可扩展性的未来”。
Envoy与Wasm的交互
2 Istio WasmPlugin API
Envoy对Wasm的支持为Istio带来了全新的扩展机制。在早期，用户可以使用EnvoyFilter手动在Envoy配置中添加Wasm filter，这种方式非常地繁琐，用户体验并不友好，且EnvoyFilter是一个“break glass”API，社区并不保证其不同版本的向后兼容性。
为了更好地支持Wasm，Istio在1.12版本中添加了一个新的CRD，即WasmPlugin。用户可以通过WasmPlugin方便灵活地将Wasm插件下发到指定的工作负载，使得开发人员可以更简单健壮地扩展网格功能。
WasmPlugin yaml示例
上图展示了一个最基本的WasmPlugin配置，在配置中用户需要指定Wasm模块的url，该url可以是像容器镜像一样的OCI格式的Wasm，也可以是代理本地的一个文件（通常要求用户手动挂载到容器中），或者是http协议的url，用于直接获取远程Wasm模块文件。一般推荐的方式第是一种，将编写好的代码编译成Wasm二进制后，打包成一个OCI镜像，方便分发和复现。
用户可以通过selector指定要下发Wasm的proxy，如果selector为空，则代表下发到该namespace下的所有proxy。
除此之外，如果用户需要指定Wasm插件在过滤器链中执行的位置，可以通过phase和priority两个参数来控制。phase用来指定在http filter链中的何处插入此Wasm 插件，可以设置为authentication，authorization或istio stats filter之前，未设置时会在istio stats filter之后插入；priority用来控制多个WasmPlugin在同一个phase中的执行顺序，priority值大的优先。
03Istio下发Wasm配置流程解析
Istiod推送过程
每当用户更新WasmPlugin时，istiod就会触发一次config update。首先，istiod会更新本次xDS push的context，将当前的WasmPlugin信息按照namespace分类，保存到push context中。
之后，在LDS（Listener Discovery Service）推送的过程中，istiod为proxy构建Listener的http filter时，会从push context中找出与该proxy匹配的WasmPlugin并按照priority排序，最后根据phase将Wasm filter插入到http filter chain中的某个位置。
Istio插入Wasm filter代码
注意此处插入的只是Wasm filter的名称，具体的Wasm filter配置则是通过后续的ECDS（Extension Config Discovery Service）下发的。在ECDS中，istiod会构建出实际的Wasm filter配置并推送给proxy。
Wasm filter envoy配置示例
04 Proxy接收过程Proxy接收过程
Envoy的Wasm filter配置本身是不支持使用OCI镜像格式作为data source的。那么Istio是如何支持使用OCI镜像分发Wasm二进制的呢？
答案是通过istio-agent的代理。Istio的proxy中包含两个进程，一个是Envoy本身，另一个是istio-agent。istio-agent会代理Envoy与istiod之间的xDS通信。对于ECDS，istio-agent在收到推送时，会读取其内容，假如其中的Wasm filter使用OCI镜像或者http/https作为data source（即需要执行的Wasm二进制），那么istio-agent会从远程仓库中拉取该Wasm二进制并缓存至本地。之后会修改ECDS的内容，将Wasm filter的data source改为刚才保存的本地文件，再将修改后的ECDS内容发送给Envoy。
对Wasm为Envoy带来新的扩展性的价值简要总结：综上，Envoy和Istio对Wasm的支持大大加强了服务网格的扩展性。用户通过Wasm能够以可扩展、灵活、安全的方式对代理进行自定义配置，应对各种场景的业务需求，例如认证、授权、Tracing、请求内容转换/检查等等。同时，Istio提供的API使Wasm成为了服务网格中的“一等公民”，用户可以方便地将Wasm下发到指定的工作负载，该过程是完全动态的，应用无需重启。这种高效率的扩展方式使得服务网格具备了可编程性。
05 未来展望
目前，Wasm仍在快速发展，相关的特性在Istio和Envoy中还处在alpha阶段。为了加速Wasm生态，让所有Wasm程序有一个“common language”，社区正在设计一个标准的Wasm interface —— WASI（WebAssembly System Interface），用于访问和操作系统资源。未来proxy-wasm可能会与WASI融合，为Wasm程序提供一个标准的交互接口。同时，Wasm将支持更多高级语言作为前端，用于构建轻量、高性能的应用程序。随着Wasm生态的逐步成熟，期待它能在云计算领域中带来更多令人兴奋的可能性。