可扩展性

Istio 提供了两种用于扩展 Istio 代理的机制：WebAssembly (Wasm) 和 Lua。 两者均通过 TrafficExtension API 进行配置； 该 API 提供了一种统一的方式，允许以一致的定位规则以及阶段/优先级顺序， 将扩展附加到工作负载上。

选择滤镜类型

通常而言，对于那些需要经过测试、版本管理及复用的生产级扩展， 应优先选用 WebAssembly；而对于轻量级、局部的变更， 若内联代码的简洁性优于对工具链的需求，则应优先选用 Lua。

WebAssembly 插件

WebAssembly 是一种用于更复杂扩展的沙箱技术。 Proxy-Wasm 沙箱 API 取代 Mixer，成为 Istio 中的主要扩展机制。

WebAssembly 沙箱目标：

• 效率 —— 扩展引入的延迟、CPU 和内存开销极低。
• 功能 —— 扩展能够执行策略、收集遥测数据，并对负载（Payload）进行修改。
• 隔离性 —— 某个插件中的编程错误或崩溃不会影响到其他插件。
• 配置 —— 插件通过一套与 Istio 其他 API 保持一致的 API 进行配置；扩展支持动态配置。
• 运维人员 —— 扩展支持金丝雀发布，并可配置为仅记录日志、 故障开放（Fail-open）或故障关闭（Fail-close）模式。
• 扩展开发者 —— 插件可以使用多种编程语言进行编写。

这段视频演讲是对 WebAssembly 集成架构的介绍。

高级架构

Istio 扩展（Proxy-Wasm 插件）包含多个组件：

• 过滤器服务提供接口（SPI）：用于构建过滤器的 Proxy-Wasm 插件。
• 沙箱（Sandbox）：嵌入在 Envoy 中的 V8 Wasm 运行时。
• 宿主 API（Host API）：用于处理请求头、尾部数据及元数据。
• 外部调用 API（Call out API）：用于发起 gRPC 和 HTTP 调用。
• 统计与日志 API（Stats and Logging API）：用于指标收集与监控。

示例

您可以在此处找到一个用于过滤器的 C++ Proxy-Wasm 插件示例。 您可以参照这份指南来使用 C++ 实现 Wasm 扩展。

生态系统

• Istio 生态系统 Wasm 扩展
• Proxy-Wasm ABI 规范
• Proxy-Wasm C++ SDK
• Proxy-Wasm Go SDK
• Proxy-Wasm Rust SDK
• Proxy-Wasm AssemblyScript SDK
• WebAssembly Hub
• 用于网络代理的 WebAssembly 扩展（视频）

Lua 脚本

Lua 过滤器提供了一种轻量级的内联脚本编写方式， 用于实现简单的请求和响应转换。Lua 代码直接内联在 TrafficExtension 资源中， 并在 Envoy 代理内部执行，无需进行模块分发。 Lua 过滤器最适合用于简单的标头操作、日志记录或条件逻辑处理。 对于更复杂的处理任务，建议使用 WebAssembly 过滤器。

Lua 的内存占用远小于 WebAssembly。 基准测试结果显示， 无论并发度如何，Lua 的内存消耗始终维持在 20–26 MiB 左右； 而 WebAssembly 的内存消耗则随并发度的变化而波动， 从低并发时的约 110 MiB 升至高并发时的约 290 MiB：