哈啰业务数据场景

痛点软硬件一体化应用场景

图片

用户从APP端、支付宝小程序、微信小程序、H5和WEB,经过一些核心服务。核心服务通过HTTP或内部的RPC接口,包含用户增长、配置平台、综合平台、用户增长等,对应的基础平台包括存储平台、用户平台、算法平台、开放平台、大数据、地图平台等。物联网目前主要对接单车、电动车、电池、电柜等。

研发测试阶段遇到的痛点

图片

单车这里,红包车数据测试链路过长,手工构造一次数据需要0.5天以上;不同入参返回不同结果,难以构造模拟返回数据。助力车这里,超区断电依赖地图算法模型,测试线下路上跑来跑去模拟临区超区耗时过长。顺风车这里,对接众多第三方平台,迭代回归第三方接口,各种场景返回难以构造。支付这里,异常场景众多,实名认证信息难以构造。换电这里,不同项目并行开发,对方接口未开发的情况下,开发调试成本过高;无法模拟只支持某个时间段的返回结果。电动车这里,通过单测的方式Mock各种场景代码量巨大;部分场景Mock需要研发配合改造代码,侵入性过高,成本较大。

哈啰HiMock和传统Mock的对比

传统Mock在哈啰全场景先天性不足

图片

传统Mock一是代码改动频繁,只要代码变动,case相关代码都需要改动,整体耗时较长;二是链路简单,只支持简单链路的Mock;三是Mock难度上,数据构造难,非本业务线同学如果没有接口文档,不知道如何快速Mock;四是扩展难度较大,仅支持部分软件协议,不能扩展。而哈啰全场景业务特性一是代码改动难,涉及到多个业务方,研发无法及时配合验证迭代需求改动相关代码;二是链路复杂,需要支持前后多端、涉及硬件协议链路的Mock;三是Mock难度上,并行开发时,多个业务同个接口模拟不同的返回,构造成本较大;四是拓展程度上,需要支持软硬件协议数据模拟。

打破传统Mock的设计思路

图片

我们为了打破传统Mock的设计思路,从以下六点设计HiMock。一是低代码,代码开发量少,可以快速搭建框架;二是代码解耦,不需要用户改动任何代码;三是高性能,不影响原有系统的性能指标;四是应用性,用户可以低成本Mock;五是支持前后置场景,如签名、回调、数据库操作等;六是全场景,支持前后端各种协议。

Mock技术支撑全场景业务域的实践

打破传统互联网的软硬件结合的Mock业务架构

image.png

首先介绍服务链路,C端用户主要来源于哈啰APP、支付宝小程序、微信小程序,通过HTTP网关,再进入各个业务的入口,包括单车、助力车、电动车、换电、顺风车等,接下来我们协议拦截之后,再去匹配对应规则引擎里配置的规则来看是不是命中了对应的Mock,并去检查对应的静默开关、生效时间、生效范围、延时、参数替换、后置条件,这些都是通过规则引擎拿到对应的数据。我们通过Mock返回的规则,一站式并支持多端。

接下来介绍产品能力,一是Mock管理,包括case创建、case列表、我的Mock;二是工具管理,主要是YAPI|Swagger接口导入;三是大盘统计,主要是调用统计的分析,包含每个业务域、调用量以及对应的Mock量、各业务线使用的分析等;四是权限管理,包括用户权限和用户组权限;五是拦截规则引擎,包括高并发支持、静默支持、生效范围和参数替换;六是一体化Mock工作台,可以集成APP、H5、微信小程序和支付宝小程序,自动接口抓包、一键功能,并支持YAPI|Swagger接口导入、接口参数自动获取、匹配规则参数自动生成;七是自动更新,底层代码改动,自动更新最新代码;八是环境稳定性,保证整体研发测试流程不被打断,Mock可被追溯。

HiMock整体流程

图片

我们case的来源分为三部分,包括HiMock、Fox和第三方。左边这部分就是用户请求,分为后端请求和前端请求。后端请求我们通过Agent拦截到对应的协议之后,根据Mock、规则引擎去匹配对应的规则,如果能匹配到,就把对应的Mock结果返回出去。Agent的下载流程也有两部分,一是Atlas部署的时候,会去检查Agent是否存在,如果不存在,会自动下载到对应服务的原容器上或者ECS上面。二是添加或更新case的时候,也会去判断Agent是否存在。前端请求iOS是针对NSURLProtocol协议进行拦截和转发到对应的Mock规则引擎,去判断是否命中;安卓是针对OkHttp协议拦截和转发,其他协议也可以在这里进行兼容适配处理。

HiMock底层Agent设计

图片

HiMock底层Agent设计主要分四方面,一是字节码拦截,我们经过大量的对比分析,最终选型ByteBuddy作为字节码拦截的底层框架,可实现低代码,迭代敏捷迅速开发。二是拦截协议,我们实现插件化模式开发,可快速实现拦截协议的开发与配置,支持多维度协议拦截。三是壳化Agent,对外暴漏一个premain的壳函数,可实现动态代码更新相关功能。四是后置处理,复杂链路信息,需要在Mock 返回之后,执行一些数据库操作、消息发送、地址回调等。

图片

在HiMock底层Agent实现上,我们首先把Agent进行一个premain函数的壳化处理,再对各个协议拦截的Interceptor封装。HTTP协议请求,我们针对CloseableHttpClient、HttpClient、OkHttpClient和RestTemplate等等Class进行拦截。RPC协议,我们有进行RpcHandler Class拦截。针对Mq,我们有Hms进行拦截。同理,其他也是拦截对应的核心请求类,再进行协议的拦截。

HiMock规则引擎设计

图片

HiMock规则引擎设计思路主要分三方面,包括高并发、兼容性和多端。在方案调研上,基于不同协议,拦截规则不尽相同,但是作为拦截收口,统一转为JSON进行参数匹配入参条件。最常用的JsonPath框架有fastJson、jackson、json-path和snack3,经过多轮压测,我们最终选型snack3,支持的选择器表达式更丰富,性能较优。在方案执行上,拦截规则判断时多条件支持,且支持多条件与或组合等。目前支持的条件有equals、not equals、contains、not contains、in等。在方案落地上,拦截规则参数根据入参自动生成,参数预期值智能匹配。

HiMock平台系统架构

image.png

HiMock平台包含WEB、核心功能、数据层、Agent和Mock服务。WEB主要有DashBoard、Mock管理、权限管理、工具管理和平台指南。核心功能主要有云容器自动部署、自动化部署、添加Mock、Mock列表、Mock日志、Mock规则、工具管理、权限管理、数据统计和用户手册。同时我们要适配一些拦截协议,如RPC、HTTP、TCP、MQ、MQTT、DB、ES。

数据层主要分为Mysql、Redis和ES,我们会把数据缓存到Redis里,再定期汇总到Mysql里,并把Redis里的数据进行清空,减轻缓存压力。Mock的服务请求被对应的Agent拦截到协议请求之后,Agent访问Mock服务设置的规则数据,拿到规则数据判断请求是否被匹配到Mock规则。

HiMock落地使用场景

图片

HiMock落地使用场景有依赖测试、自动化测试、性能压测和并行开发等。依赖测试支持 case Mock生效日期和端到端的Mock生效范围,主要是为了避免某一个case过大影响实际的测试范围。自动化测试支持自动开启、关闭对应的Mock开关。性能压测支持一键静默,只要把静默开关打开,所有的调用Mock case都不会生效,这时所有的性能压测都会走原始的调用请求。并行开发支持生效范围界定和Mock参数动态调整等。当然我们在测试过程中不要过度依赖基于Mock的测试结果,Mock只是一种提效手段,基于Mock的测试无论如何多么的充分,都不能保证不会遗漏。一个完整的测试策略,一定是由基于Mock的测试和基于非Mock的测试共同组成,二者相辅相成,缺一不可。

HiMock平台能力介绍

图片

这里介绍RPC接口的新增,在Mock标题里可以根据自己的场景设置标题,如助力车赔付,应用名称、iface、method是要拦截的对应服务以及它对应的method。在右边,我们也可以看到对应这两个应用名称,后面可以查看Atlas的配置,如果选择在ClientAppId进行Mock拦截,需要把对应服务的自定义启动参数中Agent启动命令配置上去。Mock环境里FAT和UAT都可以选择,同一个case多个环境同时生效。生效时间默认是永久生效的,如果填写生效范围,只会针对生效时间范围内走Mock逻辑;下面也有对应的是否开启的开关。添加规则这里,我们支持从用户请求日志里自动获取对应的请求有哪些参数,减少用户手动填入的复杂度。最下面的请求响应、执行日志和变更记录,主要用来查看预执行的时候对应这个规则能否匹配到,哪一步拦截失败,进而去调整Mock匹配规则。针对复杂场景,我们支持后置模拟回调,包括HMS、HTTP等。

图片

这里是测试请求,测试请求自动填入,也可以根据实际情况进行动态调整,Mock结果即时校验。执行日志做到了执行过程的匹配,结果校验可以实时看到匹配规则是否正常匹配,以及匹配的返回结果是否是想要的。

图片

接下来介绍前端一键Mock的功能,左边是我们的APP端,右边通过扫码APP-QrCode就可以看到左边菜单栏有自动抓包的链路信息,点击后会有接口对应的Request和Response。这里我们可以快速Mock对应接口的返回,或者是Mock异常的返回。

HiMock平台效果价值回收能力分析

图片

我们主要从六部分进行HiMock效果价值回收能力分析,包括接口调用统计分析、Mock业务线覆盖统计分析、Mock占比分析、业务线Mock运营分析、Mock case统计分析和Mock次数、平均耗时统计分析。

image.png

这里是HiMock平台整体的调用统计分析,可以看到具体某个业务线、当天调用量和对应的Mock次数。左边是调用统计的趋势图,右边是业务线Mock次数的占比。

后续规划&探讨

图片

Mock平台我们分三步走,第一步是测试小哥哥小姐姐通过手工Mock的方式人肉抓包Mock返回,后端Mock代码改动较大,费时费事费人,重复劳动严重。第二步是HiMock一体化Mock平台,可以支持全场景、多端Mock。前端自动抓包一键Mock,规则匹配参数自动生成,日志请求自动填充,极大提升了我们Mock case的整体效率。第三步是HiMock智能化,我们后续也会支持适配中间件DB、MQ类型协议的Mock,与仿真实验室、精准自动化的进一步结合,打造研发、精准测试、高效运营的一体化Mock,并打造智能出行Mock平台,能够self-learning自适应,以及更多场景的Mock支持。

(本文作者:崔焕锐)

图片

本文系哈啰技术团队出品,未经许可,不得进行商业性转载或者使用。非商业目的转载或使用本文内容,敬请注明“内容转载自哈啰技术团队”。

哈啰技术
89 声望53 粉丝

哈啰官方技术号,不定期分享哈啰的相关技术产出。