流量录制回放，不是银弹！

前几天在技术交流群，大家又讨论起了流量录制回放的话题。我观察了一下，讨论的人不少，大体有这两种观点：第一种观点认为，流量录制回放的应用前景很广阔，能大幅度提高测试效率和技术逼格，都想在自己团队落地，但需要一些最佳实践参考；第二种观点则认为只有大厂才能做这个实践，小公司就别想了。

我无法完全赞成或者反对这两种观点，只能结合自己的一些实践经验和看到过的案例，谈谈我对流量录制回放的看法。

什么是流量录制回放？

流量录制回放，就是通过录制线上的真实流量，然后在测试或者生产环境模拟请求进行验证的一种技术方法。简单理解其实和我们利用其他工具(比如 JMeter/postman)构造请求，然后根据返回的响应数据判断测试是否通过的本质相同。两者的区别在于：流量录制回放的机器执行占比较多，而传统的利用测试工具来发送请求手段，人工介入的占比较多。

关于流量录制回放这个概念和技术实践，最早是在 2010 年，由英国公司 Riverbed Technology 开发，用于网络性能监控和诊断，以便在出现问题时进行快速诊断和解决。而国内，最出名的应该是阿里在 2019 年开源的流量录制回放工具：JVM-Sandbox-Repeater。

JVM-Sandbox-Repeater 最初要解决的是线上全链路压测时遇到的一些问题，主要如下：

• 模拟请求和真实用户请求存在偏差；

• 线上全链路压测对系统存在一定的侵入；

• 模拟请求无法完全覆盖特定的业务流程和场景；

后来随着经验的累积和技术的不断迭代优化，也用来解决其他方面的测试问题，比如：

• 线上 bug 在测试环境的复现；

• 服务重构和复杂系统调用关系下的回归测试问题；

• 业务越复杂，系统越庞大，接口自动化测试用例维护成本越高；

目前关于流量录制回放的工具有不少，下面是主要的几种工具：

• ngx_http_mirror_module：Nginx 内置的模块，提供流量复制功能；

• TcpCopy：一个开源的流量回放工具，支持多种类型流量的实时及离线回放；

• Sharingan：基于 Golang 的流量录制回放工具，通过修改 Golang 源码，加钩子拦截并镜像流量；

• GoReplay：Golang 编写的开源工具，利用 gopacket 库，基于 libpacp 抓包并利用 go 的协程特性实现回放速率控制；

• JVM-SANDBOX-Repeater：JVM-Sandbox 生态体系下的重要模块，插件式设计可以快速适配各种中间件，封装请求录制/回放基础协议，提供了很多通用可扩展的 API；

流量录制回放的优劣点

如上所述，流量录制回放技术的应用场景很丰富，在性能测试、回归测试、自动化测试以及线上问题快速修复方面有广泛的应用前景，可以帮助技术团队解决复杂业务场景和系统架构下的稳定性保障以及研发过程效率问题。

但问题来了，看似完美的技术方案在团队中落地时，要面临很多的挑战，主要有如下几点：

• 绝大多数业务都有各种登录状态校验和风控安全考量，录制的数据面临各种校验不通过的问题；

• 很多业务场景非幂等，比如某商品只允许同一 ID 下单一次，比如三方支付回调和三单匹配问题；

• 很多系统存在各种内外部依赖调用，而录制的数据如果不经过处理直接回放，很多场景会报错；

上述三点主要是技术层面的挑战，但在实际的工作场景中，很多技术无法落地的原因往往不是技术本身的问题，而是投入产出比的问题。

首先，流量录制回放本身对一个团队的基础技术设施建设要求较高，这背后就是高昂的前期投入成本和时间成本。

其次录制的数据要保存、脱敏、加工处理，还要和业务链路以及场景匹配，这个过程只能由工程师人工来进行，且不是短时间就能梳理清楚的，这又是成本的一部分。

再次，一个技术方案从调研到完全落地，这个过程需要一定的试错成本，也需要时间和人力资源去配合，在降本增效大环境下，企业很难在短期内看不到明显直接效益的方向投入巨额成本。

最后也是最关键的一点，技术团队从上到下都背负着 KPI，越是优秀复杂的技术，落地所需的时间和人力成本越高，KPI 会倒逼领导做出短视的决定，这无关对技术的信仰和认可，只关乎个人的职场生存问题。

也难怪大家说，优秀的技术实践是一种只会发生在大公司的富贵病。

技术落地要考虑的因素

最后分享一些我个人实践流量录制回放时的经验总结，大家避免踩坑。

1. 流量录制回放技术，更适合复杂业务+复杂系统架构+高并发高性能的系统。因为复杂和高并发，背后才有更高的商业利润和问题的修复成本，落地的可行性才越强。

2. 技术建设和实践是逐步迭代的，如果团队的基础技术设施建设一般，比如 CICD、灰度发布、自动化测试和线上全链路压测等没有较为丰富的实践经验，不建议去实践流量录制回放。

3. 就技术实践来说，流量录制回放要解决这几点核心问题：环境隔离、应急预案、仿真用户数据、数据加工处理以及完善的 mock 手段。

4. 流量录制回放并不能直接发现多少线上问题，相比于投入巨额成本和时间去落地流量录制回放，还不如在这几个领域多投入：捋清需求、编码规范、项目管理、分支和环境管理。

最后我要说的是，流量录制回放是看似美味实则难以下咽的技术盛宴，多了解借鉴它的思路没错，但在决定落地前一定要全方位考虑清楚。