wasm

WASI 运行时与服务器端 WebAssembly

深入讲解 WASI 标准：WASM 从浏览器走向服务器的关键一步。对比主流运行时 Wasmtime/Wasmer/WasmEdge，实战文件系统、网络、时钟等系统接口调用，以及 WASM 微服务的安全模型与部署策略。

spcent 2026-09-22 5 分钟阅读 2502 字

导语：WASM 离开浏览器

WebAssembly 最初的设计目标很明确：在浏览器中运行高性能代码。但当它的安全沙箱、快速启动、平台无关等特性被深入理解后，一个更大的场景浮现——服务器端。

服务器端运行 WASM 面临一个问题：浏览器环境提供了 web-sys（DOM、fetch、WebSocket），但服务器需要什么？文件系统、网络套接字、环境变量、随机数生成、高精度时钟——这些都是操作系统能力，而标准 WASM 规范故意不定义这些。

WASI（WebAssembly System Interface） 就是填这个坑的标准。它定义了一套模块化的系统接口，让 WASM 模块能在脱离浏览器的环境中安全地使用 OS 能力。

一句话总结：WASI 是 WASM 走出浏览器进入云原生世界的桥梁，它让 WASM 模块在保持沙箱安全的同时访问文件、网络和系统时钟。

1. WASI 是什么

WASI 是一个模块化、基于能力（capability-based）的系统接口标准，由字节码联盟（Bytecode Alliance）主导制定。核心设计原则：

模块化：接口按功能拆分为独立模块（如 wasi-filesystem、wasi-sockets、wasi-clocks），宿主只需要实现需要的模块
能力安全：WASM 模块不自动获得任何系统权限，宿主必须显式"注入"权限（如"只能读写 /tmp 目录"）
POSIX 子集：API 风格接近 POSIX，让 C/C++ /Rust 的移植成本降到最低
版本快照：以"world"和"package"概念管理版本（如 wasi:cli/command@0.2.0）

WASI 的版本演进：

版本	特点	状态
WASI Preview 1	基于 `wasi_unstable` / `wasi_snapshot_preview1`，以 `fd_*` 风格描述文件操作	广泛使用，但设计有局限
WASI Preview 2	引入组件模型（Component Model），以 WIT（WASM Interface Types）定义接口	主流方向，工具链逐渐成熟
WASI Preview 3	加入异步/流式支持	制定中

一句话总结：WASI Preview 2 + 组件模型是 WASI 的未来，它让不同语言编译的 WASM 模块可以用标准接口互操作。

2. 编写 WASI 程序

以 Rust 为例，编译一个使用文件系统和命令行参数的 CLI 程序：

Cargo.toml

[package]
name = "wasi-cat"
version = "0.1.0"
edition = "2021"

[profile.release]
opt-level = 3
lto = true

src/main.rs

use std::env;
use std::fs::File;
use std::io::{self, Read, Write};

fn main() {
    let args: Vec<String> = env::args().collect();
    
    if args.len() < 2 {
        eprintln!("用法: wasi-cat <文件路径>");
        std::process::exit(1);
    }

    let path = &args[1];
    let mut file = File::open(path).expect("无法打开文件");
    let mut contents = String::new();
    file.read_to_string(&mut contents).expect("读取失败");

    // 写入标准输出（WASI 中 stdout 是 fd=1）
    let stdout = io::stdout();
    let mut handle = stdout.lock();
    handle.write_all(contents.as_bytes()).unwrap();
}

编译为 WASI 目标

# 安装 WASI 编译目标
rustup target add wasm32-wasip1

# 编译
cargo build --target wasm32-wasip1 --release
# 输出：target/wasm32-wasip1/release/wasi-cat.wasm

一句话总结：Rust CLI 程序可以几乎零改动地编译为 WASI 目标，只要用 wasm32-wasip1 替代默认目标。

3. 主流 WASI 运行时对比

运行时	维护方	特点	适用场景
Wasmtime	字节码联盟(Bytecode Alliance)	Rust 编写，WASI Preview 2 最完整实现，组件模型支持最好	生产级服务器、嵌入 CLI 工具
Wasmer	Wasmer Inc.	多语言绑定（Python/Go/Ruby）、头文件自动生成、包管理器(Wapm)	多语言集成、快速原型
WasmEdge	CNCF 沙箱项目	Rust/C++ 混合、内置 networking(tensorflow/图像处理)、Kubernetes 集成	边缘计算、AI 推理、云原生
WAMR	Intel/字节码联盟	占地面积极小（~100KB）、支持 AOT 编译	嵌入式/IoT
wasm3	社区驱动	纯解释执行、性能中等但体积最小	MCU/资源受限设备

Wasmtime 实战

# 安装
wget https://github.com/bytecodealliance/wasmtime/releases/download/v21.0.0/wasmtime-v21.0.0-x86_64-linux.tar.xz
tar -xJf wasmtime-v21.0.0-x86_64-linux.tar.xz
sudo mv wasmtime /usr/local/bin/

# 运行（默认沙箱：无文件系统权限）
wasmtime run target/wasm32-wasip1/release/wasi-cat.wasm
# → panic: 无法打开文件（因为没有文件系统权限）

# 显式赋予目录映射权限
echo "Hello WASI" > /tmp/hello.txt
wasmtime run \
  --dir /tmp::/mnt \
  target/wasm32-wasip1/release/wasi-cat.wasm \
  /mnt/hello.txt
# → Hello WASI

关键点：

--dir /tmp::/mnt 将宿主 /tmp 映射为 WASM 内的 /mnt，隔离可见性
WASM 程序看到的文件系统是受限视图，越界访问会触发 trap
可以和 --env KEY=VALUE 注入环境变量

一句话总结：Wasmtime 的能力模型让"最小权限原则"在 WASM 中落地——默认什么都禁止，显式注入才开放。

4. WASM 在微服务中的优势

将 WASM 用于微服务（或更细粒度的模块）相比传统容器有几个独特优势：

4.1 启动速度

技术	冷启动时间	说明
Docker 容器	500ms - 2s	需要拉取镜像、创建 namespace、启动 init
gVisor/runsc	300ms - 1s	增加了安全层，但启动更慢
WASM + Wasmtime	1ms - 10ms	解包+实例化，无 OS 启动开销

4.2 密度更高

一台 8 vCPU / 32 GiB 的节点：
- Docker：容忍 50-100 个活跃容器（受限于内存和调度开销）
- WASM：可同时运行数千个模块实例（每个 <10MB 内存）

4.3 安全边界更细

传统容器共享内核，逃逸风险始终存在（Dirty COW、容器逃逸漏洞）。WASM 运行在用户态 VM 中：

没有系统调用接口（只能走 WASI）
内存越界立即 trap
即使模块被攻破，突破的只是 VM 边界（Wasmtime/Wasmer 有额外加固层）

4.4 执行中暂停与迁移

WASM 的确定性执行模型让快照/恢复成为可能：

# 伪代码：WASM 执行快照
engine = wasmtime.Engine()
store = wasmtime.Store(engine)
instance = wasmtime.Module.from_file(engine, "service.wasm")

# 执行到某状态后冻结
snapshot = store.capture_snapshot()
serialize(snapshot, file="job.state")

# 在另一台机器恢复
new_store = wasmtime.Store(engine)
new_store.restore_snapshot(deserialize("job.state"))
# 从断点继续执行

这在 Serverless 场景意义重大——函数可以"休眠"到磁盘，恢复时状态不丢失。

一句话总结：WASM 微服务的核心竞争力是"毫秒级冷启动 + 高密度 + 强隔离 + 可序列化执行"，这是 Docker 和 VM 都做不到的。

5. 与 Kubernetes 集成

WasmEdge 提供了 Kubernetes 集成方案，让 WASM 模块以"容器"的形式在 K8s 中运行：

# crun + WasmEdge shim
cat <<EOF | kubectl apply -f -
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: crun-wasm
handler: crun
overhead:
  podFixed:
    memory: "0"
    cpu: "0"
scheduling:
  nodeSelector:
    wasm-runtime: wasmedge
---
apiVersion: v1
kind: Pod
metadata:
  name: wasm-app
spec:
  runtimeClassName: crun-wasm
  containers:
  - name: app
    image: ghcr.io/wasmedge/wasm-app:latest
    # 这个镜像不是 Docker 镜像，而是 OCI 兼容的 WASM 模块包
EOF

运行时的集成路径：

Kubelet → CRI → containerd/cri-o → crun (替换 runc) → WasmEdge Runtime

一句话总结：通过 crun 替换默认的 runc，Kubernetes 可以直接调度 WASM 模块，无需sidecar 或额外适配层。

6. 总结

WASI 让 WebAssembly 走出了浏览器，成为云原生生态的新兴力量。它的核心优势不是性能（虽然性能很好），而是安全模型与启动速度的组合：

以能力为基础的安全模型天然适合多租户场景
毫秒级冷启动让 Serverless 真正"serverless "
可序列化执行的语义让任务迁移和断点续算成为可能

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章返回首页