微服务下混乱的调用关系
一般来说，开发工程师在开发前期就已经定义好了微服务接口，测试工程师和开发工程师几 乎是同步开始进行各自的开发任务。但是，这种和谐的工作场景很快就被蜘蛛网一样的微服 务调用关系给破坏了，几乎所有的项目都会出现相互依赖的关系，比如说服务 A 依赖服务 B，服务 B 依赖服务 C，如下图所示：
这种混乱主要体现在：当持续集成流水线部署服务 A 的时候，由于对应的开发工程师团队也在做同步改造，导致测试环境的服务 B 不可用；
由于服务 B 依赖服务 C，而服务 C 还没有开发完成，导致即使服务 A 和服务 B 都没问题，但也没有办法完成服务 A 的接口测试。
微服务随 着开发越来越复杂，服务之间的调用关系就像蜘蛛网一样错乱，让你摸不清外部依赖到底有 几层，以及一个接口到底依赖了几个外部接口。这就导致了虽然被测系统已经开发完成，测试脚本也准备就绪，但是测试工作就是没办法进 行的悲惨结局。
Mock 框架的抉择：用什么实现服务 B 的替身
针对混乱的调用关系，我的思路是：我的被测服务就是服务 A，那么我不用管服务 B 是不 是好用，我只要保障服务 A 能够走完流程，就可以完成接口测试任务了。循着这个思路， 每做一个 Mock 服务其实就是做了一个简单的服务 B，不同的是，它不需要实现原有服务 B 负载的处理逻辑，只要能按服务 B 的处理逻辑给出对应返回就可以了。 因此，有些团队也会把这样的服务叫做挡板系统。
我的 Mock 服务设计经验
在选择好 Mock 框架后，你就可以酣畅淋漓地完成各个外部依赖服务的解耦工作了，但是 关于 Mock 服务，我还想告诉你一些我的设计经验。
首先，简单是第一要素。无论原服务 B 处理了多么复杂的业务流程，你在设计服务 B 的 Mock 服务时，只要关心服务 B 可以处理几种类型的参数组合，对应的服务都会返回什么 样的参数就可以了。这样你就能快速抓住 Mock 服务 B 的设计核心，也能快速完成 Mock 服务 B 的开发。
其次，处理速度比完美的 Mock 服务更重要。一个 Mock 服务要能按照原服务正确又快速 地返回参数，你不需要把大量的时间都浪费在 Mock 服务的调用上，它只是用来辅助你完 成接口测试的一个手段。
最后，你的 Mock 服务要能轻量化启动，并且容易销毁。你要时刻注意，Mock 服务只是 一个辅助服务，因此，任何一个团队都不希望启动一个 Mock 服务需要等待 5 分钟，或者 需要 100M 的内存。它要能快速启动、容易修改并且方便迁移。
总结
微服务现在已经铺天盖地而来，尤其在中台化战略的推动下，业务中台服务的依赖关系会越 来越复杂，并且随着团队内微服务数量越来越多，每个测试团队面临的被测系统都会是一团 乱麻，很容易找不到头绪。
为了解决由于微服务间相互依赖而导致的混乱的系统调用关系，我建议你尽快掌握一个 Mock 服务框架，这样可以让你在混乱中理清思路，快速进行接口测试，交付高质量的项 目。
最后我要提醒你的是，选择 Mock 的技术栈与选择测试框架的技术栈还是有些区别的，在 选择 Mock 技术栈时，你重点要考虑的是学习成本，把学习成本降到最低，才是选择 Mock 框架的首要关注点。而且你不只要关注自己的学习成本，也要关注你所在团队的学习 成本，因为现在每个项目都有可能需要 Mock 服务，这个时候，就要求每一个项目的测试 工程师都具备自己独立建设 Mock 服务的能力，在 Mock 服务的技术选型上，还是要以团 队整体的技术栈为基础，以自己的技术为参考进行选型。
