查看原文
其他

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

Chris Xia 携程技术 2022-06-07

作者简介

 

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


前言



本文描述的是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机票业务的快速发展保驾护航。

【推荐阅读】



 “携程技术”公众号

  分享,交流,成长



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存