WASI 0.3组件服务链

WASI 0.3 实战 把鉴权、日志和业务逻辑串成一条 WebAssembly 组件服务链

能不能把鉴权、日志和业务处理各做成一个 WebAssembly 组件，再在同一进程里串起来？我先去看了 WASI 0.3 的接口定义，而没有先找一个“三组件服务器”的安装命令。原因很简单，接口是否允许这样连接，与现成工具能否把整条链编译、组装、启动，是两件需要分别核对的事。

2026 年 6 月，WASI 小组批准了 0.3.0。它最实在的变化是组件模型的异步能力进入规范。WASI 0.2 用 pollable、输入输出流资源和 start、finish 一类调用拼出异步过程。0.3 的规范改用 future<T>、stream<T> 和 async func。等待任务由宿主运行时调度，值穿过组件边界后，等待它的任务仍可由同一个调度机制唤醒。这里的“异步”并不意味着每个组件自己开一套事件循环。

我理解这项变化时，最关心的是请求体。HTTP 响应可以先返回头，再逐段发送内容。0.3 里 stream<u8> 表示字节流，相关操作还能返回一个独立的 future 报告最终状态。读取方即使提前停止消费，也不必只靠下一次读取才知道流的结果。这样描述比笼统地说“异步性能更好”更接近接口本身。官方文章提到进程内调用可能比网络调用快很多，那是架构上的潜力，不能直接换算成这条鉴权链的延迟数字。

接着看 wasi:http。0.3 发布版的 WIT 给出 service 和 middleware 两个 world。service 导出 handler.handle，供宿主把请求交给组件；它还导入 HTTP 客户端、时钟、随机数及标准流等能力。middleware 包含 service，另外导入一个 handler。于是鉴权组件可以导出自己的处理入口，检查请求后再调用导入的下游处理入口。日志组件同样占据一个上游与下游之间的位置，业务组件则只需做终点服务。

官方接口的关键几行可以缩写如下。省略号代表 service 中其他真实存在的导入，不能拿这段节选当成完整的官方 WIT 包去编译。发布版 worlds.wit 还有一条注释，要求宿主能够把同一个组件实例用于零次到多次 handle 调用，甚至可能并发调用。因此，若鉴权组件把“当前请求的用户”放在可共享的全局变量里，接口本身不会替应用避免串号。请求相关状态应跟着本次调用走，组件实例能否复用也要在宿主一侧明确。

interface handler {

use types.{request, response, error-code};

handle: async func(request: request)

-> result<response, error-code>;

}

world service {

// 这里省略其他导入

import client;

export handler;

}

world middleware {

include service;

import handler;

}

顺序可以写成“宿主 → 鉴权 → 日志 → 业务”。请求向右走，响应沿原路返回。鉴权失败时应由鉴权组件生成 401 响应，而不是把 HTTP 拒绝误当成底层传输错误。日志组件应考虑记录哪些字段，避免把凭据或完整请求体顺手写入日志。这里说的是按接口能够设计出的职责分工，还没有声称某个现成项目已按这个顺序运行。

这条链的价值也不在于把进程内函数调用改名。组件导入导出是明确的类型契约。组合时，下游 handler 的签名必须能接住上游的调用，宿主还能按 world 判断组件申请了哪些能力。业务组件若只作为终点，就没有继续导入下游 handler 的理由。另一方面，HTTP 客户端导入仍然存在，它可以用于真正的对外请求，也可能在特定组合中接到另一个处理器。用 client.send 绕过网络这一点写在官方 WIT 注释里，但具体怎样接线取决于组合工具和宿主配置，不能把“可以直连”读成“所有请求都会自动直连”。

下面先把 HTTP 类型缩成字符串，只保留组成服务链的接口骨架。这份 WIT 使用 demo:chain 命名空间，不能冒充 wasi:http@0.3.0 的完整定义。真实 HTTP 的 request、response 和 error-code 都在官方 types.wit 中，handler.handle 的正式签名是异步接收请求并返回 result<response, error-code>。

package demo:chain@0.1.0;

interface handler {

handle: async func(request: string) -> string;

}

world service {

export handler;

}

world middleware {

include service;

import handler;

}

这段代码里，export handler 是向上一环提供入口，import handler 是向下一环发起调用。两个方向使用同一接口，才有把一环接到下一环的基础。world 是组件对外的能力边界，不会自己完成接线。真正的连接还需要把每个组件编译成组件二进制，再由组合工具或宿主把导入绑定到对应的导出。

我在 Windows x86-64 上用 wasm-tools 1.263.0 验证了这个最小契约。将代码保存为 chain.wit，从该版本的官方发布页取得 Windows 可执行文件，随后在 PowerShell 中运行以下命令。第二步生成的是 WIT 包的 WebAssembly 表示，文件虽以 .wasm 结尾，却不是可启动的 HTTP 服务。

wasm-tools --version

wasm-tools component wit .\chain.wit

wasm-tools component wit .\chain.wit --wasm -o .\chain.wasm

wasm-tools validate .\chain.wasm

本机前三条命令完成，最后的校验也通过。这个验证只说明 WIT 语法、异步函数声明及导入导出结构可被当前工具解析，不能证明鉴权、日志或 HTTP 转发已经执行。读者若要继续往前走，需要选定能生成 WASI 0.3 客户端组件的语言工具链，分别实现两个 middleware 和一个 service，再检查生成组件的世界接口并进行组合。wac 项目提供 plug、compose 和 targets 等命令，但调用它们之前必须先有实际组件，单凭上面的 WIT 文件无法拼出服务链。

版本也要写在命令附近。发布公告在 2026 年 6 月写明，Wasmtime 45 当时运行候选版，Wasmtime 46 将默认启用正式 0.3；jco 的默认支持与多个语言的客户端工具链仍在推进。到本文核对时，Wasmtime 已有 50.0.1，wit-bindgen 已有 0.63.0，wac 已有 0.12.0。版本号更新不能自动证明任意语言生成的三个组件都能无调整地接入同一宿主。尤其是官方 service world 还有标准输入的临时兼容导入，照着一张只有三个方框的图写宿主配置，容易漏掉这些实际能力要求。

如果下一步要做真正的 HTTP 演示，我会先固定这几个版本，再把验证拆成可观察的请求行为。未带凭据的请求应在鉴权环节得到 401，带凭据的请求应进入业务处理，日志里应能区分进入、拒绝与完成，响应体流中途失败时还要能看到错误怎样传回。只有这几种行为都跑通，才能说服务链按预期工作。眼下我只完成了 WIT 的解析和校验，所以下面的运行步骤刻意停在接口层。

还有一个设计上的疑问值得留给实现阶段。鉴权位于日志之前，拒绝的请求会不会留下足够的审计记录？若把日志放在鉴权之前，原始凭据又该怎样遮蔽？WASI 0.3 解决的是组件间可表达、可组合的异步接口，这类策略仍由应用决定。我的取舍是先用 WIT 把接口和导入导出校验清楚，再用选定的语言、宿主和组合工具做一次端到端验证。到那一步，才适合写“服务链已运行”，更适合谈吞吐和延迟。

参考资料

1. Bytecode Alliance，WASI 0.3 Launched，https://bytecodealliance.org/articles/WASI-0.3

2. WebAssembly/WASI，WASI 0.3.0 release notes，https://github.com/WebAssembly/WASI/releases/tag/v0.3.0

3. WebAssembly/WASI，wasi:http@0.3.0 的 worlds.wit，https://github.com/WebAssembly/WASI/blob/v0.3.0/proposals/http/wit/worlds.wit

4. Bytecode Alliance，wasm-tools v1.263.0，https://github.com/bytecodealliance/wasm-tools/releases/tag/v1.263.0

5. Bytecode Alliance，wac 项目说明，https://github.com/bytecodealliance/wac