4、流量回放与压测：录制生产流量，在仿真环境中回放，验证系统稳定性
说实话，很多团队做仿真迁移，最怕的是什么？
不是代码跑不通，也不是环境配不好。而是——仿真环境里一切正常，一上线就崩了。
为什么会这样？因为仿真环境里的流量是假的，是测试人员手写的。真实的生产流量，那叫一个「千奇百怪」。有凌晨三点的爬虫攻击，有双十一的瞬间峰值，有用户反复点击提交订单的骚操作……这些，你靠手写用例根本模拟不出来。
所以，我个人的习惯是：仿真环境上线前，必须做流量回放和压测。说白了，就是把生产环境的真实请求录下来，在仿真环境里重新放一遍，看看系统扛不扛得住。
4.1 流量录制：从哪里来，怎么录？
流量录制，核心就两个问题：录什么？怎么录？
录什么？
- API 请求：HTTP/HTTPS 的请求头、请求体、响应状态码
- 数据库查询：慢查询、高频查询、写操作
- 消息队列：生产/消费的 topic、消息体、延迟情况
- 第三方调用：外部服务的请求和响应
怎么录？
我推荐三种方式，按场景选：
| 方式 | 工具 | 适用场景 | 注意点 |
|---|---|---|---|
| 网关层录制 | Nginx + lua, Kong, APISIX | 全量 API 请求 | 注意磁盘空间，建议只录采样 |
| 应用层录制 | Java Agent (如 SkyWalking), Python middleware | 需要上下文关联的请求 | 对性能有 5%-10% 影响 |
| 网络层录制 | tcpdump, goreplay | 快速验证，不侵入代码 | 无法关联业务上下文 |
我的经验： 如果只是做压测，用 goreplay 就够了。它可以直接从网卡抓包，然后转发到仿真环境。我曾经在一个日活千万的项目里，用 goreplay 录了 2 小时的流量，回放时发现了一个隐藏很深的死锁问题——那个问题在测试环境跑了三周都没发现。
4.2 流量回放：怎么放？放多少？
流量录好了，接下来就是回放。这里有个关键点：回放不是简单的「重播」。
你想想看，生产环境有 100 台机器，仿真环境只有 5 台。你把 100 台机器的流量全部压到 5 台上，那肯定崩。所以，回放要做两件事：
- 流量缩放：按比例缩小或放大。比如生产 10000 QPS，仿真环境只有 1/10 的资源，那就回放 1000 QPS。
- 时间压缩：把 1 小时的流量压缩到 10 分钟放完，模拟突发流量。
具体怎么做？我一般用这个脚本：
# 使用 goreplay 进行流量回放
# 录制：从 eth0 网卡抓取 80 端口的流量，保存到文件
sudo gor --input-raw :80 --output-file=production_traffic.gor
# 回放：按 0.5 倍速率回放，目标地址为仿真环境
sudo gor --input-file=production_traffic.gor --output-http="http://staging.example.com" --split-output=true --input-file-loop=false --rate-limit=500
注意： 回放时一定要做 流量隔离。我曾经见过一个团队，回放时把生产流量直接写到了仿真环境的数据库里，结果仿真环境的订单数据和生产环境混在一起，排查了三天才清理干净。建议回放时只读不写，或者使用独立的数据库实例。
4.3 压测：不只是看 QPS
流量回放能验证「功能正确性」，但压测验证的是「系统稳定性」。很多人以为压测就是看 QPS 能到多少，其实不然。
我一般关注这几个指标：
- 响应时间（RT）：P50、P95、P99。P99 超过 500ms 就要警惕了。
- 错误率：5xx 错误、超时、连接拒绝。超过 1% 就要停。
- 资源使用率：CPU、内存、磁盘 IO、网络带宽。任何一个超过 80% 都算危险。
- GC 情况：Full GC 频率、GC 暂停时间。Java 应用尤其要注意。
压测工具我常用这几个：
| 工具 | 优点 | 缺点 |
|---|---|---|
| wrk | 轻量、单机就能压几万 QPS | 不支持复杂场景 |
| JMeter | 支持复杂脚本、分布式压测 | 配置繁琐、资源消耗大 |
| Locust | Python 编写、易于扩展 | 性能不如 wrk |
| goreplay | 直接回放生产流量 | 无法自定义场景 |
避坑指南： 我曾经在一个压测项目里，用 wrk 压了 10 分钟，QPS 稳定在 8000，以为系统没问题。结果上线当天，流量一上来，数据库连接池直接打满，服务挂了。后来排查发现，wrk 压测时请求是均匀的，但生产流量有「突发性」——比如整点秒杀、用户集中刷新。所以，压测一定要模拟 突发流量，而不是匀速流量。
4.4 知识体系：流量回放与压测的核心逻辑
下面这张图，是我自己总结的流量回放与压测的完整流程。你可以把它当作一个检查清单：
4.5 实战中的几个关键点
最后，分享几个我在实战中踩过的坑，希望能帮你少走弯路：
- 录制时长要够：至少录 1 小时，最好覆盖业务高峰期。我见过只录 5 分钟的，回放时什么问题都没发现，上线就出事了。
- 回放要多次：一次回放可能只是运气好。建议至少回放 3 次，每次间隔 10 分钟，让系统有足够的时间恢复。
- 压测要「破坏性」：不要只压正常流量。试试把流量突然翻倍、突然切断某个服务、突然让数据库宕机——看看系统能不能优雅降级。
- 结果要对比：回放结束后，对比仿真环境和生产环境的响应结果。如果差异超过 5%，说明仿真环境有问题，需要排查。
一个小技巧： 回放时，可以在仿真环境里埋一些「探针」。比如，在关键接口打印日志，记录请求和响应。这样，如果回放过程中出现异常，可以快速定位到是哪个请求导致的。我习惯用
@AuditLog 注解，配合 ELK 做实时监控。
嗯，流量回放和压测，说白了就是给系统做一次「全身体检」。录的是真实流量，放的是真实压力，查的是真实问题。这一步做好了，仿真迁移的成功率至少能提高 50%。
可可精品资料库