运营商复杂系统下的影子流量回放测试实践

浙江移动公司 | 戴安妮

一、 背景

云原生体系下，应用趋向于微服务化，服务器趋向于云化，愈加复杂的架构部署要求更高的测试覆盖率。同时，敏捷的迭代节奏又要求快速测试反馈结果，这就使得传统的测试用例设计 - 编写 - 执行 - 维护的模式无法满足当下的测试需求。文章源自玩技e族-https://www.playezu.com/186840.html

沙盘不是战场：构建类生产环境进行上线前的版本测试是通用的解决方案，起到沙盘演练的作用。但是线下的测试结果仍然会与实际情况存在偏差，尤其是性能测试。文章源自玩技e族-https://www.playezu.com/186840.html

模拟不抵真实：真实的业务请求不仅有各种入参的组合搭配，还有不同场景的混合叠加，很难通过人工设计模拟出来的，更遑论测试用例的维护工作量。文章源自玩技e族-https://www.playezu.com/186840.html

缺陷难以定位：微服务拆分使得业务调用链路呈指数级增长，而且海量的微服务也增加了缺陷定位的难度，导致测试价值打折扣。文章源自玩技e族-https://www.playezu.com/186840.html

二、 解决方案

浙江移动公司借鉴互联网行业流量回放的实践案例，再结合自身特点，在不改造系统框架的前提下，推动测试右移，并聚焦于查询类业务的流量回放，实现微服务架构性能管理的边际效益最大化。文章源自玩技e族-https://www.playezu.com/186840.html

依托于开源 Gatling 测试框架，自建流量回放测试平台，通过实时流量归档，筛选每个业务真实的业务场景和数据，并按不同的策略形成分片数据，在测试时按需抽取并组装，再回放至待测系统。文章源自玩技e族-https://www.playezu.com/186840.html

图 1 流量回放测试平台架构文章源自玩技e族-https://www.playezu.com/186840.html

1. 流量归档文章源自玩技e族-https://www.playezu.com/186840.html

通过对接日志框架，采用应用自主上报的形式，实现日均十亿条请求的流量数据通过 kafka 归档至 HBase 中。文章源自玩技e族-https://www.playezu.com/186840.html

2. 流量预制

针对采集得到的日志流量进行预处理，形成可回放的测试流量。

抽取：支持按时间、系统、地市等不同维度采集日志。

过滤：采用黑名单模式，剔除不可回放的接口流量，确保不影响用户数据、报表统计等。

染色：在回放请求中设置标记位，用于区分真实流量和回放流量。

组装：按接口报文格式组装流量。

分片：对数据文件进行分片存储，便于后续流量叠加使用。

图 2 流量分片示意图

3. 场景编排

分片流量不仅解决了性能测试铺底数据的困扰，更使得灵活编排混合业务叠加的复杂场景成为可能，适配各种差异化、精益化的测试需求。

Ø 业务分片流量编排

通过需求关联业务分片流量，实现敏捷迭代测试多、快、好、省。

Ø 地市分片流量编排

试点地市与其余地市分片流量的比对测试，凸显试点割接地市的差异化结果。

Ø 多分片流量编排

不同分片流量混合编排，提供了真实的铺底数据，提高单业务摸高测试准确度。

4. 压力控制

Gatling 是一款基于 Scala 开发的功能强大的负载测试工具，只要底层协议（如 HTTP）可以以非阻塞方式实现，Gatling 的体系结构就是异步的。这种架构允许我们将虚拟用户实现为消息而不是专用线程，这使得它们非常便宜。因此，运行数千个并发虚拟用户不是问题。

并且，Gatling 可设计非常丰富的压力加载模式，该特性可用于流量回放时拟合生产实际流量波动趋势，并发数根据生产实际流量波动实现秒级的即时调整，达到每一个时间切片上的业务组成也跟生产保持一致，从而最大程度还原真实业务场景。

首先，将日志流速转化为每秒的请求总量。

再以每 15 秒为一个节点，统计这段时间区间内的业务量均值，并将其转化为 Gatling 脚本的压力策略。

最终输出精确拟合线上业务量变化趋势的压测场景。

此外，通过在压力机上部署 agent，基于 Jenkins 实现 Gatling 的集群调度功能，使得测试流量可分发至多台压力机联合回放，实现更高并发压测能力。

图 3 Gatling 集群调度

1. 实时 DIFF

流量回放测试存在天然参考系，即影子流量在被测系统中的回放结果应与线上环境的真实返回一致。因此，根据真实返回结果来定义回放测试的预期结果，并进行实时 Diff 分析。

图 4 Diff 流程

1.噪声提取

依托于影子流量回放测试的特性，以真实的业务返回为基准，在提取因测试条件变化引起的噪声点后，沉淀出预期返回结果。

通过在稳定版本上回放一次测试报文，将所有的返回报文都持久化到本地 MySQL 数据库中。再对真实业务返回报文和回放测试产生的返回报文进行对比处理，通过偏移检测函数计算出每一笔业务请求的噪声和预期结果。

图 5 噪声提取流程

2.实时 DIFF 执行

通过调用 gatling 的 check() 函数，对每一笔请求的返回报文进行实时精准校验，以判断返回内容是否符合预期结果。得益于 gatling 的非阻塞异步实现方式，使得在高并发场景下，依然可以实现对每一笔返回报文进行全文检查而不降低效率，从而达到更加的个性化的 diff 手段。

首先从 MySQL 中预读所有的预期结果数据并写入内存中，这使得流量回放时无需多次调用数据库，减少性能开销。然后在流量回放测试过程中，对实时返回报文进行解析，将解析后的返回报文与预期结果数据进行一一 Diff，从而实现整个报文体的精准校验。

三、 思考

让数据创造价值：将流量数据转换成测试用例，突破了人工设计测试用例的桎梏，提高了压测流量准确性和实时性，降低了用例维护难度，实现了柔性化、定制化和精益化的压力测试，是典型的运维数据再消费场景。

世界上没有银弹：软件工程是一个超级复杂的系统，没有一种单纯的技术或管理上的进步，可以一直提高效率。运营商面对互联网行业的冲击，只有立足自身，不断提出问题、分析问题最后解决问题并且不断迭代，才能找到适合自己的解决方案。

技术红利提高生产力：通过技术创新聚焦查询类应用场景，在无需改变应用框架、非侵入系统的方式，实现测试体系变革，从人工测试转变成系统 “自产自销式” 测试，达到边际效益最大化。软件测试方法