研发提效利器：聊聊mock服务化
前两天公众号后台有同学留言问了这样一个问题：
接口测试时依赖调用外部第三方平台，三方平台不稳定经常报错，该如何解决这个问题？
看到这个问题我的第一反应是通过mock的方式来解决。但仔细想了下，这位同学的疑惑其实不是如何解决具体的问题，而是类似的问题有没有很好的分析思路和解决方案。
其实mock除了可以解决上述的问题，它适用于研发过程各阶段，比如：服务联调、性能测试、自动化测试、流量染色和录制回放等场景。
这篇文章，我想聊聊我对于mock的理解，它的特点、应用场景以及价值。
Mock是什么？
其实mock还有个称呼，叫做“挡板”。即在某个流程环节起到阻拦、保护的作用。
我们日常的软件研发工作中，整个过程还是比较长的。从需求到线上发布，要经过多个角色多个流程协同配合才能完成。
如果按照瀑布模型按部就班的迭代，每个环节经过足够的设计、开发、验证再交付到下个环节，那mock的价值其实不大。
但随着业务迭代的不断加快，软件系统架构也越来越复杂，多任务并行的状况越来越多。
这个时候为了防止某个中间环节阻塞导致后续任务无法开展，就需要一种方法或者工具，来保证任务的正常开展。
简单理解，mock就是一种降低阻塞风险的方法。
Mock能解决什么问题
举几个常见的工作案例，就能明白mock的作用和应用场景了。
- 自动化测试，依赖第三方的支付或者物流系统，但第三方没办法提供稳定的环境；
- 微服务架构，开发经常服务联调，但可能其中某个服务还没开发完，但又是强依赖；
- 全链路压测，线上支付业务总不能真金白银的测试支付吧，需要一种手段来保障可测性；
如上几种场景只是日常工作中比较常见的，但其实mock应用的场景是很多的。
原则上只要是类似遇到阻塞但又要保证任务进度的事情，都可以采用类似的思路或者方法来进行。
我的理解，mock不仅仅是一种技术手段或工具，而是一种解决问题的思考方式。
逆向思考，如果我们在工作开展前能尽可能的考虑到风险并做好冗余措施，就可以更好的提高效率和保障交付质量。
Mock工具选型和推荐
目前市场上商用的、免费开源的mock工具其实挺多的，随便搜搜就有很多。
但在实际应用中，技术选型还是要考虑到工具的适配性、落地难度和后期维护成本，以及学习成本。
我个人认为，一个好的mock工具&框架应该满足如下几个特点：
- 支持多语言多协议（适应不同的技术栈）；
- 强大的自定义语法，可以灵活配置规则和返回数据；
- 较好的断言和校验能力，支持条件触发和规则匹配；
- 开箱即用，较低的学习落地成本以及较低的维护成本；
- 完善的官方文档和活跃的社区，避免后期无人维护和更新；
- 一定的数据导入导出和接口/配置管理功能，便于集成到技术体系中；
综合上述几个特点，我个人比较推荐这两个工具：Apifox（商业）和 Mockito（开源）。
当然，具体选型和使用，还是需要结合实际的情况来判断。
Mock服务化的价值体现
近几年很流行这样一句话：XXX即服务。
以前的IaaS、PaaS、SaaS，近几年的BaaS(后端即服务)、FaaS(函数即服务)、NaaS(网络即服务)，其中都有aaS。
这里的aas就是 As-a-Service，xxx即为服务的意思。
不是无脑跟风，我个人觉得Mock即服务，或者说Mock服务化，在架构越发复杂和迭代越来越快的情况下，可以很好的体现其价值。
一方面，将Mock服务化，其他调用方或者使用方只需要简单便捷的操作即可快速解决问题，提升研发效率和任务进度，降低风险；
另一方面，Mock服务化本身也更适合当下的软件研发现状，避免内部重复实现和造轮子。
