1、前言
在日常开发过程中，大家经常都会遇到：新需求来了，但是需要跟第三方接口来对接，第三方服务还没好，我们自己的功能设计如何继续呢？这里，给大家推荐一下Mock方案。
2、场景示例
2.1、场景一：公司外部间的接口调用
我们都知道，联调外部接口，往往都需要申请测试环境，而申请外部测试环境的时间往往都很长、会耗费很多精力。当然，一般都是项目经理去协调的，但是作为有担当的开发人员，不可能在这个空窗期摸鱼划水吧。不然，等环境下来之后，可就是自己苦日子的开始，毕竟，不催工期的项目经理还是少见的。
2.2、场景二：公司内部之间的接口调用
曾经有一个项目需要我们配合另一个部门一起做。需求宣讲完后就是定排期，然后我们就问合作部门：“这几个接口什么时候可以联调？”
因为合作部门还在赶另外一个项目，便回复道：“我们先一起对接口，等忙完手头这个项目，再给出排期可以吗？”
然后我们催促道：“那也得给出一个具体的上线计划啊？”
在我们的催促下，合作部门终于给出了一个日期。
过了几天，合作部门手头的项目出现了延期，又跑过来跟我们说：“我们可能晚几天才能提供那些接口。”
因为需要与对方交互的接口的功能迟迟未动，我们也不敢释放人手，担心人手释放后，项目又立马启动，开发人员好不容易熟悉了新项目又要回来做这个。
为此，我们坐在一起商量了一个解决思路：
3、解决思路
我们希望有一个 Mock 接口服务，它能提供与正式服务的 URI、出入参一样的接口，区别是主机名或者 URL 的前缀不一样。
在开发和测试过程中，我们都连接上 Mock 服务。等到接口或环境搭建好后，我们无须修改代码，通过一个简单的配置切换即可让服务连接到真实接口服务，然后通过一些简单的回归测试即可实现上线，大大提升了开发效率，此时整体的系统架构如下图所示：
不过，如果我们想实现这一思路，可就一点不简单了，因为他包含了Mock服务端和Mock服务客户端调用设计。
4、Mock服务端设计
先说下在Mock服务端设计过程中，都需要满足哪些需求？
4.1、Mock接口支持返回动态字段数据
比如有个接口输入的参数为userId、orderid、redirectUrl，如下所示：
输出参数为success和startTime，如下所示：
我们希望每次调用这个Mock接口时，startTime都返回当前时间，如：
{
success:true,
startTime:2023-11-12 12：45：02
}
4.2、Mock接口支持一些简单逻辑
在测试过程中，我们会通过不同的测试用例走完不同的流程。
紧接着上面的例子，比如我们希望调用 Mock 接口传入的 UserID 是 10001，那么 Mock 接口返回的 success 值为 True，否则为 False，而后系统会根据不同的 success 值进入不同的流程。
4.3、Mock接口支持回调
在实际开发工作中，有很多联调接口需要异步回调，比如上面的例子中，如果返回的 success 值是 True，我们希望过一段时间回调 Redirect URL。
4.4、Mock接口支持规则校验
我们希望通过添加一些规则让这个 Mock 服务对传入的参数进行校验，比如校验 UserID 是否为数字、OrderID 是否为 15 位数字、Redirect URL 是否为 URL……
4.5、Mock接口支持接口文档导入
这一点比较特别，比如某些团队在设计接口文档时，直接将接口定义放在 Wiki 上；而某些团队直接写在 Java 代码中，再通过 Swagger 生成在线接口文档。
对于前者，我们要求定义接口时，直接将接口文档放在新的 Mock 服务上。而对于后者，因为不想改变他们的习惯，所以最终 Mock 服务需要支持 Swagger 文档导入。
根据以上五点需求，我们开始在市面上找一些合适的开源框架，并发现市面上收费的接口文档管理工具有 Apizza、Eolinker，免费的有 YAPI 和 RAP2，出于各种原因的考虑，最终我们决定在 YAPI 和 RAP2 中进行选择。
这里我们可以看一下YAPI和RAP2对比：
通过表中的内容对比，很明显YAPI更符合我们的需求。因此，在Mock服务端设计过程中，我们选择基于YAPI进行二次开发。
5、Mock服务客户端调用设计
说完Mock服务端，接下来我们看看调用Mock服务客户端时，都需要考虑什么？
5.1、Mock服务如何支持基于二进制流的接口调用？
因为历史原因，有些服务间调用使用 Spring Cloud Feign ，而有些服务间调用使用基于二进制流序列化的 RPC（当然是基于 TOP 协议）。
我们知道，如果服务间的通讯是基于二进制流而不是 JSON，就没办法在 YAPI 上通过简单的界面定义输入输出参数了，且 YAPI 也不支持二进制流的调用，此时我们的解决方案如下图所示：
在上面框架中，我们添加了一个拦截器，它会拦截所有服务间调用的请求，并增加一个判断。如果访问的地址是 Mock 服务，我们就使用 HTTP 协议，并且通过 JSON 进行序列化和反序列，这样问题就解决了。
这里，我们需要补充一点：曾经，我还碰到过一些第三方接口使用 XML 格式（很多银行的接口就是这样），最终我们决定先不支持自定义XML格式的接口，因为改造 YAPI 的工作量实在太大。
5.2、Mock服务客户端如何简单切换Mock与真实服务？
这里，我们需要考虑以下两种情况：
- 对于第三方接口，我们只需在配置中将第三方接口的 host 改为 Mock 服务的 host 即可。
- 对于微服务间的调用，我们知道 Spring Cloud 中的微服务定义都是服务级别，但是在实际开发的场景中，我们需要使用接口级别的 Mock，比如我们开发的 operationService，它依赖 productService 的几个接口。因此，在新项目中，我们还需要在 productService 中新增几个接口，且它们必须调用 Mock 服务的接口，而原先的接口继续调用真实的 productService 中原来已经做好的接口。此时，我们需要在配置中心增加 2 个配置项：mock.apis 和 mock.host，每次服务间调用时，先判断调用的 URI 是否在 mock.apis 字符串列表中，如果在，则让它调用 mock.host 这台机器。特别说明一点：关于这点，曾经我们也出过错。因为在上线时配错了 mock.apis 和 mock.host，导致线上环境使用了 Mock 服务的情况，所以我们需要多考虑下面这点。
5.3、如何预防线上环境使用Mock服务？
对于此问题，我们做了一个检查代码：在服务启动时，先判断当前的环境名称，如果是 prod（线上环境），先判断 mock.apis 中是否有值，有值的话提示异常。然后扫描所有的 properties 配置，如果配置中包含 Mock 服务地址，则说明有些地方配置了 Mock 服务的调用，也提示异常。
到这里，整体的 Mock 调用方案就完成了。
