WebAssembly--云原生项目可扩展性的利器

尽管在诞生之初，WebAssembly（简称Wasm）目的是为浏览器带来高级编程的功能 -- 它提供了一条途径，以使得以各种语言编写的代码都可以以接近原生的速度在Web中运行。在这种情况下，以前无法以此方式运行的客户端软件都将可以运行在Web中。

但是随着最近几年的发展，Wasm 凭借着以下几个特性：

1. 接近原生性能运行
2. 沙箱
3. 可移植性，build once， run everywhere

给云原生项目带来了可扩展性。

接下来我们通过几个云原生项目，来看看Wasm 是如何成为可扩展性的利器。

Envoy 和 Istio

Envoy是专为大型现代服务架构设计的L7代理和通信总线。其已经成为了Service Mesh 解决方案数据面事实上的标准。

但是我们在应用Envoy的过程中，我们可能希望插入其他业务逻辑，例如度量，可观察性，转换，数据丢失预防，合规性验证或其他功能。

不过编写和添加自定义Envoy模块有点繁琐。你必须使用C++编程并在Envoy中重新编译。

为了解决这个问题，Envoy 社区在 Envoy 中嵌入了 WASM 虚拟机以获得一个安全的沙箱环境，用于动态加载和运行可拔插的扩展代码（被编译为 WASM 字节码），简化 Envoy 二次开发和功能增强的复杂度。

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

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

在Envoy支持Wasm之后，istio也通过这种扩展机制，移除了Mixer组件，将现有的 out-of-process 的插件模型最终用基于 WASM 的 in-proxy 扩展模型来替代，极大提升了网格的性能。

OPA

Open Policy Agent（简称OPA）是一种开放源代码的通用策略引擎，它统一了整个技术栈中的策略执行。 OPA背后的原则之一是策略评估与策略执行解耦。

在 OPA v0.15.1之前，各种基础设施需要嵌入策略评估引擎。

由于OPA策略评估引擎是使用golang编写，所以对于其他编程语言，集成OPA存在一定难度。其他语言只能通过Restfull API的方式。

在OPA v0.15.1+版本，OPA 引入了Wasm来解决该问题。OPA包含一个接受Rego策略作为输入并生成可执行的Wasm程序作为输出的编译器。该Wasm程序可以加载到任何标准的Wasm运行时中，并在需要策略决策时执行。

容器 和 Kubernetes

随着Wasm的发展，WebAssembly system interface（简称Wasi）出现了。WASI代表WebAssembly系统接口。这是由Wasmtime项目设计的API，可提供对几种类似操作系统的功能的访问，包括文件和文件系统，Berkeley套接字，时钟和随机数。

此时Wasm的沙箱机制带来的隔离性和安全性，都比Docker做的更好。Docker的创始人也曾说过:"如果WASM + WASI在2008年存在，我们就不需要创建Docker。"

用于创建可以与容器相同的方式运行的有效二进制可执行文件。Wasm有潜力成为Docker的重要替代部署单元。

Wasm container 与 Kubernetes的集成，目前有两种思路：

Krustlet

Krustlet是一个用 Rust 开发的开源 Kubernetes kubelet，用于在 Kubernetes 中运行 WebAssembly 工作负载。

目前这是一个实验性质的项目。

container-shim-wasm

该思路相对Krustlet，更加合理，侵入性也比较小。我们只需要实现container-shim-wasm，使containerd直接可以管理 Wasm container。

该方案与kata，firecracker集成Kubernetes 的实现思路都比较类似。

相信随着Wasi的完善，我们不久的将来，在kubernetes中，可以通过RuntimeClass指定，在node节点运行Wasm container。

Serverless

其实截止目前，已经有大量的组织将Wasm用于serverless的场景。比如：

Second State提供了一个开源WebAssembly实现（Second State Virtual Machine，或SSVM），该实现专门针对服务器端应用程序进行了优化。它是

• 同类最佳的性能。对于冷启动，它比Docker快1000倍。
• 无缝支持服务器应用程序框架，例如Node.js。您可以使用SSVM构建高性能的Node.js应用程序。
• 支持安全访问外部资源，例如数据库，消息队列，甚至是新的AI硬件
• 允许精确计量无服务器应用程序的计算资源。

Second State 已经支持Wasm用于AI，区块链等场景。

而Cloudflare也早已推出了自己的Serverless 产品 Cloudflare Workers。

边缘计算

边缘运行的物联网设备正在推动计算的未来，这已不是什么秘密。但是，许多设备缺少最佳的计算硬件或其他资源，例如电源，网络和存储。

现在诸多基于Kubernetes的边缘计算解决方案(kubeedge等），其边缘工作运行时依旧是docker。这种做法不是最理想的，尤其是对于物联网和边缘计算用例。

我们是否可以在边缘端直接运行Wasm哪？

随着Wasm通用运行时wasmer 1.0 GA，其推出了Headless版本。该版本提供尽可能轻量级的执行环境，这对于在边缘的IoT设备上高效运行Wasm至关重要。

借助对AOT编译的新增支持，我们可以运行“headless”版本的Wasmer，其重量仅为数百KB，并且可以在任何设备上运行任何预编译的Wasm二进制文件。

总结

Wasm已经成为了云原生项目的扩展利器，并且非常有可能成为云原生工作负载的最佳运行时。