海量流量下淘宝如何进行稳定的流量回放

作者:淘宝技术  全文2828字 阅读需10分钟

淘宝已经有非常大的应用数量和变更次数的基础上, 对流量回放也有更高的要求。那么在不断尝试流量的录制与回放的过程中,我们遇到了什么问题?

那么在不断尝试的过程中,我们遇到了什么问题?我们由从中得到了什么启示?流量录制回放又能给我们带来多少收益?本文将一一介绍。

开源地址

提前放出开源地址,

本开源项目是一款 基于 JVM-Sandbox 开发的一款 Java 流量录制、回放通用解决方案,

下文将会详细介绍,长按识别下方

二维码,关注“

淘宝技术

”官方公众号,并在对话框回复

“git”

即可获得

下载链接、了解更多详情。

为什么需要流量回放

淘宝网陪伴我们剁了已经有 15 年的手,在经过这么久的演变后, 整个淘系的服务端已经成为了有数千个应用, 每年变更数万次的大航母, 我们在面对这个航母时, 需要既能全方位了解系统的全盘数据,又能从小处着眼,观察 细节的精细代码运行状况。

并且, 面对全国以至于全世界物联网网民时,我们的测试用例写的肯定会有疏漏和不足, 我们也希望能从线上获 取到更加有意义的用例。

同时,我们整个淘宝已经有非常大的应用数量和变更次数了, 我们对流量回放也有更高的要求。

于是,我们开始了我们的流量回放研发之路。

技术选型

技术上选型我们使用了 JVM-Sandbox (以下简称 sandbox ), 其主要的特性与我们想满足的需求都是比较贴切的。

淘系技术质量开源项目「JVM-SANDBOX」在《

MTSC 2019年度开源项目奖 花落淘系技术质量团队

》一文中有提及,如果要获取开源地址可关注

“淘宝技术”

官方公众号,并在对话框回复

“测试”

即可获得下载链接、了解更多详情。

第一个流量录制与回放

首先,我们要找到第一个可录制的流量, 我们曾经尝试过比较简单的实现方案, 比如直接录制入口请求的地点, 然后通过 JSON 化后打 LOG , 回流数据, 进行数据存储后, 以泛化调用的方式进行回放。这样实现起来固然简单 并且快捷, 但是这样有一个致命的问题, 那么就是我们丢失了大量的 class 信息, class 信息丢失对于比较重的参数、返回值执行是有相当大的风险的, 会导致无法无法反序列化, 导致回放失败, 也可能因为循环引用,需要进 行定点改造, 这样就非常麻烦了,做不到我们的 0 代码改造。

当我们意识到这个问题后,我们明确的分析了问题所在, 解决办法也比较明确了, 因为只有同样的 JVM 才会加载 出同样的 class 信息,所以我们必须要在同JVM对录制的参数、返回值进行 java 序列化/反序列化( hessian/kyro 等)进行录制, 在同机进行反序列化后进行同机回放, 保证原汁原味 的 class 信息, 不再会有无法反序列化的问题。

★录制部分

通过 sandbox aop 到中间件层的 invoke 方法, 获取参数和返回值, 以 hessian 序列化成二进制,并通过消息的方式 发送至服务端进行存储。

★回放部分

从存储的二进制的数据拉取到本机, 通过反序列化成为 JavaObject , 直接以本地代码 invoke 执行, 得到返回值后 进行对比,得到结果。

于是,我们第一个简单且稳定的录制回放就完成了, review 一下:

可以看到,我们这个方法可以解决读接口的行为,无法满足写接口的行为, 写坏数据了就会引起故障, 我们如果想完整的进行录制回放,那么我们必须要解决这个写接口回放的问题。

写接口的录制和回放

我们究竟要怎么测写接口?如果是要完整落库后删除,那么可以通过回溯 binlog 等方式尝试做到,但是成本极高, 我们选择退而求其次的方式:在回放时,只要参数和类型一样, 就将真正的写行为直接 mock 掉。其具体做法就是:

在这里,我们将所有的 JVM 内请求进行了分类, 以URI作为区分类型标准, 以URI为准进行回放的 mock 行为准 则, 那么我们的整体架构有了一点点改变:

★录制部分

我们将所有的子链路都进行了录制, 每一个我们认定的子链路都以序列化的方式进行了存储,并且加入了 URI 和 index 来进行区分。

★回放部分

回放的时候, 每当回放流量执行代码中遇到我们的子链路代码时,都从数据中拉取相同 URI 的数据进行反序列 化, 当参数一致时, 直接以录制时的结果进行返回, 返回录制的那一个子链路的反序列化的 object 。

在这里可以看到,我们还有一个 script engine , 这里是插入了一个 groovy 代码执行器,主要是为了当我们遇到诸 如时间 、动态配置等类型的数据时,参数不一致,导致了我们子链路请求不一致, 无法正确的进行对比参数回放,所以通过一段 groovy 代码进行录制参数和执行参数修改, 将值赋值成为同样的结果后, 动态数值就会被固定 下来,可以被整成回放了。

至此,我们的写操作也完整的进行了录制和回放, 也保证了数据安全。

不过,我们可以看出,当我们将线上流量的录制量提高以后,我们出错后的排查成本非常高, 比如同样一个接口的 1 万个 case 错 2000 个, 这里需要排查起来就太困难了,我们需要更加完备的测试方式进行区分和组合我们的 case 。

执行范围与测试范围分析

我们在制作录制回放的同时,我们也做了基于接口链路的执行路径录制,可以很明确的分辨出每一个请求的执行 代码路径(类似 Jacoco ,不过 Jacoco 是基于整体的, 基于接口/线程级需要自己修改 Jacoco , 也不是很复杂), 基于这个路径,我们做了以下的事情:

1. 进行了代码链路聚合,录制的 case 我们可以用执行路径的区别进行等价类划分,称为链路热度,同样的路 径,我们可以一目了然, 以同样的路径进行推荐就可以作为链路 case 推荐,大大减少重复的 case 。

2. 代码路径在回放的时候也进行链路追踪,执行追踪后可以得到路径的diff,也同样的能感知到修改的代码是 否对结果有影响,是否链路发生改变, 可以得出变更的范围。

总体效果及展望

目前我们在运行的流量录制回放应用在例如大型架构迁移应用上,基础能力的回归基本可以做到 0 成本, 可以稳定 的进行回放。

经过过去一年的建设, 如本文开头说的,我们开源了这整套体系,不过,我们并不会止步于此, 基于JVM-sandbox 和 repeater ,我们更多可以涉足的领域,例如:压测数据生成、故障模拟、混沌工程等应用场景, 我们将一直向前, 为整个行业带来丰富多彩的能力。

推荐阅读

历时1年,上百万行代码!首次揭秘手淘全链路性能优化(上)

阿里首次将用户手势数据用于电商场景!淘宝提出的算法DIPN秒杀传统模型

2019-08-27 15:22阅读2368次