研发提效利器：聊聊 mock 服务化

前两天公众号后台有同学留言问了这样一个问题：

接口测试时依赖调用外部第三方平台，三方平台不稳定经常报错，该如何解决这个问题？

看到这个问题我的第一反应是通过 mock 的方式来解决。但仔细想了下，这位同学的疑惑其实不是如何解决具体的问题，而是类似的问题有没有很好的分析思路和解决方案。

其实 mock 除了可以解决上述的问题，它适用于研发过程各阶段，比如：服务联调、性能测试、自动化测试、流量染色和录制回放等场景。这篇文章，我想聊聊我对于 mock 的理解，它的特点、应用场景以及价值。

Mock 是什么？

其实 mock 还有个称呼，叫做“挡板”。即在某个流程环节起到阻拦、保护的作用。

我们日常的软件研发工作中，整个过程还是比较长的。从需求到线上发布，要经过多个角色多个流程协同配合才能完成。如果按照瀑布模型按部就班的迭代，每个环节经过足够的设计、开发、验证再交付到下个环节，那 mock 的价值其实不大。但随着业务迭代的不断加快，软件系统架构也越来越复杂，多任务并行的状况越来越多。这个时候为了防止某个中间环节阻塞导致后续任务无法开展，就需要一种方法或者工具，来保证任务的正常开展。

简单理解，mock 就是一种降低阻塞风险的方法。

Mock 能解决什么问题

举几个常见的工作案例，就能明白 mock 的作用和应用场景了。

• 自动化测试，依赖第三方的支付或者物流系统，但第三方没办法提供稳定的环境；

• 微服务架构，开发经常服务联调，但可能其中某个服务还没开发完，但又是强依赖；

• 全链路压测，线上支付业务总不能真金白银的测试支付吧，需要一种手段来保障可测性；

如上几种场景只是日常工作中比较常见的，但其实 mock 应用的场景是很多的。

原则上只要是类似遇到阻塞但又要保证任务进度的事情，都可以采用类似的思路或者方法来进行。

我的理解，mock 不仅仅是一种技术手段或工具，而是一种解决问题的思考方式。逆向思考，如果我们在工作开展前能尽可能的考虑到风险并做好冗余措施，就可以更好的提高效率和保障交付质量。

Mock 工具选型和推荐

目前市场上商用的、免费开源的 mock 工具其实挺多的，随便搜搜就有很多。

但在实际应用中，技术选型还是要考虑到工具的适配性、落地难度和后期维护成本，以及学习成本。

我个人认为，一个好的 mock 工具 &框架应该满足如下几个特点：

1. 支持多语言多协议（适应不同的技术栈）；

2. 强大的自定义语法，可以灵活配置规则和返回数据；

3. 较好的断言和校验能力，支持条件触发和规则匹配；

4. 开箱即用，较低的学习落地成本以及较低的维护成本；

5. 完善的官方文档和活跃的社区，避免后期无人维护和更新；

6. 一定的数据导入导出和接口/配置管理功能，便于集成到技术体系中；

综合上述几个特点，我个人比较推荐这两个工具：Apifox（商业）和 Mockito（开源）。

当然，具体选型和使用，还是需要结合实际的情况来判断。

Mock 服务化的价值体现

近几年很流行这样一句话：XXX 即服务。

以前的 IaaS、PaaS、SaaS，近几年的 BaaS(后端即服务)、FaaS(函数即服务)、NaaS(网络即服务)，其中都有 aaS。这里的 aas 就是 As-a-Service，xxx 即为服务的意思。

不是无脑跟风，我个人觉得 Mock 即服务，或者说 Mock 服务化，在架构越发复杂和迭代越来越快的情况下，可以很好的体现其价值。

一方面，将 Mock 服务化，其他调用方或者使用方只需要简单便捷的操作即可快速解决问题，提升研发效率和任务进度，降低风险；另一方面，Mock 服务化本身也更适合当下的软件研发现状，避免内部重复实现和造轮子。