WebAssembly组件模型在服务边界选择中的判断表

团队讨论“要不要把能力拆成WebAssembly组件”时，最容易混淆的是两个不同问题：组件模型解决的是跨语言组合和受控宿主能力，网络服务解决的是独立部署、流量治理和故障隔离。判断边界时，先看调用是否需要跨进程，再看依赖是否能被明确写成导入接口。

官方资料入口：https://component-model.bytecodealliance.org/

先用四个问题判断边界

第一问是调用路径：如果调用必须跨节点、经过网关或需要独立限流，网络服务更合适；如果能力在同一宿主内高频调用，组件可以减少序列化和网络往返。第二问是发布节奏：组件仍可能随宿主一起发布，不能自动获得服务级的独立回滚。第三问是权限：组件只能使用宿主显式提供的导入能力，但宿主仍要认真设计文件、网络、时钟和密钥接口。第四问是运行时：目标语言、绑定生成器和宿主都要支持同一个world，不能只因为“都能编译成Wasm”就认为可以互调。

用WIT把可用能力和依赖写成契约

WIT不是业务实现语言，而是接口定义语言。接口适合表达一组聚焦能力，world则把多个接口组织成组件对外提供的功能和运行所需依赖。下面的示例只保留支付能力的边界，故意把日志作为导入依赖，便于检查权限是否被显式声明。

package example:billing@0.1.0;

// 中文注释：接口只描述输入、输出和可观察的错误，不放实现细节。
interface charge {
  record request {
    account-id: string,
    cents: u64,
  }

  variant charge-error {
    invalid-account,
    declined,
    unavailable,
  }

  charge: func(input: request) -> result;
}

// 中文注释：world明确组件导出的支付能力，以及宿主必须提供的日志能力。
world payment-boundary {
  export charge;
  import wasi:logging/logging;
}

这里的关键不是字段长短，而是方向清楚：外部只能调用charge导出的能力，组件只能调用已经导入的日志接口。若实现还需要访问数据库、密钥或外部网络，就应该继续把这些依赖拆成可审计的接口，而不是在宿主里悄悄放开一组“大而全”的能力。

服务边界与组件边界怎么选

可以把候选能力放进下面的判断表。表格不是绝对规则，但能让架构讨论从“Wasm很快”转成可验证的工程条件。

一个常见折中是“服务承载生命周期，组件承载局部能力”：例如订单服务负责鉴权、事务和外部依赖，把规则计算、格式转换或租户策略作为组件加载。这样既保留服务的发布与治理能力，也让高频、跨语言的局部逻辑拥有清晰的权限边界。

按证据排查“能运行但不该采用”的方案

第一层看组合证据：组件的导入是否都能由宿主或其他组件满足，WIT类型是否在生成绑定后仍保持一致。第二层看权限证据：删除文件、网络或密钥导入后，组件是否会明确失败，而不是依赖隐藏的宿主全权限。第三层看错误证据：把declined、unavailable等业务结果与宿主崩溃、资源耗尽区分开，调用方才知道能否重试。第四层看发布证据：升级接口版本后，旧组件能否继续组合，失败时是否能回滚到上一个宿主和组件组合。

如果团队需要每个能力独立扩容、独立告警、跨节点容灾，组件通过编译只是局部成功，边界仍应放在服务层。反过来，如果网络调用只是为了隔离一个纯计算策略，且部署、权限和失败策略都能由宿主承担，组件边界往往更简单。

试点前的落地清单

• 为每个world写清版本、导入、导出、资源所有权和错误集合。
• 选一个窄能力做组合试点，记录冷启动、调用开销和内存上限，但不把单次基准当成生产结论。
• 在宿主侧逐项声明文件、网络、时钟、日志和密钥权限，拒绝默认全权限。
• 准备组件缺依赖、业务拒绝、运行时崩溃和版本不兼容四类故障演练。
• 把升级、回滚、审计、告警和容量责任写进部署清单，确认它们没有被“组件化”这个词掩盖。

相关问题

WebAssembly组件是不是天然等于微服务？

不是。组件主要描述可组合的二进制与接口边界，微服务还包含网络、部署、治理和运维责任。

WIT能不能替代API网关契约？

不能。WIT适合组件间的类型和导入导出约束，鉴权、限流、路由和跨节点观测仍需要服务侧机制。

什么时候不值得引入组件模型？

当能力只在单一语言内调用、没有隔离要求、且独立发布和扩缩容更重要时，普通库或网络服务通常更省成本。