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已经成为了云原生项目的扩展利器，而且很是有可能成为云原生工做负载的最佳运行时。