浅谈Mock平台设计思路

一、Mock概述

友情提示：本节为小白科普章节，大神可绕路直奔下一章节。

1.1 何为mock？

mock即模拟，可以理解为模拟数据。就接口mock而言，就是mock接口返回结果。

根据不同层次的需求，也是存在不同的mock层级，可以参考下面的金字塔模型，越往上mock的级别越“高”，对于用户（测试）越“可见”。方法、类级别一般是开发会用到，例如单测开发。而接口和服务级别是测试进行服务联调测试甚至系统测试过程会用到的。

1.2 为什么需要mock？

这就有必要介绍一下微服务了，微服务架构下，每个服务只完成一块功能，这些服务共同合作来就可以完成某些更加复杂的操作。与单体的复杂系统不同，开发者需要开发和管理一系列相对简单的服务，而这些服务可能以一些复杂的方式交互。这些服务之间的相互协作可以通过异步方式如消息形式，也可以通过同步方式来完成协作的。而这些服务之间可以独立部署与发布。为了让大家更有体感，以散户交易股票的过程为例：

（1）用户创建一个订单，用来出售其账户里某只股票的股份；

（2）账户中的这部分持仓就会被预留下来，这样它就不可以被多次出售了；

（3）提交订单到市场上是要花钱的——账户要缴纳一些费用；

（4）系统需要将这个订单发送给对应的股票交易市场。

可以看到，微服务有三大关键特性。

（1）每个微服务只负责一个功能。这个功能可能是业务相关的功能，也可能是共用的技术功能，比如与第三方系统（如证券交易所）的集成。

（2）每个微服务都拥有自己的数据存储，如果有的话。这能够降低服务之间的耦合度，因为其他服务只能通过这个服务提供的接口来访问它们自己所不拥有的数据。

（3）微服务自己负责编排和协作（控制消息和操作的执行顺序来完成某些有用的功能），既不是由连接微服务的消息机制来完成的，也不是通过另外的软件功能来完成的。

（4）每个微服务都是可以独立部署的。如果做不到这一点，那么到了部署阶段，微服务应用还是一个庞大的单体应用。

（5）每个微服务都是可代替的。每个微服务只具备一项功能，所以这很自然地限制了服务的大小。同样，这也使得每个服务的职责或者角色更加易于理解。

一般来讲，微服务可以根据业务形态划分服务，然后不同的开发负责对应服务的开发与维护。当然一个服务可能不止有一个上游服务调用，甚至存在多个上游调用，而且不同的上游服务存在不同的调用契约。服务之间的调用链路可以参考如下图：

试想如果你是服务A的测试同学A，你的业务需要调用服务C来完成一项业务，即服务A根据服务C的返回结果决定业务的执行结果。那么我是服务B的测试B，也需要调用服务C来完成一项业务，但是我调用服务C和你调用服务C的接口传参不同，返回的结果也可能不同，此外我们依赖的服务C版本号也不同，但是当前环境可能只部署2.0版本，再碰上有时候开发环境不稳定，服务时还是坏，这样服务C就无法同时满足测试A、B同学进行项目测试，而且环境问题也会浪费很多联调时间，导致项目并行难上加难。