基础组件-流量回放(全链路流量回放预研)
一、调研
日常测试工作中，遇到问题如下：
1、服务架构升级或者重构，需要对原有的接口做全量回归
2、对于业务逻辑复杂的场景，每个迭代版本都需要大量的时间进行回归测试
3、编写自动化用例时复杂场景造数麻烦，日常自动化维护成本高
4、构造压测模拟数据麻烦
5、线上问题，无法再测试环境中重现
6、无法对线上核心接口采样之后做一些业务校验并实时监控业务正确性
二、流量复制
用户访问系统造成的数据传输定义为流量，那么在用户访问系统的过程中，可以把进入和流出的数据复制下来，进行保存，待后续使用
三、流量回放
获取到复制下来的流量后，按照接收的时间顺序，将他们一条一条的传输到待测试的服务中，让测试服务产生相应的响应
四、流量回放测试场景
1、复制下来什么内容就回放什么内容，即流量回放
2、复制下来的内容进行一些预设规则的过滤，或者特殊的处理后，再进行回放，即选择性回放
3、复制下来的内容，对其进行处理从中获取必要的数据项，比如搜索词，即关键词回放
五、技术选型
| 技术框架 | 语言 | 社区 | 协议 | 优点 | 缺点 |
|---|---|---|---|---|---|
| Jvm-sandbox-repeater | java | 活跃，github 2.0K start,博客较多，大公司有实践 | http,二进制 | 1、开源项目，功能丰富 2、单体，依赖少，无需配置，环境配置简单 3、功能丰富，支持流量过滤功能，按倍速回放功能，回放时改写接口参数等 4、资源消耗少，且不侵入目标应用的JVM运行环境，影响小 5、提供插件机制，插件不限制语言，方便拓展 | |
| GoReplay | golang | 活跃 github 15k star | 社区版：http 商业版本：http,二进制 | 1、开源项目，代码简单，方便定制 2、3、4、5 点同sandbox-repeater | 1、需要自研配置，监控、分析平台 2、社区版只支持HTTP协议，不支持二进制协议，且核心逻辑与HTTP协议耦合了，拓展麻烦 3、只支持命令行启动，没有内置服务，不好进行集成 4、官方提供插件较少 5、不支持mock 6、生产库会产生测试数据 |
| RDebug | php,golang、C++ | 一般，github 1.4k star | http | 1、开源项目，代码简单，方便定制 2、单体，依赖少，无需配置，环境配置简单 | 1、只支持命令行启动，没有内置服务，集成麻烦 2、功能简单 3、配置，监控，分析平台的支持机制，需要自研 4、不支持mock 5、生产环境产生测试数据 |
| tcpreplay | C | 一般，github 829 starr | http，二进制 | 同Redebug | 同Redebug |
| tcpcopy | C | 一般，github 4k star | http,二进制 | 同Redebug | 同Redebug |
| ngx_http_mirror_module | C | 活跃 | http,二进制 | 同Redebug | 1,2,3,4,5同Redebug 6、必须依赖nginx |