🌊 流量模拟
流量模拟是全链路压测的灵魂——流量不够真实，压测结果就毫无意义。 本章从流量模型构建、生产流量回放、流量调度控制到异常注入和结果比对，构建完整的流量模拟方法论。
1. 流量模型构建
流量模型是压测流量的设计蓝图，决定了压测在多大程度上反映真实业务场景。 一个好的流量模型需要覆盖业务比例、用户行为分布、数据分布等多个维度。
📐 流量模型五要素
| 要素 | 说明 | 银行场景示例 |
|---|---|---|
| 业务配比 | 各业务接口的请求比例分布 | 查询:转账:理财:缴费 = 60%:20%:12%:8% |
| 请求参数分布 | 请求参数的取值范围与概率分布 | 账户余额符合幂律分布（少量大额+大量小额） |
| 用户行为模式 | 用户的思考时间、点击流、会话长度 | 登录→查询余额→转账→查询→登出，平均思考时间 5-15s |
| 时间节奏 | 流量的时间分布特征（峰谷变化） | 工作日 9:00-11:00、14:00-16:00 为高峰期，TPS为低谷的 3-5 倍 |
| 数据量级 | 压测数据集的规模、多样性、热点分布 | 账户数 5000万，活跃账户 800万，热点账户 Top 100 占比 15% 流量 |
1.1 流量建模方法
银行系统推荐采用以下组合建模方法：
📊 三种流量建模方法对比
| 方法 | 实现方式 | 优势 | 局限 |
|---|---|---|---|
| 业务推导法 | 从业务规划目标（如日活用户数、交易笔数）和用户行为路径出发，逐层推导各级接口的TPS目标 | 适用于新业务/无历史数据的场景，逻辑链条清晰 | 依赖业务假设，可能与实际有偏差 |
| 历史数据分析法 | 采集生产环境一段时间（通常1-4周）的访问日志，通过日志分析提取出真实业务配比和参数分布 | 数据驱动，模型最接近真实场景 | 依赖完整的日志采集体系，对日志质量要求高 |
| 混合建模法 | 历史数据提供现状基线，业务推导提供增长预期，两者加权合成最终流量模型 | 兼顾真实性和前瞻性，最佳实践 | 需要较强的建模能力 |
2. 生产流量回放
生产流量回放是获取真实流量的最有效手段：录制生产环境的真实请求，在压测环境中回放， 获得与生产几乎一致的流量特征。
2.1 流量录制方案
🎬 流量录制技术方案对比
| 方案 | 原理 | 录制位置 | 优势 | 劣势 |
|---|---|---|---|---|
| 网络层录制 | 通过 tcpdump/pcap 抓取网络包，解析HTTP/RPC协议还原请求 | 负载均衡/网关 | 应用无侵入、适用所有协议 | 数据量大、解析复杂、加密流量难处理 |
| 网关层录制 | 在 API 网关（Nginx/Kong）通过日志/插件录制请求和响应 | API 网关 | 集中录制、配置灵活、性能损耗低 | 仅能录制经过网关的流量 |
| 应用层录制 | 通过 Java Agent/AOP 拦截器录制方法调用入参和返回 | 应用服务器内部 | 可录制内部RPC调用、支持参数过滤脱敏 | 需要应用改造、有一定性能开销 |
| 中间件录制 | 在消息队列/数据库代理层录制流量 | 中间件层面 | 对应用完全透明 | 方案复杂、定制化强 |
2.2 银行场景流量回放特殊要求
- 敏感数据脱敏：录制流量中的敏感字段（卡号、身份证、手机号）必须在录制阶段实时脱敏后再存储
- 时间戳处理：录制请求中的时间戳参数需要做偏移处理，避免回放时因时间过期被业务逻辑拒绝
- 幂等性保障：交易类请求（转账、支付）在回放时需要替换幂等键（如交易流水号），避免重复提交
- 会话关联：需要保持同一用户会话内的请求顺序和 Cookie/Token 关联关系
3. 流量控制与调速
全链路压测的流量控制要求精确、平滑、可控，能够按照预设的梯度模型逐步加压，同时支持突发流量模拟和紧急熔断。
🎛️ 流量控制策略
| 策略 | 说明 | 实现方式 | 使用场景 |
|---|---|---|---|
| 固定速率 | 以恒定 QPS 持续施加压力 | 令牌桶算法，恒定令牌生成速率 | 稳定性测试、长期浸泡测试 |
| 梯度加压 | 按预设阶梯逐步提升 QPS（如 20%→40%→60%→80%→100%） | 定时调度器调整令牌速率 | 标准容量测试、拐点识别 |
| 突发脉冲 | 在基准负载上叠加短时间的流量尖峰 | 短时间释放大量令牌 | 秒杀/抢购场景模拟、弹性扩缩容验证 |
| 自适应调速 | 根据系统实时指标（RT/错误率）动态调整 QPS | PID控制算法闭环调节 | 自动化极限探索 |
| 混合调速 | 多种流量模式按时间线组合执行 | 编排引擎 + 时间线配置 | 复杂业务场景（日常+促销+秒杀叠加） |
📈 银行典型加压梯度设计
阶段 时间 目标TPS 持续时间 操作 ────────────────────────────────────────────────── 预热 00:00 10%峰值 5 min 检查系统各组件状态、数据隔离有效性 1级 00:05 20%峰值 10 min 观察资源使用率线性增长趋势 2级 00:15 40%峰值 15 min 关注数据库连接池、缓存命中率 3级 00:30 60%峰值 20 min 检查是否有慢SQL、GC频率变化 4级 00:50 80%峰值 25 min 重点监控响应时间P99、错误率 5级 01:15 100%峰值 30 min 核心业务指标验证、拐点确认 极限 01:45 120%峰值 15 min 可选：寻找系统容量天花板 冷却 02:00 梯度递减 10 min 逐步减压，观察系统恢复能力 总耗时：约 2 小时 10 分钟（不含准备和复盘）
4. 异常场景注入
全链路压测不仅要验证系统在正常负载下的表现，还要验证系统在异常场景下的韧性。 混沌工程（Chaos Engineering）的理念与全链路压测深度融合，形成「压力+故障」的双重验证。
💥 异常场景注入矩阵
| 异常类型 | 注入手段 | 预期验证点 | 银行场景示例 |
|---|---|---|---|
| 网络故障 | iptables/Tc 模拟网络延迟、丢包、断连 | 超时重试机制、连接池恢复能力 | 核心系统到支付网关的网络抖动下交易成功率 |
| 服务不可用 | Kill Pod/进程、摘除服务节点 | 熔断降级、故障转移、流量调度 | 风控服务宕机后交易是否自动降级放行 |
| 资源耗尽 | CPU满载/内存泄漏/磁盘满的模拟脚本 | 资源隔离、限流保护、OOM Kill行为 | 某节点CPU打满时其他节点是否承接流量 |
| 依赖超时 | Mock框架注入延迟响应 | 超时配置合理性、快速失败策略 | 核心调用支付网关超时3s时的用户体验 |
| 数据库故障 | 模拟主从切换、连接池满、慢查询 | 读写分离切换、连接池保护机制 | 主库故障时交易切换到备库的RTO/RPO |
5. 结果采集与比对
全链路压测产生海量数据，需要系统化的采集和智能比对机制，才能从中提炼出有意义的结论。
5.1 结果采集维度
📊 全链路结果采集矩阵
| 采集层次 | 核心指标 | 采集工具 | 存储方案 |
|---|---|---|---|
| 压测引擎层 | TPS、响应时间（P50/P90/P99/P999）、成功率、错误分布 | 压测平台内置采集 | InfluxDB / ClickHouse |
| 应用服务层 | 接口级别 TPS/RT、错误率、线程池状态、GC指标 | SkyWalking / Pinpoint / Micrometer | Elasticsearch / Prometheus |
| 中间件层 | 连接池状态、MQ积压、Redis命中率/QPS | Exporter + Prometheus | Prometheus TSDB |
| 数据库层 | QPS、慢SQL、连接数、锁等待、Buffer命中率 | Exporter + 慢查询日志 | Prometheus + ES |
| 基础设施层 | CPU、内存、磁盘IO、网络带宽、TCP连接数 | Node Exporter / cAdvisor | Prometheus TSDB |
| 业务层 | 业务成功率、资金准确性校验、对账结果 | 自定义业务监控 | 关系型数据库 |
5.2 智能比对机制
将本次压测结果与历史基线进行多维度对比，自动识别性能退化：
- 同场景纵向对比：本次 vs 上次同场景压测结果，识别性能退化趋势（如RT上升 > 20% 告警）
- 同版本横向对比：新版本 vs 旧版本在相同负载下的性能差异
- 生产基准对比：压测结果 vs 生产环境日常性能基线，判断压测环境偏差
- 多集群对比：不同机房/集群间的性能一致性校验
- SLO合规校验：压测结果 vs 预定义的SLO阈值（如P99 ≤ 200ms），不达标自动告警
✅ 结果分析最佳实践
银行场景下，全链路压测结果分析不能仅关注性能指标，还需要加入资金一致性校验。
压测结束后应对账：压测交易总金额、账户余额变化、流水记录三者是否一致，确保影子库的数据隔离没有影响生产数据。
6. 流量模拟工具对比
🔧 主流流量模拟工具全景对比
| 工具 | 类型 | 核心能力 | 适用场景 | 学习成本 | 社区活跃度 |
|---|---|---|---|---|---|
| JMeter | 通用压测引擎 | GUI脚本编写、分布式压测、丰富插件生态、支持多种协议 | HTTP/HTTPS、JDBC、JMS等协议的接口压测 | 低 | 极高 |
| Gatling | 代码化压测引擎 | Scala DSL编写场景、异步非阻塞架构、内置HTML报告 | HTTP协议的代码化压测、CI集成 | 中 | 高 |
| GoReplay (Gor) | 流量录制回放 | 实时捕获HTTP流量并回放、支持流量放大/缩小、实时流量过滤 | HTTP流量的在线录制和实时回放 | 低 | 高 |
| TCPCopy | TCP层流量复制 | 在线复制TCP层流量、支持请求拦截和修改 | TCP协议层的全协议流量复制 | 中高 | 中 |
| Locust | Python压测引擎 | Python脚本编写、分布式可扩展、Web管理界面 | Python技术栈的HTTP压测 | 低 | 高 |
| wrk2 / wrk | 轻量HTTP压测 | 恒定速率控制(wrk2)、极高的单机QPS、Lua脚本扩展 | 简单HTTP接口的快速压测 | 极低 | 高 |
| 阿里云PTS | 商业压测平台 | 可视化场景编排、云端施压、JMeter兼容、流量录制 | 企业级全链路压测（阿里云生态） | 低 | 中（商业产品） |
| 自研平台 | 定制化平台 | 完全按需定制、异构协议支持、内部系统深度集成 | 大型银行/金融企业的专属压测平台 | 极高 | 内部封闭 |
💡 银行工具选型建议
银行全链路压测工具选型通常采用「商业+开源+自研」的组合策略：
流量录制回放选用 GoReplay/TCPCopy 作为基础，压测引擎结合 JMeter（传统协议）+ Gatling（高QPS），
平台层以自研为主（满足合规、审批、审计等银行特有需求），监控采集集成 SkyWalking + Prometheus 开源方案。
关键原则是：核心链路（资金交易）用最成熟的方案，外围链路可逐步引入新技术。