WebAssembly Component Model 适合拆分哪些服务边界

WebAssembly Component Model 更适合拆分“契约窄、输入输出清楚、状态少、权限可列举”的能力，而不是把现有微服务逐个换成另一种打包格式。规则计算、格式解析、数据转换和租户插件通常是好候选；强依赖共享事务、共享内存、GPU 或高频往返的核心服务，往往应该先保持为普通模块或独立服务。

先把 Component Model 看成契约，而不是服务进程

Core WebAssembly module 主要暴露低层函数；Component Model 在其上增加 WIT 接口、world 和 Canonical ABI。interface 适合描述一组单一职责的类型与函数，world 则把组件提供的 exports 和运行所需的 imports 收拢成完整契约。组件可以在宿主中组合，也可以与其他组件拼接，因此“拆分一个组件”不一定意味着新增一个 HTTP 服务或容器。

判断边界时，先问三个问题：调用方能否用一组稳定的值调用它？它需要的外部能力能否列成少量 imports？调用结果是否可以通过返回值或明确的错误完成，而不是依赖调用方直接读取内部状态？三个答案越明确，越接近合适的组件边界。

需要继续查规范时，可复制官方资料地址：https://component-model.bytecodealliance.org/design/wit.html、https://component-model.bytecodealliance.org/design/worlds.html。

规则、解析和插件是最容易收敛的三类边界

第一类是纯计算或规则判断，例如价格、路由、格式校验和策略匹配。输入是一组记录，输出是结果或错误，不需要直接打开文件、访问数据库，组件的权限和测试范围都比较清楚。

第二类是解析与转换，例如把文档片段转换为规范化记录、把一种消息格式转成另一种格式。它们的价值在于跨语言复用：宿主不必关心实现语言，只需围绕 WIT 维护数据类型和错误语义。第三类是租户或团队插件，例如为不同客户提供独立的字段规则。将插件的能力限制在明确的 imports 内，比把宿主的全部 SDK 暴露出去更容易审查。

这里的“适合”是工程判断，不是 Component Model 的强制分类。数据量、调用频率和宿主运行时支持情况仍要用小型原型验证。

用 imports 和 exports 写出最小第一版接口

不要从“要拆成几个服务”开始，而应从一次调用的最小数据开始。下面的 WIT 只表达报价能力和一个可选的策略依赖；注释解释每个边界，示例本身不代表已经在本机执行。

package demo:commerce;

interface pricing {
    // 输入只携带计算报价所需的业务字段，避免泄露宿主对象。
    record quote-input {
        sku: string,
        quantity: u32,
        region: string,
    }

    // 结果明确区分成功和业务错误，调用方不必读取内部状态。
    record quote-output {
        amount: u64,
        currency: string,
    }

    quote: func(input: quote-input) -> result;
}

interface policy {
    // 只有确实需要的外部能力才放进 imports。
    allow: func(sku: string, region: string) -> bool;
}

world pricing-component {
    // 组件对外提供报价接口。
    export pricing;
    // 宿主或另一个组件提供策略接口。
    import policy;
}

评审这份接口时，重点不是字段数量越少越好，而是每个字段是否有稳定语义：货币单位、数量上限、错误分类、字符串编码和兼容策略都应写入接口文档。若组件为了完成一次报价还要隐式读取宿主环境变量或共享缓存，应该把它显式建模成 import，或者重新考虑边界。

这几种服务不要急着改成组件

订单聚合、库存扣减这类强依赖共享数据库事务的边界，若每个调用都要往返多个外部资源，组件契约并不会自动消除分布式一致性问题。高频聊天式调用也要谨慎：显式序列化、跨边界拷贝和宿主调度会让原本靠共享内存完成的细粒度协作变复杂。

同样，强依赖特定操作系统句柄、GPU 驱动或大型原生库的能力，不应只因为“能编译成 Wasm”就直接组件化。先检查运行时是否提供所需接口，以及失败时能否回退。一个实用的落地清单是：

1. 把一次调用画成输入、输出、错误和副作用四列。
2. 把所有外部能力逐项映射为 WIT import，禁止隐藏依赖。
3. 估算数据复制、调用频率和资源限制，做一条真实链路原型。
4. 为接口版本、兼容字段和组件失败准备回退路径。

常见问题

WebAssembly Component Model 能直接替代微服务吗？

不能直接画等号。它解决的是类型化接口、跨语言组合和受限外部能力，是否部署成独立网络服务仍由宿主和业务架构决定。

为什么不能让组件直接共享宿主内存？

组件边界的价值之一就是把交互收敛到 imports 和 exports。共享内存会重新引入隐式耦合，也削弱权限、版本和错误边界的可读性。

第一次试点应该选什么？

优先选无状态规则、解析转换或可禁用的租户插件，准备小输入集、错误样例和回退实现；不要从核心订单事务或高频共享状态链路开始。