干货 | 代理模式 Mock 平台在携程的应用

本文描述的是 2020 年携程 IBU 机票研发团队基于业务痛点所研发的轻量级前端 Mock 解决方案（目前正与集团另一 Mock 中台融合，从中台的赋能中探寻更多拓展）。希望可以借此文为有类似前端 Mock 需求，正在寻找解决方案的团队/个人提供一种思路。

一、背景

在实际开发场景中，有很多前端需求是需要和后端基于契约进行并行开发的。因此不论是开发阶段，如何让开发和测试更简便地覆盖业务场景，提升开发质量，还是在产品验收阶段，如何在出现问题时精确、快速的定位，都是前端开发需要解决的痛点。

因此，拥有一个稳定、灵活、易用的数据 Mock 平台是保证前端开发和排查问题效率的重要前提。

总结前端在开发、调试、验收等各阶段需要 Mock 平台具备的能力后，我们整理出了 Mock 平台需要具备的核心功能：

1）实时请求数据可视化（抓包）；

2）简单易用的 Mock 报文管理，支持设备维度的个性化 Mock；

3）满足设备多接口不同环境的支持（复杂业务下不同接口不同团队开发，发布在不同环境的测试服务器上）;

4）模拟延时，支持前端模拟不同业务场景下的展现；

在明确了主要需求后，我们开始调研公司内已有的和市面上主流的 Mock 工具和平台。

二、调研

公司内：

公司内已有一个功能集成较高的 Mock 效率平台，但是其主要的功能设计为面向服务端和测试，对上述单个设备维度及多测试环境的前端 Mock 需求支持度不够高。

市场调研：

外部市场 Mock 工具大致分为以下三类：

1）数据本地管理

该方法是将 Mock 数据存储在本地-代码或本地存储中，前端在业务代码中使用假数据或通过配置读取数据。这种做法会导致测试代码与业务代码耦合，提交代码和发布前必须删除测试代码或修改配置，容易造成生产事故。即使结合运行环境控制还是存在维护效率低、成本高的问题。

2）Mock 平台：如 Rap\YApi

开源的一些企业级 Mock 平台，提供了接口文档管理，接口数据模拟，接口调试等功能。但这些平台都是围绕接口的契约文档为核心对数据进行 mock 和管理，对于已经接入过接口管理框架（如 Swagger）的组织来说，会存在接口文档同步难的问题。对报文实时回显和多接口不同环境的配置功能支持也不足。

3）代理工具：如 Charles、Fiddler

轻量级的客户端代理工具，能满足日常开发抓包和简单的 Mock 需求。缺点是配置繁琐，对 Mock 数据的管理能力弱，数据和报文也无法共享。

因此我们根据自身痛点开发了 Mars 系统 –基于代理模式的轻量级前端 Mock 平台。较好的解决了上述痛点，支持了业务发展，显著提升了前端开发效率。

三、设计实现

对前端 Mock 平台而言，不论是 PC，H5 还是 App，每个设备的 Mock 需求都会不同。为了解决设备间的差异性，我们将 Mars 定义为基于设备维度的 Mock 平台。

摆在我们面前的有两类实现方案：

方案 A：往公司的服务治理中心注册 Mock 地址，前端需要在现有的基础网络设施上配置 Mock 地址。这种方案侧重对后端环境的模拟，需要强依赖服务治理中心，前端不同设备在 Mock 时需要再针对单个设备进行特定配置，不够灵活。

方案 B：通过代理请求的方式，客户端将所有请求发送到 Mock 平台，平台内部判断是走 Mock 还是走原请求。这种方案对请求的控制更加精细，同时也可以将客户端的配置工作转移到 Mock 平台上，客户端使用起来更加方便灵活。

综合考虑优缺点后，最终选择代理请求的方案 B 来实现 Mars 平台。

Mars 的使命是让设备接入后，从请求发出到接收响应再到 Mars 回显数据，可以清楚的观测到接口信息和 Mock 命中情况，让前端的数据流由原本的黑盒变为白盒，使整个 Mock 流程形成一个闭环。

平台的设计中包括两个部分：

一是 GUI 层，负责数据展示和管理用户操作，主要分为实时报文展示，Mock 数据管理以及环境配置等模块，如下图蓝框部分；

二是数据处理层负责处理设备的请求响应，主要分为设备参数解析，Mock 数据筛选以及请求转发等模块，如下图红框部分。

图 1 Mars 框架图

四、功能实现

4.1 数据实时回显

在日常的开发调试中，经常需要查看页面元素对应的接口数据。我们将已发出的请求实时回显到 Mars 页面上，方便观察接口数据变化。

此功能基于 Websocket 实现。用户在 Mars 上选择设备进入设备详情之后，前端通过 Websocket 与平台建立通信链接，这时后端会保存一个以设备号为 ID 的 Websocket 链接实例，之后，平台将该设备的所有请求通过该实例回显到 Mars 前端页面上。

图 2 Mars 数据实时回显图

4.2 Mock 数据控制

Mars 除了支持接口配置固定 Mock 数据以外，还对其他复杂场景进行了支持，例如同一个接口，根据不同的请求参数返回不同的 Mock 数据，即接口与 Mock 数据之间可以分别实现一对一和一对多的关系。

此功能主要利用了 Json 报文数据格式化的特性。通过在平台上配置 JsonPath 脚本，让 Mars 对收到的代理请求进行解析，返回相匹配的 Mock 数据。

4.3 网络环境切换

这里的网络环境指的是业务接口的测试，堡垒，生产等环境。

当设备需要在指定的网络环境中测试某些功能时，正常情况下前端需要在代码中增加一些配置指向特定的网络环境。在接入 Mars 后，因为使用的代理模式，这些配置工作被转移到平台上，在平台上配置好需要的环境后，在平台上直接切换前端就生效了。

在实际应用过程中，我们还遇到了更复杂的业务场景。如后端有多个接口发布在不同的测试环境上：业务需要的接口 1 被发布到测试环境 A，而其它接口在测试环境 B。

这里，我们通过增加子环境的概念，将子环境与设备绑定，实现以接口为维度的环境控制且设备之间相互隔离。回到这个问题，就是针对测试设备在 Mars 中增加一个子测试环境 A，并将设备的基础环境设置为 B。Mars 会将该设备发出的指定接口 1 转发至子测试环境 A，其他请求转发至测试环境 B。具体如下图所示

图 3 Mars 环境切换流程图

4.4 模拟延时

很容易理解，客户端请求被代理后，相当于是与 Mock 平台建立了连接，在平台上为响应设置延时，模拟真实请求返回时间。这样就可以帮助前端轻松构建网络卡顿、超时等各种情况下的表现了。

在上述核心功能被实现后，Mars 基本满足了我们对 Mock 平台的核心诉求。Mars 发布上线后，通过收集用户需求和反馈，我们基于核心功能对平台进行了拓展，使 Mars 兼容了更多复杂场景下的问题。主要举例以下两点：

Mock 数据集

上文提到的 Mock 数据控制，主要体现在对单个接口的 Mock 数据上，单接口 Mock 数据与设备绑定，主要适用于开发调试阶段对一些零散接口进行 Mock 调试。

而在集成测试阶段，一个业务场景通常涉及多个接口，不同业务场景下对同一个接口要求的返回数据也不同。如测试预订单程和往返下单流程，同样的查询和政策接口要求返回数据完全不一样，这种情况下操作单接口 Mock 数据费力度很高。

所以我们在单接口 Mock 的基础上拓展了 Mock 数据集的概念，将单个场景中多个接口的 Mock 数据打包成一个集合，设备直接使用集合，极大的提升了 Mock 数据管理效率。

后端 Mock 应用

后台服务间的相互调用，调用方实际上也相当于是前端，因此我们将这套代理模式的 Mock 方案也应用到了服务间的调用上，降低了后端对上游服务的依赖。同时，将 Mock 数据集功能与接口自动化测试相结合，为自动化测试平台提供数据支持，使服务端接口自动化测试覆盖率提升至 90%以上。

五、一些问题

基于代理模式的 Mock 方案为实现实时报文显示和子环境切换功能提供了便利，但也引入了一些问题，如：

1）内存占用较大

代理模式下客户端的所有请求响应的数据大小对于 Mock 平台来说都是未知的，当遇到数据量大的接口被频繁调用时，会造成应用内存升高，JVM 触发 Full GC 影响性能。需要在申请 Mock 应用内存时对使用量进行合理评估，保证稳定性。

2）响应时间增长

代理模式相当于多了一层网络调用，接口的响应耗时会有所增加，在需要测试接口极致性能时，需要评估代理方式是否适用。

六、结语

Mars 平台目前已被多个团队使用，产出近 2W 条 Mock 数据，600 多个 Mock 数据集，平均每天代理 130 个左右设备的流量，基本满足了在开发调试过程中 95%的 Mock 需求。与此同时，我们也一直在使用过程中不断验证、优化，并开始与携程内部其他开发效率工具融合，使 Mars 能为 IBU 机票业务的快速发展保驾护航。

作者介绍：

Chris Xia，携程资深前端开发工程师，关注前端技术更新和研发效率提升。

本文转载自：携程技术中心（ID：ctriptech）

原文链接：干货 | 代理模式Mock平台在携程的应用