Day07-10｜2.9.4 性能评估：用测试、模型和生产证据验证架构目标

教材定位：系统架构设计师教程（第 2 版）第 2 章“计算机系统基础知识”第 2.9.4 节。

学习目标：理解性能评估的目的、原则、对象、方法和过程；掌握基准测试、负载测试、压力测试、容量测试、稳定性测试、并发测试和性能监控的区别；能够设计有代表性的性能评估方案，分析测试结果，定位瓶颈，并在案例题和论文中形成可验证的性能闭环。

一、性能评估不是只跑一次压测

性能评估是通过测量、分析、建模、对比和持续监控，判断系统是否满足性能目标，并为优化和容量决策提供证据。它既可以发生在架构设计阶段，也可以发生在开发、集成、上线、运行和扩容阶段。

一次压测结果不能代表系统全部性能。测试环境可能与生产不同，负载模型可能不真实，数据规模可能过小，缓存可能处于热状态，测试时间可能不足，监控指标也可能不完整。因此性能评估必须说明对象、场景、负载、环境、方法、指标、结果和限制条件。

二、性能评估的基本过程

第一步是明确业务目标和验收指标。指标应包含场景、负载、数据、环境、统计方式、目标和持续时间。第二步是建立性能模型，描述用户行为、请求比例、到达规律、峰值系数、数据增长和故障条件。第三步是准备生产等效环境和数据。第四步选择工具、脚本、监控和测试策略。第五步逐步加压并观察系统。第六步分析瓶颈和结果，形成优化与复测闭环。

性能评估应先小规模校验脚本和数据，再进行阶梯加压。直接一次性冲到最大并发，可能把脚本错误、环境问题和真实瓶颈混在一起。每个阶段应保留基线，记录开始时间、版本、配置、数据、流量、结果和异常。

三、测试场景与负载模型

真实负载不是一个固定数字，而是用户、请求类型、数据规模和时间变化的组合。在线交易可能有查询、创建、支付、取消和退款等不同操作；消息系统可能有不同消息大小、消费速度和失败比例；媒体系统可能有不同清晰度和观看时长。

负载模型至少要说明并发用户、到达率、请求比例、思考时间、请求大小、数据量、热点分布、持续时间和峰值变化。闭合模型把固定数量用户循环执行任务；开放模型按外部到达率持续产生请求。两者适用场景不同，不能把一个模型的结果直接替代另一个模型。

测试数据要具有代表性。数据量过小会让索引、缓存和内存表现过于理想；数据分布过于平均会掩盖热点；全部使用相同用户会忽视权限和会话；测试数据与生产数据混用还可能造成安全和合规风险。应使用脱敏数据、合成数据和明确的数据清理策略。

四、指标采集与结果分析

性能评估要同时采集业务、应用、依赖和基础设施指标。业务层关注成功率、完成量、订单状态和数据正确性；应用层关注响应分位数、吞吐、线程池、连接池、GC、错误和队列；依赖层关注数据库、缓存、消息、外部服务和 CDN；基础设施层关注 CPU、内存、磁盘、网络和容器资源。

结果分析要比较目标、基线和不同版本，不能只看一张平均响应曲线。应观察随负载增加的响应、吞吐、错误和资源变化，识别线性区、饱和区和失效区。稳定容量通常位于满足质量目标且具有安全余量的区域，而不是极限崩溃点。

五、基准测试与组件评估

基准测试用于比较算法、数据库、序列化方式、缓存策略、网络协议或硬件配置。基准必须控制变量，保持数据、输入、编译参数、环境和测试时间一致。单项基准的优势不一定在端到端场景中成立，例如序列化更快但消息更大，压缩率更高但 CPU 更重。

组件基准应围绕真实工作负载设计。数据库要比较查询类型、数据量、索引、读写比例和事务；消息系统要比较消息大小、批量、确认和副本；缓存要比较命中、失效、热点和网络。基准结果应记录方差和重复次数，避免偶然值成为架构结论。

六、负载、压力、容量和稳定性测试

负载测试在预期或设计负载下验证系统是否满足目标；压力测试逐步超过设计负载，观察系统怎样退化、怎样失败以及能否恢复；容量测试寻找满足响应、错误和资源约束的最大负载；稳定性测试在较长时间运行，发现泄漏、碎片、积压、缓存增长和资源漂移。

压力测试的价值不只是“把系统压垮”，还要观察故障是否可控。例如是否限流、是否返回明确错误、是否保护数据库、是否产生重试风暴、是否能够清理队列、是否能在负载下降后恢复。高质量系统即使不能承载无限流量，也应优雅退化并可恢复。

七、性能评估中的建模与仿真

在系统尚未完成时，可以使用排队模型、容量模型、离散事件仿真、原型和历史数据预测性能。模型适合比较方案和估算趋势，能够提前发现线程、连接、带宽和存储不足。仿真结果依赖假设，必须通过真实测试校准。

模型使用时要记录参数来源、适用范围和误差。把实验室测得的单节点吞吐直接线性外推到百节点集群，可能忽略网络、协调、数据倾斜和共享依赖。评估报告要说明哪些是测量值，哪些是推断值，哪些仍需现场验证。

八、故障场景与性能恢复

性能评估不应只测试正常状态。需要加入节点故障、网络延迟、丢包、数据库慢查询、缓存失效、消息积压、外部服务超时、磁盘空间不足和发布变更等场景，观察系统性能目标和可用性如何变化。

故障场景应有明确的注入方式、持续时间、停止条件和恢复验证。测试结束后检查数据完整性、队列、连接、缓存、告警、自动恢复和人工操作。性能恢复不仅是 CPU 降下来，还要看业务成功率、尾延迟和积压是否回到基线。

九、案例：银行批量结算系统评估

某银行夜间结算系统要求两小时内完成 5000 万笔记录，失败记录必须可重试且不能重复记账。团队在小数据集上测试通过，但生产批处理超时。

问题可能来自数据规模、索引、日志、锁、磁盘、批量提交、并行度和失败重试设计。评估应使用生产等效数据量和分布，分别测量读取、计算、写入、日志、提交和校验阶段；比较不同批大小、并发度和分片策略；注入节点故障、数据库慢写和重复执行，验证幂等和恢复。

架构改进可以按业务键分片并行处理，控制每个分片的事务范围，使用批量 I/O 和合适索引，将非核心报表与结算隔离；通过任务状态、检查点和幂等键支持断点续跑；对数据库、磁盘和消息设置容量监控。验收不只看完成时间，还要看金额对账、重复率、失败恢复时间和资源峰值。

十、案例：微服务压测结果异常

某微服务压测时吞吐达到目标，但 P99 持续上升，消息积压不断增加，CPU 只有 50%。分析可知有效完成率可能低于到达率，系统通过排队隐藏了处理不足；瓶颈可能在数据库锁、外部依赖、连接池或消费者并发，而非 CPU。

排查应比较生产速率和消费速率，查看最老消息年龄、消费者等待、数据库锁、连接池、外部调用和 trace；确认压测脚本是否把入队当作业务完成；检查重试和重复消息是否放大流量。修复后要以业务完成为吞吐定义，验证积压清空时间、P99、错误率和数据正确性。

十一、练习与详细答案

1. 负载测试和压力测试有什么区别？
2. 为什么性能测试必须使用有代表性的数据？
3. P99 达标但消息积压增加，能否判定性能达标？
4. 稳定容量为什么不是系统崩溃时的最大吞吐？
5. 性能评估报告必须包含哪些内容？

答案：1. 负载测试验证预期负载下是否满足目标，压力测试超过设计负载观察极限、退化和恢复；2. 数据规模和分布会影响索引、缓存、内存、锁和 I/O，数据不真实会得到错误结论；3. 不能，积压说明到达率超过有效处理率或完成定义有误，应同时检查吞吐、队列、完成率和延迟；4. 崩溃点没有质量和安全余量，稳定容量应满足目标、可持续运行并能承受波动和故障；5. 应包含目标、范围、版本配置、环境、数据、负载模型、工具、指标、结果、瓶颈、限制、结论、优化建议和复测证据。

案例题：某系统压测报告只写“并发 1 万、响应 100 毫秒”，上线后用户体验差。请指出报告缺陷并提出改进。

参考答案：报告缺少请求类型和比例、到达率、数据规模、成功率、分位数、测试持续时间、环境配置、依赖状态、资源指标和完成定义；100 毫秒可能只是平均值或客户端发起到入队的时间。应建立真实场景和生产等效数据，明确 P95/P99、有效吞吐、错误率、队列、资源和业务成功率，分阶段加压并持续运行；接入端到端追踪，覆盖缓存冷/热、热点、数据库、外部依赖和故障场景；根据瓶颈优化后在同版本、同数据和同负载下复测，形成可审计证据。

十二、论文素材与复盘

论文中写性能评估，可按“目标定义—模型准备—环境和数据—分阶段测试—监控分析—瓶颈定位—优化复测—生产观察”展开。要写清负载模型、P95/P99、有效吞吐、错误率、资源、队列和业务正确性，并说明压力和故障场景下的退化、恢复和回滚。

今日核心记忆句：性能评估是证据链，不是单次压测；先定义目标和模型，再准备等效环境与数据；正常负载看是否达标，压力测试看如何失败，容量测试找稳定上限，稳定性测试看长期退化；结果必须结合业务完成、尾延迟、队列、资源和数据正确性分析。