性能预算怎么分配
性能预算把端到端延迟目标拆成各环节的额度：网关多少、每个服务多少、数据库与外部依赖各多少，并留出一块余量应对波动与重试。它的作用是防止“逐项小幅劣化”累积超标——每个团队都觉得自己只慢了几毫秒，合起来就突破了整体目标。预算要进入变更流程：引入新依赖或新环节时，必须申明消耗多少额度并说明余量是否还够。
基本信息
| 分解对象 | 网关、各服务、数据库、外部依赖，以及重试与序列化开销 |
|---|---|
| 余量 | 总预算的 10%~20% 用于吸收波动与重试 |
| 口径 | 按分位（P99）分解，而不是按平均耗时 |
| 载体 | 预算表随架构文档或 ADR 维护，并被监控看板引用 |
典型使用场景
- 多团队协作的服务链路：为每个环节设额度，避免单方优化目标不一致
- 新依赖评审：评估引入后剩余预算是否仍能满足端到端目标
- 延迟问题归因：对照预算表找出哪个环节超支最严重
- 容量规划：按各段预算推断资源需求与扩缩容优先级
- 架构演进：拆分或合并服务时重新分配预算并复评
示例
示例
端到端目标 P99 ≤ 500ms
网关 30ms + 服务 A 120ms + 服务 B 150ms
+ 数据库 100ms + 外部依赖 60ms + 余量 40ms预算表维护要点
| 项 | 要做的事 | 常见遗漏 |
|---|---|---|
| 分位口径 | 各段统一用 P99 或统一用同一分位 | 各团队口径不一，数字无法相加 |
| 重试开销 | 在预算里体现重试带来的额外往返 | 只算单次调用，实际重试后超支 |
| 余量管理 | 明确余量归属，谁动用谁记录 | 余量被多个环节悄悄挪用后耗尽 |
| 超支处理 | 超支环节列入治理清单并跟踪进度 | 发现超支但无人认领，长期挂在表里 |
落地做法
- 按端到端目标逐层拆解：网关、各服务、数据库、外部依赖
- 每层预留余量（如总预算的 10%–20%）应对波动与重试
- 新增依赖必须申明消耗额度，评审剩余余量是否足够
- 在链路追踪中标注各段实际耗时，与预算表定期对照
- 超支环节列入治理清单，避免长期挪用别的环节余量
预算表要进变更流程：引入新依赖时必须申明消耗多少预算并说明余量是否足够，否则预算会变成事后解释而不是事前约束。
各环节用不同分位口径（有人用 P95、有人用 P99）会让预算表失去可加性：数字看起来都达标，端到端仍可能大幅超标。