重塑代理的可扩展性 - 将 WebAssembly 引入 Envoy 和 Istio

使用 WASM 实现 Istio 可扩展性的未来。

2020 年 3 月 5 日 | 作者：Craig Box、Mandar Jog、John Plevyak、Louis Ryan、Piotr Sikora - Google，Yuval Kohavi、Scott Weiss - Solo.io

自从 2016 年采用 Envoy 以来，Istio 项目一直希望提供一个平台，在这个平台上可以构建丰富的扩展集，以满足用户的各种需求。 有很多理由需要为服务网格的数据平面添加功能 - 为了支持更新的协议、与专有安全控制集成，或者使用自定义指标来增强可观察性，仅举几例。

在过去一年半的时间里，我们 Google 的团队一直在努力使用 WebAssembly 为 Envoy 代理添加动态可扩展性。 我们很高兴今天与世界分享这项工作，并揭开 WebAssembly（Wasm）用于代理（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 - 例如，对流量的策略检查和 JWT 身份验证。 尽管如此，我们始终希望收敛到一个可扩展性的单一堆栈，以减少权衡：能够将 Envoy 发布与扩展生态系统分离，使开发人员能够使用他们选择的语言工作，以及使 Istio 能够可靠地推出新功能而不会出现停机风险。 让我们来谈谈 WebAssembly。

什么是 WebAssembly？

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

虽然 WebAssembly 最初是作为一种客户端技术而诞生的，但在服务器上使用它也有一些优势。 运行时是内存安全的，并且为了安全而被沙箱化。 存在一个庞大的工具生态系统，用于以文本或二进制格式编译和调试 Wasm。 W3C 和 BytecodeAlliance 已成为其他服务器端努力的活跃中心。 例如，Wasm 社区正在 W3C 标准化一个 “WebAssembly 系统接口”(WASI)，以及一个示例实现，它为 Wasm“程序”提供类似操作系统的抽象。

将 WebAssembly 引入 Envoy

在过去的 18 个月里，我们一直在与 Envoy 社区合作，将 Wasm 可扩展性构建到 Envoy 中，并将其贡献到上游。 我们很高兴地宣布，它已作为 Alpha 版本在随 Istio 1.5 一起发布的 Envoy 构建中可用，源代码位于 envoy-wasm 开发分支中，并且正在进行将其合并到 Envoy 主树的工作。 该实现使用 Google 高性能 V8 引擎 中内置的 WebAssembly 运行时。

除了底层运行时之外，我们还构建了

使用 Wasm 扩展 Envoy 为我们带来了几个主要优势

“我很高兴看到 WASM 支持在 Envoy 中实现； 这是 Envoy 可扩展性的未来，毫无疑问。 Envoy 的 WASM 支持与社区驱动的中心相结合，将在服务网格和 API 网关用例中释放网络领域中难以置信的创新。 我迫不及待地想看看社区接下来会构建什么。” – Matt Klein，Envoy 创建者。

有关实现的技术细节，请关注即将发布的 Envoy 博客 文章。

Proxy-Wasm 主机环境和扩展之间的接口刻意与代理无关。 我们已将其构建到 Envoy 中，但它被设计为供其他代理供应商采用。 我们希望看到一个世界，在那里你可以将为 Istio 和 Envoy 编写的扩展带到其他基础设施中运行； 你很快就会听到更多关于这方面的信息。

在 Istio 中构建 WebAssembly

Istio 在 1.5 版本中将其多个扩展迁移到其 Envoy 构建中，以显着提高性能。 在进行这项工作时，我们一直在测试以确保这些相同的扩展可以编译并作为 Proxy-Wasm 模块运行，而行为没有任何变化。 考虑到我们认为 Wasm 支持处于 Alpha 状态，我们还没有准备好将此设置设为默认值； 但是，这让我们对我们的一般方法以及已开发的主机环境、ABI 和 SDK 充满了信心。

我们还很小心地确保 Istio 控制平面及其 Envoy 配置 API 已准备好用于 Wasm。 我们有一些示例展示了如何执行一些常见的自定义操作，例如自定义标头解码或编程路由，这些都是用户常见的请求。 随着我们将此支持迁移到 Beta 版本，你会看到显示使用 Wasm 与 Istio 的最佳实践的文档。

最后，我们正在与许多为 Mixer 适配器 编写代码的供应商合作，帮助他们迁移到 Wasm - 如果这是最合适的路径。 Mixer 将在未来的版本中迁移到一个社区项目，它将继续可用于遗留用例。

开发体验

如果没有良好的开发体验，强大的工具将毫无用处。 Solo.io 最近宣布发布了 WebAssembly Hub，这是一套工具和存储库，用于构建、部署、共享和发现用于 Envoy 和 Istio 的 Envoy Proxy Wasm 扩展。

WebAssembly Hub 自动化了开发和部署 Wasm 扩展所需的大多数步骤。使用 WebAssembly Hub 工具，用户可以轻松地将其代码（以任何支持的语言）编译成 Wasm 扩展。然后，这些扩展可以上传到 Hub 注册表，并通过单个命令部署和取消部署到 Istio。

在幕后，Hub 处理了许多繁琐的任务，例如拉取正确的工具链、ABI 版本验证、权限控制等等。此工作流程还通过自动部署扩展来消除 Istio 服务代理之间的配置更改带来的繁琐操作。此工具帮助用户和操作人员避免因配置错误或版本不匹配而导致的意外行为。

WebAssembly Hub 工具提供了一个强大的 CLI 以及一个优雅且易于使用的图形用户界面。WebAssembly Hub 的一个重要目标是简化构建 Wasm 模块的体验，并为开发人员提供一个协作场所来共享和发现有用的扩展。

查看入门指南，创建您的第一个 Proxy-Wasm 扩展。

下一步

除了致力于发布 Beta 版本外，我们还致力于确保 Proxy-Wasm 周围有一个持久的社区。ABI 需要最终确定，将其转变为标准将通过适当的标准机构进行更广泛的反馈来完成。将上游支持完成到 Envoy 主线仍在进行中。我们还在寻找一个适合工具和 WebAssembly Hub 的社区家园。

了解更多

分享此帖子