Wasmtime 与 Wasmer 用于生产 Edge Functions

WebAssembly 早已为浏览器指定了一种运行时格式。多年来，它还被用于在服务器端或边缘执行沙盒代码：字节码编译一次，可在任何主机上移植，默认情况下隔离，无需容器或完整的虚拟机。 Wasmtime 和 Wasmer 将这个扩展从浏览器中携带出来，两者都是用 Rust 编写的，都能够执行相同的 .wasm文件。

Wasmtime 是由字节码联盟托管的项目，该组织管理 WebAssembly 服务器生态系统的多个组件，包括 Cranelift 编译器。 Wasmer 由 Wasmer Inc. 开发，该公司将运行时作为开源发布，同时营销围绕其的补充服务（边缘部署、工具）。两种不同的治理模型，不对其中之一生成的代码质量进行判断。

本文的其余部分比较了四个可验证的领域：许可和治理、可用编译器、WASI 标准和组件模型、安全模型，然后通过支持代码解释为什么 Aurabase 的 Rust 核心 在其 Edge Functions 引擎中运行 Wasmtime。

Wasmtime 是在 Apache-2.0 许可证下发布的，LLVM 例外，这是编译器生态系统中常见的宽松许可证。其治理遵循字节码联盟模型：多个组织为该项目做出贡献，没有一个组织单独拥有该项目。

Wasmer 是在 MIT 许可下发布的，在纸面上更宽松，但其技术方向仍然集中在单一出版商 Wasmer Inc 上。这本身并不是错误：许多成功的开源项目都遵循这种模式。如果您的组织重视跨多个实体的分布式治理，这只是不同的风险状况。

Wasmtime 通过同样来自字节码联盟的代码生成器 Cranelift 在生产中进行编译。该板条箱还记录了一个额外的编译器 Winch，与 Cranelift 相比，它旨在在对启动敏感的情况下减少编译时间。aura-functions 的 Cargo.toml 仅激活 cranelift 功能：正是这个编译器，并且单独处理生产中加载的每个 WASM 模块。

Wasmer 采取了相反的路径：三个可互换的后端。 Singlepass 几乎可以立即进行一次编译，但代价是优化程度较低的机器代码。 Cranelift 提供了一种平衡的折衷方案。 LLVM 旨在实现最佳的执行吞吐量，并具有三者中最长的编译时间。单个运行时，配置期间选择的三个折衷配置文件。

WASI（WebAssembly 系统接口）标准化了从 WASM 模块对文件、时钟和网络的访问，而不依赖于浏览器。其最新版本 WASI Preview 2 基于组件模型：一种用不同语言编写的模块组合机制，具有共享类型接口，而不是特定于每个运行时的二进制格式。 Wasmtime 和 Wasmer 都在按照各自的进度致力于实施这一标准。

Wasmer 还记录了 WASIX，这是一个扩展，旨在涵盖官方 WASI 标准尚未涵盖的 POSIX 原语，例如线程或更全面的网络套接字。这不是 WebAssembly 工作组支持的标准，而是特定于 Wasmer 生态系统的扩展。

两个运行时都将每个模块隔离在其自己的线性内存中，除了显式导入的函数之外，无法直接访问主机系统。这是两个项目共有的 WebAssembly 安全模型的基础。

Wasmtime 还公开了一个本机执行片段 API，fuel：每条指令消耗预先固定的预算，一旦预算耗尽，执行就会正确停止。第二个 API，epoch中断，允许您在等待时施加超时，而不会阻塞引擎。 Wasmer 记录了他自己的计量机制和每个实例的内存限制；本文尚未在第三方存储库中验证它们，因此不会逐图分解它们。

这正是 Aurabase 的 aura-functions 服务所支持的功能，下一节将通过实际源代码详细介绍。

aura-functions 服务将 wasmtime 声明为生产依赖项，没有停用注释或开发依赖项配置。存储库中没有文件，无论是 Cargo.toml 还是 .rs文件，都没有提到 Wasmer。

# WASM 运行时
wasmtime = { version = "43", features = ["async", "cranelift"] }

初始化代码按纪元显式激活燃料和中断，然后通过调用 StoreLimits来限制内存：

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);
let engine = Engine::new(&cfg)?;

// 通过调用：
let limits = StoreLimitsBuilder::new()
    .memory_size(self.max_memory_mb as usize * 1024 * 1024)
    .build();
store.set_fuel(self.max_fuel)?;
store.epoch_deadline_async_yield_and_update(1);

所有三个限制均可根据环境变量进行配置，并在 config/mod.rs中检查默认值：WASM_MAX_MEMORY_MB 为 64，WASM_TIMEOUT_SECS 为 10，WASM_MAX_FUEL 为 10 亿单位。超时在后台触发：tokio::spawn 等待配置的持续时间，然后增加引擎纪元，而不会在等待时阻塞当前执行。

暴露给来宾模块的 ABI 故意保持最小：四个主机函数 aura.log、 aura.get_input、 aura.set_output 和 aura.get_env，通过 linker.func_wrap注册。它不是组件模型，也不是 WASI Preview 2：它是一个内部合约，范围更窄，专为一次性使用而设计，执行 HTTP 边缘函数并恢复其 JSON 响应。

此 wasm 模式是每个函数的选择，而不是全局切换。 Aurabase 架构概述 详细介绍了另一个路径，即默认的 deno模式，该模式在单独的服务中执行 JavaScript/TypeScript。两者共存于同一个 aura-functions服务中。

来源：来自 Aurabase 存储库的 Cargo.toml 和 wasm/mod.rs，于 2026 年 8 月 24 日直接验证。Wasmtime 和 Wasmer 的一般特征取自每个项目的公共文档；该表中没有重新发布第三方基准数据。

您启动一个新的边缘运行时，没有现有的依赖项。 Wasmtime 由多供应商基金会支持，降低了项目未来依赖单一发布商的风险。

您有非常频繁且短暂的冷启动。 Wasmer 的 Singlepass 后端直接响应了这种需求，几乎是即时编译，但代价是优化程度较低的机器代码。

您需要超出当前标准 WASI 的 POSIX 原语。 WASIX，Wasmer 扩展，涵盖了 WASI Preview 2 单独尚未涵盖的线程和扩展套接字。

您想要一个本机素材和超时 API，无需第三方中间件。 Wasmtime 直接在板条箱中公开 fuel 和 epoch，这正是 aura-functions 在 Aurabase 中实现的功能。