在微服务和前后端分离的项目里，联调环境永远是最容易出问题的一环。下游服务还没开发完，第三方接口限流限到怀疑人生，测试环境的数据永远凑不齐一单完整的业务流程。Stub 服务正是为了解决这类问题而生：它用一个假的实现顶替真实依赖，让开发与测试不被外部系统阻塞。而容器化 Stub 服务管理，则是把这些假实现统一放进容器里，用镜像和编排工具进行生命周期治理，使其成为团队共享的基础设施。本文将从概念、架构设计到具体落地，完整讲清楚这套方案的实现思路。
一、先厘清 Stub 与 Mock 的边界
很多团队在口头交流中把 Stub 和 Mock 混用，但在工程实践里二者关注点并不相同。Stub（桩）是一种状态验证工具：它只负责在收到请求时返回预设的响应，不关心调用方与它之间发生了多少交互细节。比如支付网关的 Stub，无论收到什么下单请求，都固定返回一个成功应答，让上游链路可以继续跑通。
Mock 则偏重行为验证：测试结束后需要断言"某个方法是否被调用、调用了几次、参数是什么"。Mock 通常运行在进程内（如 Mockito、unittest.mock），生命周期与测试用例绑定；而 Stub 更像一个独立部署的服务，可以被多个团队、多个环境共用。理解这个差异很重要，因为它决定了架构选择：进程内 Mock 适合单元测试，独立部署的 Stub 服务适合联调、契约测试和端到端测试。
一旦 Stub 需要独立部署、被多方共享，管理问题就来了：谁负责维护、配置怎么分发、实例怎么回收、不同版本怎么共存。传统做法是在某台测试机上手工启动一个 WireMock 进程，时间一长就变成"谁也不敢重启的祖传服务"。容器化正是解决这一痛点的钥匙。
二、容器化管理带来了什么价值
第一是环境一致性。Stub 的行为完全由配置文件决定，把配置打进镜像或通过挂载卷注入，就能保证本地开发、测试集群、CI 流水线里跑的是同一套规则，避免"本地好的、测试环境不行"这类经典扯皮场景。镜像本身自带版本号，回滚只是改一个 tag 的事。
第二是生命周期可编排。借助 Docker Compose 或 Kubernetes，Stub 实例可以按需启动、用完即毁。契约测试需要验证 20 种异常响应？在流水线里临时拉起一个只包含异常分支的 Stub 容器，测试结束自动销毁，互不干扰。这比常驻的共享实例干净得多，也不会出现一个团队改了配置影响另一个团队的尴尬。
第三是资源隔离与可观测性。每个 Stub 容器有独立的 CPU、内存限额，有独立的日志和健康检查端点。当联调出现诡异问题时，可以快速判断是业务代码的问题还是 Stub 响应不符合预期，排查路径清晰。下面是一个最简的 Docker Compose 示例：
version: "3.8"
services:
pay-stub:
image: wiremock/wiremock:3.5.4
container_name: pay-stub
ports:
- "9091:8080"
volumes:
- ./stubs/pay:/home/wiremock/mappings
healthcheck:
test: ["CMD", "wget", "-q", "--spider", "http://localhost:8080/__admin/health"]
interval: 10s
timeout: 3s
retries: 5
deploy:
resources:
limits:
cplicas: 0.5
memory: 256M这个配置里，mappings 目录挂载了支付服务的桩定义，健康检查指向 WireMock 的管理端点，资源限制保证单个 Stub 不会拖垮宿主机。团队只需要维护 Git 仓库里的 mappings 文件，Compose 负责其余一切。
三、Stub 定义的工程化管理
容器解决了运行时问题，而 Stub 的"内容"——也就是请求匹配规则和响应模板——同样需要工程化。推荐的做法是一个依赖服务一个目录，目录内按场景拆分文件，全部纳入版本控制。例如 stubs/pay/success.json、stubs/pay/timeout.json，文件名即语义，review 时一目了然。
WireMock 的 mapping 文件结构清晰，支持请求匹配、优先级和延迟注入。下面模拟一个支付接口在峰值时返回限流的场景：
{
"name": "pay-rate-limit",
"priority": 10,
"request": {
"method": "POST",
"urlPathPattern": "/api/pay/order"
},
"response": {
"status": 429,
"jsonBody": {
"code": "RATE_LIMITED",
"message": "请求过于频繁，请稍后重试"
},
"fixedDelayMilliseconds": 200
}
}除了静态映射，还应善用场景（Scenario）与模板能力。Scenario 可以让同一个接口按调用顺序返回不同结果，模拟"第一次扣款失败、重试后成功"这类有状态的链路；模板（基于 Handlebars）则可以回显请求参数，让返回数据与入参关联起来，逼近真实服务的行为。需要强调的是，模板中不要硬编码敏感信息，密钥和账号统一走环境变量注入。
对于动态性要求更高的场景，可以不用 WireMock，而是自己写一个轻量 HTTP 服务作为 Stub。用 Go 写一个几十行的 handler，配合多阶段构建打成十几兆的镜像，启动毫秒级，冷启动成本几乎可以忽略。自研 Stub 的自由度最高，但维护成本也最高，建议只在前端交互复杂、需要主动推送消息（如 WebSocket）时才走这条路。
四、与 CI 流水线和团队协作的集成
单机跑通只是第一步，真正的价值在于接入 CI。典型流水线是：构建阶段校验 mapping 文件的 JSON 合法性并做 lint；测试阶段通过 docker compose up -d 拉起整套 Stub，运行契约测试和集成测试；收尾阶段执行 docker compose down -v 彻底清理。由于实例是临时的，测试之间不会相互污染，失败重跑的结果也更可信。
团队协作层面，建议把 Stub 仓库定位为"契约的可执行形态"。下游服务对外承诺什么接口、什么行为，就体现在对应的 mapping 文件里。当接口需要变更时，先修改 Stub 并提交 PR，上游团队基于新版 Stub 完成适配后再上线真实服务，形成类似消费者驱动契约测试的协作节奏。这样 Stub 不再是测试人员的私人工具，而成为跨团队沟通接口契约的公共语言。
最后是治理细节：为长期运行的共享 Stub 集群配置资源配额与日志采集；对临时实例设置 TTL 自动回收，防止 CI 异常中断留下僵尸容器；用 WireMock 的 __admin/mappings 管理接口暴露当前生效的规则，方便排查"这个响应到底是谁配的"。把这些细节做扎实，容器化的 Stub 服务才能真正从"能用"变成"好用"，成为团队研发流程中稳定可靠的一环。