性能要求必须带上负载与时间

“接口要在一秒内返回”缺少负载、数据量和统计口径，无法指导架构。性能描述的是系统在特定资源和工作负载下处理事件的时间与能力。延迟、吞吐、并发和资源消耗互相关联，需要在同一个场景中观察。

工作负载决定指标含义

负载模型应说明请求类型、到达速率、并发方式、数据分布和突发行为。平均每秒一百次请求，可能均匀到达，也可能集中在几秒内；读取小对象与上传大影像对系统的压力完全不同。

测试数据规模也会改变结果。数据库只有几千行时的查询延迟，不能代表数亿行与长期索引膨胀后的行为。性能基线应记录软件版本、部署资源和数据状态。

平均延迟会掩盖少量非常慢的请求。面向用户或级联服务时，分位数更能描述尾部体验。一次页面加载需要多个后端请求，其中任一请求的尾部延迟都可能拖慢整体响应。

测量边界同样重要。服务端处理时间可能不包含排队、网络和客户端渲染；用户感知时间则包含完整路径。指标名称应明确从哪里开始、在哪里结束。

吞吐表示单位时间完成的工作量，容量表示在满足质量目标的前提下可承受的最大负载。当系统接近饱和，队列增长会使延迟迅速增加，即使处理吞吐暂时没有下降。

增加线程或副本不一定线性提高容量。共享数据库、锁、网络带宽和外部服务会成为瓶颈，协调开销也会随规模增长。容量规划需要识别限制资源，并保留突发和故障期间的余量。

缓存减少重复计算和远程读取，但需要命中率、失效和一致性策略；异步队列可以平滑突发，却改变结果可见时间；批处理提高吞吐，可能增加单项等待。每种机制都应对应明确的性能场景。

优化前先取得剖析证据。把复杂度转移到不是瓶颈的模块，会增加维护成本而没有可测收益。性能测试应同时收集 CPU、内存、I/O、队列、数据库等待和外部调用等信号。

一条可验收要求可以写明：在指定数据规模和硬件下，当某类请求以规定速率到达时，某一分位延迟不超过阈值，错误率和资源水位保持在边界内。阈值应来自业务需要和成本权衡，本页不提供跨系统通用数字。

SEI 的质量属性方法把负载、环境、响应和度量放入场景，使架构决定能够被分析。早期分析给出风险假设，上线后的持续测量负责验证这些假设。

Carnegie Mellon Software Engineering Institute：Reasoning About Software Quality Attributes，https://www.sei.cmu.edu/library/reasoning-about-software-quality-attributes/
Carnegie Mellon Software Engineering Institute：Early Analysis of Software Architecture，https://www.sei.cmu.edu/library/early-analysis-of-software-architecture/