重新定义代理的扩展性：WebAssembly在Envoy与Istio中的应用

原文：https://istio.io/blog/2020/wasm-announce/
作者：CRAIG BOX, MANDAR JOG, JOHN PLEVYAK, LOUIS RYAN, PIOTR SIKORA (GOOGLE), YUVAL KOHAVI, SCOTT WEISS (SOLO.IO)
译者：陆培尔

编者按

Istio的架构在1.5版本中发生了翻天覆地的变化，控制平面从微服务回归单体，pilot、citadel、galley等控制平面组件整合成了单一的istiod二进制文件，同时饱受诟病的mixer同志终于在1.5中deprecated了，社区呼声很高的Wasm以Proxy-Wasm plugins的方式登上历史舞台，官方承诺在1.6版本中提供标准的wasm插件配置API，甚至还推出了webassemblyhub这样的类似应用商店的服务，构建wasm plugin生态的野心不可谓不大。结合代理无关的ABI标准，只能说谷歌又在下一盘大棋。mixer的两大核心功能，check和report，分别使用Proxy-Wasm plugins和telemetry V2替代，曾经所谓的Mixer V2计划也渐渐烟消云散，湮没在历史尘埃中。本文翻译官方的技术博客，来一探本次的划时代变更proxy-wasm plugin的究竟。

自2016年采用Envoy以来，Istio项目一直希望提供一个平台，在此平台上可以构建丰富的扩展，以满足用户的多样化需求。有很多理由可以向服务网格的数据平面添加功能-支持更新的协议，与专有安全控件集成或通过自定义指标增强可观察性等。

在过去的一年半中，我们在Google的团队一直在努力使用WebAssembly向Envoy代理添加动态可扩展性。我们很高兴今天与大家分享这项工作，并推出WebAssembly (Wasm) for Proxies (Proxy-Wasm)：我们打算标准化的ABI；SDK；它的第一个主要实现是新型的，低延迟的Istio遥测系统。

我们还与社区紧密合作，以确保为用户提供良好的开发人员体验，以帮助他们快速入门。Google团队一直与Solo.io团队紧密合作，他们已经构建了WebAssembly Hub，该服务用于构建，共享，发现和部署Wasm扩展。使用WebAssembly Hub，Wasm扩展与容器一样易于管理，安装和运行。

这项工作今天发布了Alpha版本，还有很多工作要做，但是我们很高兴将其交到开发人员手中，以便他们可以开始尝试由此带来的巨大可能性。

背景

Istio和Envoy项目的创建原则都是基于对可扩展性的需求，但是两个项目采用了不同的方法。Istio项目的重点是启用具有轻量级开发人员体验的称为Mixer的通用进程外扩展模型，而Envoy则专注于代理内扩展。

每种方法都有其优点和缺点。Istio模型导致严重的资源效率低下，从而影响了尾部延迟和资源利用率。该模型在本质上也受到限制-例如，它永远不会为实现自定义协议处理提供支持。

Envoy模型强化了整体的构建过程，并要求使用C++编写扩展，从而限制了开发人员生态系统。为集群发布新的扩展需要推入新的二进制文件并重新启动，这可能很难协调，并且会造成停机风险。这也激励了开发人员向Envoy上游提交他们的扩展，而这些扩展仅由一小部分生产环境使用，只是为了肩负其发布机制。

随着时间的流逝，Istio的一些对性能最敏感的功能已进入Envoy的上游，例如流量策略检查和遥测报告。尽管如此，我们一直希望将单个堆栈融合以实现可扩展性，从而减少折衷：这使Envoy版本与其扩展生态系统脱钩，使开发人员能够使用他们选择的语言进行工作，并使Istio可靠地推出新功能而不会造成停机风险。

什么是WebAssembly？

WebAssembly（Wasm）是一种可移植的字节码格式，用于以接近本机的速度执行以多种语言编写的代码。其最初的设计目标与上述挑战很好地吻合，并且在其背后得到了可观的行业支持。Wasm是在所有主要浏览器中本地运行的第四种标准语言（继HTML，CSS和JavaScript之后），于2019年12月成为W3C Recommendation。这使我们有信心对其进行战略下注。

尽管WebAssembly最初是作为客户端技术而诞生的，但在服务器上使用它具有许多优点。运行时是内存安全的，并且经过沙盒处理以确保安全。有一个大型工具生态系统可用于以文本或二进制格式编译和调试Wasm。W3C和BytecodeAlliance已成为其他服务器端工作的活跃中枢。例如，Wasm社区正在W3C标准化“WebAssembly系统接口”（WASI），并提供一个示例实现，该示例为Wasm“程序”提供类似于OS的抽象。

为Envoy带来WebAssembly

在过去的18个月中，我们一直与Envoy社区合作，将Wasm可扩展性纳入Envoy并在上游做出贡献。我们很高兴地宣布，此特性在Istio 1.5随附的Envoy版本中Alpha可用，其源代码包含在envoy-wasm开发分支中，并且正在努力将其合并到Envoy主干中。该实现使用内置在Google高性能V8引擎中的WebAssembly运行时。

除了底层的运行时，我们还构建了：

用于在代理中嵌入Wasm的通用应用程序二进制接口（ABI），这意味着编译后的扩展将在不同版本的Envoy或其他代理（如果他们选择实施ABI）下也可以使用
用于在C++，Rust和AssemblyScript中轻松进行扩展开发的SDK，还有更多后续更新
有关如何在Istio和独立的Envoy中进行部署的综合示例和说明
允许使用其他Wasm运行时的抽象，包括“空”运行时，该运行时将在本地把扩展编译进Envoy中，这对于测试和调试非常有用

使用Wasm扩展Envoy可以为我们带来几个主要好处：

敏捷性：可以使用Istio控制平面在运行时交付和重新加载扩展。这样可以快速进行扩展的开发→测试→发布周期，而无需Envoy的重启。
标准发布：合并到主树中之后，Istio和其他人将能够使用Envoy的标准发布，而不是自定义版本。这也将使Envoy社区有更多的时间将某些内置扩展迁移到该模型，从而减少其受支持的覆盖区域。
可靠性和隔离性：扩展部署在具有资源限制的沙箱中，这意味着它们现在可以崩溃或泄漏内存，而不会影响Envoy主进程。CPU和内存使用率也可以受到限制。
安全性：沙盒具有用于与Envoy进行通信的明确定义的API，因此扩展只能访问并修改连接或请求中有限数量的属性。此外，由于Envoy会协调此交互过程，因此可以隐藏或清除扩展中的敏感信息（例如，HTTP标头中的“Authorization”和“ Cookie”属性，或客户端的IP地址）。
灵活性：可以将30多种编程语言编译为WebAssembly，从而使来自各种背景（C++，Go，Rust，Java，TypeScript等）的开发人员都可以使用他们选择的语言来编写Envoy扩展。

“看到WASM在Envoy中的支持，我感到非常兴奋；这是Envoy可扩展性的未来。Envoy的WASM支持与社区驱动hub相结合，将在服务网格和API网关用例中释放出令人难以置信的网络领域创新。我迫不及待地想看到社区的建设向前发展。” –Envoy创作者Matt Klein。

有关实现的技术细节，请关注即将在Envoy博客上发布的帖子。

主机环境和扩展之间的Proxy-Wasm接口有意设计为与代理无关。我们已将其内置到Envoy中，但旨在供其他代理供应商采用。我们希望看到一个世界，您可以获取为Istio和Envoy编写的扩展，并在其他基础架构中运行它。您很快就会听到更多有关此的信息。

在Istio中构建WebAssembly

为了提高性能，Istio将其几个扩展移动到了1.5版本中内置的Envoy构建中。在执行此工作时，我们一直在测试以确保这些相同的扩展可以作为Proxy-Wasm模块进行编译和运行，而行为没有任何变化。鉴于我们认为Wasm目前的支持为Alpha，因此我们还没有准备好将此设置设为默认设置。然而，这使我们对通用方法以及已开发的主机环境ABI和SDK充满了信心。

我们还非常小心地确保Istio控制平面及其Envoy配置API可以支持Wasm。我们有一些示例来说明如何执行几种常见的定制操作，例如定制标头解码或程序化路由，这是用户的常见要求。当我们将支持转移到Beta时，您将看到说明在Istio中使用Wasm的最佳实践的文档。

最后，我们正在与许多编写了Mixer适配器的供应商合作，以帮助他们迁移到Wasm —如果这是前进的最佳途径。Mixer将在将来的版本中转为社区项目，在那里它将仍可用于遗留用例。