流量录制与回放（流量录制回放工具）



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

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

什么是流量录制回放？

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

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

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

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

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

流量录制回放的优劣点

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

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

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

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

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

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

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

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

技术落地要考虑的因素

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

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

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/bcyy/31143.html