Mock回放：CI依赖治理的终极方案？

其实很多团队在CI里遇到的一个大问题，就是「外部依赖太不可控」。你跑个回归测试，动不动就因为第三方接口超时挂掉。更气人的是——有时本地跑得好好的，一到CI就报错。

我就是在这种反复折腾中，开始认真研究Mock回放的。

说白了，Mock回放就是把真实服务的一次请求/响应录下来，然后在CI环境里直接播放。用录好的数据替代真实依赖。这样你的测试就不再依赖外部系统的可用性了。

CI中那些让我头疼的痛点

先数数我在项目中踩过的坑吧。我做过一个支付流程的CI，每次构建都得调用支付宝的沙箱环境。结果呢？

• 不稳定：沙箱偶尔维护，CI直接挂掉。我曾经半夜被报警吵醒，结果只是沙箱挂了10分钟。
• 数据污染：多个开发并行跑CI，共用一套测试数据，订单状态互相覆盖。有一次我调试了一上午，最后发现是别人删了我创建的测试商户。
• 速度慢：一个接口调用加上网络延迟、限流排队，CI跑了40分钟。全组人等着发版。
• 环境依赖：要连数据库、要连消息队列、要连第三方。搭建一套完整测试环境，运维小半个月。

你想想看，这些痛点最终导致什么？CI形同虚设。大家开始“跳过CI”、“本地跑过就行”。那自动化测试的价值就全没了。

为什么Mock回放能解决？

Mock回放的核心思路其实很简单：把复杂依赖变成文件。你第一次运行测试时，系统自动录制所有对外调用（HTTP、gRPC、数据库查询等），把请求和响应存入一个「回放包」。后续CI执行时，直接回放这些包里的响应。

我记得有一个项目，核心交易链路依赖7个下游。原来CI跑一遍要18分钟，其中14分钟在等外部响应。我们换成Mock回放后，整个CI缩短到4分钟。那感觉真爽。

核心流程：录制 → 存储 → 回放

整个流程就三步。但每一步都有坑，我慢慢跟你讲。

1. 录制：在真实环境或集成测试环境里，捕获所有对外请求。我个人习惯用代理模式的工具，比如WireMock、Mountebank或商业方案VCR。录制时要注意：只录确定性请求（没有随机数的），否则回放匹配不上。
2. 存储：把录制数据保存为结构化文件（JSON、YAML）。建议按用例分组，方便后续维护。我曾经试过把所有数据塞一个文件……后来找一条记录找了半小时。
3. 回放：CI启动时加载这些文件，替换真实的远程调用。匹配规则很重要：通常按URL、方法、请求体做精确匹配。匹配失败怎么办？一般有两种策略：降级到真实调用，或报一个明确的“回放失败”异常。

什么场景最适合用Mock回放？

不是所有测试都适合。我建议按这张表快速判断：

场景	推荐度	理由
第三方API集成	★★★★★	最典型的痛点，回放几乎完美替代
内部微服务依赖	★★★★☆	如果版本发布节奏不同步，回放可以解耦
数据库查询	★★★☆☆	需要处理事务隔离级别，回放只能模拟单次查询
含随机/时间敏感的接口	★★☆☆☆	需要额外做模板化替换，否则回放匹配困难
长连接/流式通信	★☆☆☆☆	回放通常只支持请求-响应模式，流式需要特殊方案

嗯，这里有个技巧：你可以在CI里设置一个“回放模式开关”。日常开发用回放跑快速验证；提MR或发版前，再切回真调用做全量回归。这样两全其美。

一张图看懂Mock回放在CI中的位置

实施Mock回放的前提条件

不是随便一个项目都能直接用。我总结了几个前置要求：

• 测试用例必须幂等：同一个请求发送多次，录制数据要保持一致。如果每次返回不一样（比如“订单已创建”->“订单已取消”），那回放就废了。
• 通信协议要支持拦截：常用的HTTP、gRPC、Thrift都可以。但如果是自定义TCP协议，你得自己写拦截器——我建议别找这麻烦。
• CI基础设施要存录制文件：最好用Git LFS或对象存储（S3、OSS）。不要塞在Git仓库里，否则克隆速度爆炸。

常见误区梳理

最后聊几个容易踩的坑，看看你有没有中招。

1. 忽略动态字段：请求里的timestamp、nonce、sessionId如果不做模板替换，回放匹配失败会fallback到真实调用。我建议在录制时就声明忽略字段列表。
2. 回放数据不更新：外部接口升级了，你还用老数据在跑。结果是测试全绿，上线全挂。一定要设一个“录制数据有效期”，比如7天自动重新录制。
3. 没有fallback策略：匹配失败时直接抛异常，结果整个CI阻塞。我习惯的做法是：先尝试回放，失败后记录一条告警，然后降级到真实调用。这样至少不阻塞别人。

其实Mock回放不是银弹。它适用于依赖外部系统时，为了速度、稳定性和可控性做出的权衡。但它也有维护成本（录制数据老化、匹配规则配置）。关键在于：你愿意用多少维护成本，换取CI的稳定和速度。我个人觉得，对大部分互联网团队来说，这个交易很划算。