重新定义代理的扩展性：介绍 Envoy 和 Istio 中的 WebAssembly 应用

黑光技术

修改于 2020-05-15 11:33:03

7070

修改于 2020-05-15 11:33:03

翻译 Istio 官网 blog 文章，原文：https://istio.io/blog/2020/wasm-announce/。

翻译几天了，不过官网git提交有点问题，大家还在努力解决中，先发这里了。

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

在过去的一年半中，我们在Google的团队一直在努力用 WebAssembly 来为 Envoy 代理添加动态扩展。今天我们很高兴与大家分享这项工作，并推出针对代理的 WebAssembly (Wasm) (Proxy-Wasm)：包括一个会标准化的ABI，SDK，以及它的第一个重点实现：新的，低延迟的 Istio 遥测系统。

我们还与社区紧密合作，以确保为用户提供良好的开发者体验，帮助他们快速上手。 Google 团队一直与 Solo.io 团队紧密合作，Solo 他们已经建立了 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 正式建议。这使我们有信心对其进行战略下注。

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

把 WebAssembly 引入 Envoy

在过去的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 中 “null” 运行时，这对于测试和调试非常有用

使用 Wasm 扩展 Envoy 带来了几个主要好处：

敏捷性：可以用 Istio 控制平面在运行时下发和重载扩展。这就可以快速的进行扩展开发→测试→发布周期，而无需重启 Envoy。
发布库：一旦完成合并到主树中之后，Istio 和其它程序将能够使用 Envoy 的发布库，而不是自己构建。这也方便 Envoy 社区迁移某些内置扩展到这个模型，从而减少他们的工作。
可靠性和隔离性：扩展部署在具有资源限制的沙箱中，这意味着它们现在可以崩溃或泄漏内存，但不会让整个 Envoy 挂掉。CPU 和内存使用率也可以受到限制。
安全性：沙盒具有一个明确定义的 API，用于和 Envoy 通信，因此扩展只能访问和修改链接或者请求中有限数量的属性。此外，由于 Envoy 协调整个交互，因此它可以隐藏或清除扩展中的敏感信息（例如，HTTP 头中的 “Authorization”和“Cookie”，或者客户端的 IP 地址）。
灵活性：可以将超过 30 种编程语言编译为 WebAssembly，可以让各种技术背景的开发人员都可以用他们选择的语言来编写 Envoy 扩展，比如：C++，Go，Rust，Java，TypeScript 等。

“看到 Envoy 上支持了 WASM，我感到非常兴奋；这是 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 将在未来的版本中转为社区项目，它将仍可用于老系统。