一、性能五模型的定义与全链路压测中的变化

性能项目中的模型可以归纳为五类：业务模型、容量模型、监控模型、分析模型、异常（失效）模型。五个模型各自解决不同的问题：- 业务模型：确定压力工具中的业务比例配置- 容量模型：确定系统设计容量的计算方式- 监控模型：确定需要监控的计数器范围- 分析模型：确定性能问题的分析路径- 异常模型：确定异常场景的设计方式全链路压测与普通压测在模型分类上没有区别，主要差异是：由于全链路压测在线上执行，对微服务、缓存、队列、数据库做了改造（影子库等），每个模型都需要额外覆盖改造后新增的组件。—## 二、业务模型：目标决定手段业务模型的核心是将真实场景的业务比例复制或推算出来，关键在于先明确测试目标。手段一：线上流量复制。直接录制生产流量并回放，业务比例天然与生产一致。适用场景：目标是复现历史容量峰值场景。局限：录制的流量代表的是历史某一时段的业务比例，无法代表未来业务模型的变化。手段二：统计线上流量后用压力工具模拟。通过统计各接口的调用比例，在压力工具中按比例配置并发。只要业务比例与生产一致，压测结果与流量回放没有本质区别。适用场景：目标是推算未来容量峰值场景（例如业务部门预测某类交易比例会增加），此时只能通过压力工具调整比例来实现，流量回放无法满足。两种手段的选择标准：复现历史场景用流量回放，推算未来场景用压力工具模拟。—## 三、容量模型：不能线性计算，要用递增测试建模容量模型的目标是在压测执行前估算系统能支撑的容量上限，并规划扩容所需资源。以一个典型配置为例：微服务应用使用 40C80G 资源，支撑混合场景 1500TPS 时硬件已饱和；此时数据库（8C16G × 2）CPU 使用率约 50%，缓存和队列（4C8G × 2）CPU 使用率约 20%，网关（4C8G × 2）CPU 使用率约 40%。如果目标是支撑 3000TPS，不能直接线性计算。原因有两个：第一，数据库资源并未饱和，但当压力增加时，数据库响应变慢会导致 TPS 无法线性增长；第二，微服务应用节点增加会带来服务间远程调用的网络带宽增加，同时加重网关和负载均衡的压力，这些都是非线性因素。正确做法是递增加压，实测建模。按 1500 → 2000 → 2500 → 3000 TPS 逐步加压，记录每个阶段各组件的资源增长率，得到实际的容量增长曲线。通过实测数据可以发现：TPS 越高，微服务应用和数据库的资源增幅越大，成本越高；而缓存和队列由于未达到使用上限，在一定范围内不需要扩容。容量规划的结论必须来自真实测试数据，而不是理论线性推算。—## 四、监控模型：覆盖全量计数器监控模型的建立分两步：第一步：为每个技术组件创建性能分析决策树。针对网关、微服务应用（Java）、数据库（MySQL）、缓存（Redis）、消息队列（RabbitMQ）分别建树，列出各组件的模块和对应计数器。Java 应用的决策树关键模块：JVM 堆内存（各代使用率、GC 频率和耗时）、线程（总数、各状态分布、线程池队列积压）、类加载、CPU 使用率。MySQL 的决策树关键模块：查询和排序（慢查询数、全表扫描数）、InnoDB 锁（锁等待数、死锁数）、InnoDB 缓冲池（命中率、脏页比例、读写 IOPS）、连接数。第二步：将决策树中的计数器映射到监控工具。检查 Prometheus + Grafana 等监控工具的 Dashboard 是否覆盖了决策树中的所有计数器，缺少的需要补充自定义面板或通过命令行工具补充。云厂商提供的默认监控视图通常不完整，不能依赖厂商视图替代自建的监控模型。全链路压测中，监控模型相比普通压测的增量：新增了影子数据库节点的监控，其余组件的监控逻辑与普通压测完全一致。—## 五、分析模型：建立计数器到解决方案的分析路径分析模型是在监控模型基础上，为每个关键计数器建立分析路径。以几个典型场景为例：数据库查询和排序类问题：分析查询类型 → 统计具体 SQL 语句 → 查看执行计划和 Profiling 信息 → 分析业务逻辑 → 提出解决方案。InnoDB 锁问题：分析锁信息 → 统计具体 SQL 语句 → 查看执行计划和 Profiling 信息 → 分析业务逻辑 → 提出解决方案。InnoDB 缓冲池问题：分析缓存使用率 → 分析内存读写与磁盘读写比例 → 分析 SQL 类型 → 提出解决方案。注意：缓冲池分析需要与查询排序分析关联，两者之间有依赖关系。Java 线程池问题：分析所有线程状态 → 确定繁忙程度和是否阻塞 → 分析栈信息 → 提出解决方案。线程状态分析需要结合 CPU 使用率，两者关联分析。分析模型的质量取决于技术功底，单人难以覆盖所有技术栈，建议以团队协作方式完成。—## 六、异常模型：必须基于真实缺陷设计异常模型的核心原则是真实性——模拟的异常必须与生产环境中实际出现的故障一致，否则测试结果没有参考价值。常见的混沌工程工具（如 ChaosBlade-Operator）模拟 CPU 高使用率的方式是启动一个独立进程消耗 CPU，但生产环境中 CPU 高的问题通常是应用进程内部的性能缺陷导致的，两者的表现形式和影响范围完全不同。正确的异常模型设计方法：整理生产环境中实际出现过的问题，分析根因，将对应的缺陷实现到异常模型中。例如，某个方法因算法低效导致 CPU 长期消耗，可以将性能差的代码打包到应用中通过开关触发，或通过 Java Agent 将代码注入到正在运行的进程中。异常场景的测试点数量与节点数量成乘法关系（每个节点 × 每类异常类型），完整覆盖的成本极高，建议优先覆盖生产环境中出现频率高、影响范围大的异常类型，而不是追求全量覆盖。全链路压测性能五模型：业务、容量、监控、分析、异常的完整建模方法删除线格式