共计 6000 个字符，预计需要花费 15 分钟才能阅读完成。
一分钟精髓速览
流量录制与回放技术在故障排除、性能优化和降级迁徙等方面具备重要的利用价值。流量录制是指记录网络通信过程中的数据包，包含申请和响应数据，以便后续剖析和调试。流量回放则是将录制的数据包从新发送到网络中，以模仿实在的网络通信环境，验证网络应用程序的性能和稳定性。
本文以去哪儿网为例，介绍流量录制与回放实际，探讨其在接口自动化测试和全链路压测中的利用功效。
作者介绍
去哪儿高级 Java 研发工程师——沙丹丹
TakinTalks 社区专家团成员。2017 年退出去哪儿，致力于晋升研发和测试人员的效率。在 CICD、测试工具畛域有丰盛的教训，负责去哪儿网写接口自动化测试从 0 - 1 的落地、写场景全链路压测从 0 - 1 落地。
舒适揭示：本文约 4500 字，预计破费 8 分钟浏览。
后盾回复“交换”进入读者交换群；回复“5131”获取课件材料；
背景
去哪儿网是一种漏斗形业务构造，从搜寻、生单到领取，其 QPS 是逐步升高的，所以前几年咱们更关注漏斗顶端的读场景测试，即搜寻环节的测试。而生单和领取这类写场景的测试，因为测试数据结构艰难、保护老本等各类起因，此前去哪儿网写场景的测试能力不够欠缺，很多零碎的写接口只能依附人工测试。
而人工测试的弊病是非常明显的，比方零碎改变大、改变频繁，容易产生漏测等。这就会导致故障频发，甚至影响用户的出行和体验。
（去哪儿网某小部门近一年的故障列表）
从故障产生列表能够看出，在接入写接口自动化测试之前，均匀每个月都会产生 2～3 个故障。深入分析这些故障，基本上都是因为数据和环境有余，导致某些非凡 Case 场景没被测试到，或是某些回归 Case 漏测导致的。
基于以上的痛点，去哪儿将两种次要的写场景测试计划进行了比照。综合比照结构 Case 老本、上游数据 Mock 老本、保护老本等各方面，最终咱们抉择利用录制回放技术。
我接下来将分享录制回放技术在去哪儿的具体落地，次要蕴含该技术在接口自动化测试、全链路压测中的利用和落地成果。
二、技术计划如何抉择和演进？
阶段一：Areas（二开 JVM-Sandbox）
阿里在 2017 年开源 JVM-Sandbox，去哪儿网基于它开发了自动化测试工具 Areas。但在应用过程中，此工具有肯定的局限性。比方，工具应用方须要引入 jar 包接入老本高，工具保护方须要开发对应的插件，开发成本高。
阶段二：Q-Thanos-Agent（二开 JVM-Sandbox-Repeter）
起初在 2019 年阿里又开源了一个专门做录制回放的 JVM-Sandbox-Repeater。其劣势是有阿里开源社区的反对，可靠性比拟高。它能够开发自定义插件，扩展性很强，整体开发成本较低，能够疾速落地实现。
而因为它有两层封装——底层是 JVM Sandbox，上一层是 Repeater。为了实现跨线程录制，就义了一部分性能，所以对 QPS 较高的服务会有肯定性能影响。目前去哪儿网仍在应用该 Agent，前面我也将介绍其具体性能影响。
阶段三：Cinema-Agent（自研）
因为要将录制回放技术利用到全链路压测的场景中，所以对于 Agent 的性能有了更高要求，因而去哪儿网自研了 Cinema-Agent。其劣势是它是齐全自研的，与公司的根底组件联合性更高，开发人员的开发和保护体验会更好，性能也会更好。目前为止，去哪儿在线上的所有利用都装置了此 Agent，暂未发现性能瓶颈。
阶段二和阶段三的两个 Agent 目前都在应用中，只是用处和场景不同——Q-Thanos-Agent 次要利用于写接口的自动化测试，Cinema Agent 次要利用于写场景的全链路压测。接下来我将别离介绍这两个 Agent 的利用。
三、录制回放技术在接口自动化测试中的利用
3.1 反对的性能
写接口的特点是对于同样的参数，屡次申请的返回数据是不幂等的。目前去哪儿接口自动化测试反对的性能如下：
1）读接口的自动化回归测试。其测试形式是间接发动申请。
2）写接口的自动化回归测试。它应用的技术就是录制回放。
3）利用配置批改自动化验证。
3.2 测试流程
整体的测试流程是用户首先在自动化测试平台里新建利用配置，包含接口配置还有录制回放的配置。
在正式测试阶段，首先是触发测试。而后生成 Case，同时会部署它的环境。而后执行 Case。最终将执行 Case 的后果进行 Diff，而后生成测试报告。
3.3 录制回放实现原理
3.3.1 JVM-Sandbox-Repeater 的原理
在沙箱的世界观中，任何一个 Java 办法的调用都能够拆分出三种事件——Before、Return 和 Throw。比方，在执行行为 A 之前，能够获取其 Before 事件，拿到 URI 和申请参数。在行为 A 执行实现后，就把这种事件叫做 Return 事件，探测到 Return 事件时，咱们能够获取到该办法的返回值。执行行为 A 的过程中如果抛异样，此时就是会产生一个 Throw 事件。由此咱们就能够失去一个 Java 办法的 URI、Request 和 Response 来实现对行为 A 的录制。
比方一个线上服务 Service A，它下面装了一个 Repeater Agent。当一个 HTTP 的内部申请进来时，咱们就能够失去这个申请的 URI、Request。如果内部申请又调了 Service B 或 Service C，或者是进行了 Redis/ MySQL 数据库的查问批改，也同样能够失去这些子调用信息，并把申请参数和返回值录制下来。
最终就能够失去一份残缺的录制信息，包含入口的 URI、Request 和 Response，各个子调用的 URI、Request 和 Response。
3.3.2 Agent 二次开发
基于以上 Agent，咱们二次开发了 Q -Thanos-Agent。去哪儿有很多的自定义组件，如 HTTP、Dubbo、Redis 等等，咱们对这些组件都进行了自定义的二次开发。具体开发状况如图。
3.4 写接口自动化测试过程
3.4.1 录制回放流程
咱们会在抉择一台线上机器，装置 Repeater Agent 来实现线上流量的录制。并在两个 Beta 环境装置 Repeater Agent。其中一个 Beta 环境部署的是 Master 代码，能够把它作为基准环境。另一个 Beta 环境部署的是分支代码，能够把它当做实在的测试环境。
通过 Wed 端自动化测试平台，从线上的录制数据中筛选和捞取一批 Case，再将这些 Case 别离对两个测试环境发动申请。当这两个环境机器上的 Agent 辨认到回放申请时，就会从数据中心拉取录制数据。而后对这些入口和子调用进行回放，最初将回放的数据也上报到数据中心。
自动化测试平台从数据中心把这两个环境的回放数据拉取回来，而后将它们的接口返回值和每个子调用的入参进行 Diff，最终生成一个测试报告。
3.4.2 自动化测试平台架构图
基于以上测试流程，咱们把零碎划分成三个局部。
第一局部是管制测试流程的 Web 端服务，包含配置管理和整个测试流程的管制。
第二局部是数据中心，用来保留录制数据和回放数据的。
第三局部是录制回放的 Agent，它是挂载在业务利用过程上的。
（自动化测试平台架构图）
3.4.3 录制数据样例
该录制数据的样例，包含入口 URL、申请参数、返回值，还有这个入口上面的所有子调用。
3.4.4 回放数据样例
该回放数据的样例，包含两个环境的回放数据，一个是基准环境的回放数据，一个是测试环境的回放数据。而且能够提供这两个环境回放数据入参的 Diff。点击环境参数就能够看到这个 URI 对应的参数。如果某一个子调用在某一个环境没有回放也能够提醒。
3.5 落地成果
3.5.1 侧面业务成果——
a. 已接入利用（外围利用 200 个，包含读写利用）：35 个
b. 已接入写接口：296 个
c. 新接入一个接口的 50 个 Case 工夫老本：从 1pd 升高到 1h
d. 故障率：0.28% 升高到 0.18%
3.5.2 负面性能影响——
a. 单机 QPS 超过 200 的利用刚启动会有 JIT 问题，如果利用没有预热逻辑，会导致业务接口超时；
b. CPU 使用率上涨：1%~3%；
c. 内存上涨：3%~5%；
四、录制回放技术在全链路压测中的利用
4.1 利用背景
近几年去哪儿网所在的出行业务有显著的稳定，所以咱们做了很多降本提效的工作，比方集群缩容、零碎重构、零碎精简、代码瘦身等等，业务零碎的变动是十分大的。在流量上涨（比方节假日）或者秒杀流动时（比方机票盲盒），这些写场景的业务零碎如果不进行一轮压测，当流量上涨时能不能接受住冲击，其实大家心里是没有十足把握的。所以亟需实现一套写场景的压测计划。
写场景会存在返回后果不幂等的问题，比方，用雷同的参数生单，第一次生单胜利，但第二次生单可能就会失败，会校验进去是个反复的订单。所以写场景中咱们又用到了录制回放技术，来解决接口和数据 Mock 的问题。
4.2 全链路压测 Web 系统结构
整个零碎包含写场景创立、影子库治理、挡板配置、挡板调试、入口 Case 生成、子调用预热、触发压测、生成压测报告等等这些小模块。
除了 Web 端的录制回放中控以外，咱们还在业务零碎上挂载了一个 Cinema Agent，这个 Agent 和业务过程在同一个 JVM 里。数据中心用来保留录制数据，录制的原始数据保留在 ES 中，入口 Case 的数据会导入 MySQL 中。
在压测时，咱们要尽量减少回放的提早，所以会首先把子调用预热到 Redis 中，来升高因为回放造成的提早。
4.3 全链路压测录制回放流程
去哪儿是在线上环境进行的实在流量录制，也是在线上环境进行流量压测。比方，一个用户在线上实在下单时，咱们能够辨认到这是一个须要录制的入口申请，此时依据以后采样率看这条申请是否须要被采样。如果是，则会给它生成一个惟一标识。这个惟一标识会被带到这个入口申请的上游去，上游的每一个零碎都能够辨认到这是须要被录制的流量，把需设置挡板的中央录制下来。
比方，B 调 D 这个子调用在压测时不能让它实在调用上来，咱们能够提前把它设置成挡板，在录制时，走到这个子调用时就会主动录制下来，录制信息包含惟一标识、利用名、调用类型、URI、Request、Response、是否是入口等。
在实在的压测阶段，压测平台会从数据中心导入一部分入口 Case，而后将这些 Case 以肯定的 QPS 压测上来。在压测系统模拟下单时，会辨认到这是一次压测的流量。如果某个子调用设置了挡板（比方：B 调 D），Agent 会辨认到这是一个须要被回放的调用，就会从数据中心的录制数据中获取该调用的返回值，间接返回回去，实现 Mock 的成果，就不会实在调用到 D 了。
对于数据库的操作，咱们线上有影子 Redis 和影子的 MySQL。写操作是间接写到影子 Redis 里。读操作当初是会录制 Redis 的 Get、Exist 等，通过设置挡板的形式实现录制。对于 MySQL，写操作会写到影子库，读操作会优先读影子库，如果影子库外面没有这份数据，就会 Call Back 到线上库。
以上就是整个压测的流量录制和回放的流程。
4.4 痛点 / 踩坑分享
4.4.1 痛点 1：挡板配置梳理
问题：写场景个别是指下单、领取、发短信等对用户有本质上影响的操作，在全链路压测时，有些行为须要 Mock。比方：调代理商占座、下单、实在领取、反复单校验、订单状态校验、订单状态批改等，这些操作不能实在去调用。那咱们如何可能把这些挡板设置下来？
计划一❌：业务同学梳理挡板，毛病是链路长，波及 100 多个利用，齐全由人工梳理不全。如果某个挡板没有设置，则会导致压测流程不通。
计划二✅：半自动化设置挡板
首先设一个全局公共挡板，用来拦挡所有外网调用，保障不会申请到外网。接着依照以下流程进行调试。
回放 1 个 case，针对业务不通的中央设置挡板的这个操作流程一直反复，最终就能够把一个链路调通。即采纳的是疾速调试，每次用一个 Case 来摸索哪个中央应该设置挡板，一直地反复，直到多个 Case 都可能顺利地走完业务流程，才算调试完结，以此来保障挡板不脱漏。
4.4.2 痛点 2：子调用回放 Response 抉择
问题：设置档板时，同一个接口或 redis.get() 可能会调用屡次，每次的参数和返回值可能有差别，如何保障正确抉择返回值？
计划一✅：按录制程序回放（默认策略）
适宜大部分调用程序固定的状况。长处是回放时抉择的速度较快。
计划二✅：取第一次或最初一次后果回放
实用回放时的调用次数比录制时的调用次数多。
计划三✅：按参数类似度含糊匹配
很多并发场景下，同一个 URI 的子调用会录制屡次，且录制的程序和回放时的调用程序是不一样的。比方，同时生成 3 个子单，然而其程序是并行的，没有前后之分，此时则可按参数类似度来含糊匹配。
这里提供两种计算类似度的算法。第一种是简略算法——汉明间隔，两个字符串截取最短的字符串的长度，将这两个截取后的字符串进行比照。其毛病是误差较大。第二种是简单算法，用 JSON 里雷同 Value 的字段占比来计算类似度。比方，一共有 20 个参数，其中 10 个都是雷同的，则其类似度占比就是 50%。此时选取一个类似度最高的返回值即可。
4.5 落地成果
4.5.1 侧面业务成果
a. 解决了写压测不能发明流量的痛点
b. 已接入机票业务线写场景：8 个（生单、领取前校验、领取、机票盲盒流动等）
c. 最长生单链路利用个数：100+
d. 一个链路首次接入均匀调试工夫：5pd
e. 压测指标流量：2 倍 +
f. 压测数据录制 + 筹备工夫：40min 内
g. 压测 Case 成功率：95%+
h. 压测过程中，有发现业务零碎异样量上涨，真正发现了问题
4.5.2 负面性能影响
a. Cinema Agent 对业务零碎根本无性能影响
五、总结与瞻望
目前 Q -Thanos-Agent 和 Cinema Agent 去哪儿都在应用中。
Q-Thanos-Agent 次要利用于写接口的自动化测试。其应用形式是在线上环境的机器进行录制，在 Beta 环境进行回放，实用于单机 QPS 不高的写场景。也正在摸索其余的应用场景，比方用在精准测试中。
Cinema Agent 次要利用于写场景的全链路压测。这个 Agent 是所有利用都装置的，适宜对性能要求高的场景。正在摸索利用在接口 Mock 平台。
将来去哪儿可能会将 Q-Thanos-Agent 的性能合并到 Cinema Agent 里。一方面是为了精简装置到业务服务上的 Agent 个数，另一方面是为了在雷同性能的改变时，保障逻辑对立，更易于保护。（全文完）
Q&A
**1、压测的时候是否反对回放历史数据？
2、对于流程式的场景如何获取上一步的业务数据？在录制的数据中要进行脱敏解决吗？这个数据会和实在的服务器会交互吗？
3、订单号在不同的环境中，如何保障生成的是统一的？**
更多具体内容，欢送“点击跳转”，观看完整版解答！
增加助理小姐姐，凭截图收费支付材料
并收费退出「TakinTalks 读者交换群」
申明：本文由公众号「TakinTalks 稳定性社区」联结社区专家独特原创撰写，如需转载，请后盾回复“转载”取得受权。
本文由博客一文多发平台 OpenWrite 公布！