流量回放的思考，有什么用处？

背景

在日常的测试工作中我们或多或少总会遇到下列问题：

1）服务架构升级，对原有的一堆接口做回归

2）复杂度太高的业务场景，每次迭代版本都需要大量的时间用于回归

3）编写自动化用例时面对复杂场景，日常维护成本高，简单场景做自动化，就是面子工程

此时流量回放的出现能解决我的部分问题：

  通过记录线上流量，在开发或者测试环境回放，用来回归原有系统功能，发现系统是否能够正常运行，降低代码变动整体系统带来的风险

流量回放原理

说流量回放之前必须得说下流量录制的原理，首先需要将agent下发到目标服务中，通过字节码增强对目标方法进行增强。录制时拦截对应的方法签名、入参、返回进行采集上报。回放时将录制的流量回放到指定的环境，通过流量返回的diff和断言比较接口业务代码逻辑是否存在问题。
流量录制的流程图如下：

流量回放的流程图如下：

工具分类

流量录制方式：

1）基于web服务器录制

  方案：在服务上定制化代码

  优点：请求类型比较多样

  缺点：不通用，维护成本高，会占用大量线上资源

2）基于应用层录制

  方案：在网关或基于AOP切面进行录制

  优点：对代码无侵入、实现相对比较快捷简单

  缺点：会占用线上部分资源、可能会对业务有影响

  常用工具：Nginx插件-ngx_http_mirror_moudle、Java-sandbox

3）基于网络协议栈录制。

  方案：直接监听网络端口，复制数据包方式录制

  优点：基本对应用无影响

  缺点：比较偏向底层实现成本较高

  常用工具：goReplay、tcpCopy、tcpReplay

工具解析

Jvm-sandbox-repeater
项目地址：https://github.com/alibaba/jvm-sandbox-repeater

使用jvm-sandbox沙箱技术，通过Java agent或者attach方式挂载到Java应用上。repeater模块根据配置的规则录制或回放数据，console模块主要负责触发和数据交互。

优点：

通过字节码增强的方式可以直接录制Java方法、子调用

对业务代码0侵入

模块功能丰富

缺点：

对服务运行环境有一定侵入

在挂载瞬间会占用较多的机器资源，当业务量大时可能会导致服务夯住

当前功能不完善，需要代码开发能力

流量回放平台和接口测试平台很相似，但是有不同点

相似点：

  1)都是基于接口层面测试，包含入参、出参、异常抛出
  2)都是可以基于出参结果进行断言
  3)都是可进行复杂场景的接口测试

不同点：

  1)流量回放是基于用户使用时录制的接口操作流程，一定程度上保证了业务连续性和逻辑合理性
  2)流量回放是以基础能力构建用户场景，满足单纯接口测试覆盖不到的用户场景痛点

建设过程：

目标：建设一个流量录制回放工具，可进行流量录制、回放的基础能力，在此基础上增加流量过滤策略、流量内精准断言、增加mock功能、流量编排能力。

Stage1：流量过滤策略

  配置新建接口的URI，此时录制时仅录制该接口产生的流量，自动过滤其他业务接口操作流量，在录制流量过滤混杂了其他业务场景的流量

Stage2.：流量内精准断言

  在回放详情的流量体中手动标记哪些需要断言，标记后依据不同标记方式进行不同断言

Stage3.：增加mock功能

  流量回放启动后自动启动MOCK接口方法redis、数据库调用，快速验证代码本身业务逻辑。同时针对于业务本身的复杂性，增加MD5加密、业务随机数、雪花算法、时间函数等等

Stage4.：流量编排能力

  基于实际业务发生时，用户可能存在的随机使用，我们创建了流量顺序，同一个录制的流量，通过流量编排后，可产生N个不同的业务场景