1 Wasm为Envoy带来新的扩展性
Envoy是一个高性能、可编程的L3/L4和L7网络代理，许多服务网格和网关都采纳Envoy作为数据面。
Envoy通过监听器（Listener）捕捉网络数据包，依据数据包的内容匹配某个过滤器链（Filter Chain）中，之后按程序执行该链中的过滤器（Network Filter）对捕捉的数据包进行操作，实现用户定义的各种流量治理策略。Envoy自身自带很多品种的过滤器，这些开箱即用的过滤器 cover了大部分的利用场景，然而在某些须要自定义性能的场景下，用户必须实现本人的过滤器。


Envoy filter chains
在Wasm呈现之前，增加过滤器有两种形式：

  1. 批改Envoy代码，应用C++语言编写原生的过滤器（Native C++ filters）。在晚期（2019年初），Envoy是一个动态编译的二进制文件，其所有扩大都在构建时编译。这意味着提供自定义扩大的我的项目必须保护和散发本人的二进制文件。这种形式须要开发者相熟C++语言和Envoy过滤器的开发模式，在开发实现后从新编译一个新的Envoy二进制且保护它与上游社区的版本。目前Istio社区采纳的就是这种形式，Istio fork了上游的Envoy，在其根底之上增加了本人定制的一些插件。然而，这种形式对开发者要求较高，且须要破费额定的精力保护。
  2. 应用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生态的逐渐成熟，期待它能在云计算畛域中带来更多令人兴奋的可能性。