每请求成本
告诉你架构是否财务可扩展（而非仅技术）的单位经济指标。
为什么
能扛 10 倍流量的架构若也贵 10 倍就没用。每请求成本（月总成本 ÷ 服务请求）是抓超线性成本曲线架构的指标——如随规模变主导成本的每请求数据库查询。设计时追踪 CPR 让你否掉技术可扩展但财务不可行的架构，这是比技术宕机杀更多初创的失败模式。CPR 随流量增长保持平直是好设计系统的标志。
何时使用
容量规划时及之后每月。30 分钟算出。仅对无增长期望的内部工具可跳过。
如何做
1. 月总成本（来自成本模型或真实账单） 2. 服务总请求（来自分析/CDN 日志，p50 月） 3. CPR = 总成本 ÷ 总请求 4. 在 1 倍、10 倍、100 倍当前负载算 CPR——是否保持平直？ - 若 CPR 上升，找超线性组件（DB 查询、出口、锁） 5. 设 CPR 预算（如"$0.002/请求"）并超时告警 6. 跨架构备选比 CPR——最平曲线胜
示例
API 服务 1000 万请求/月，总成本 $4,000/月 → CPR = $0.0004 10 倍（1 亿请求）： - 计算线性扩展：$40,000 - 但 DB 连接池饱和 → 加读副本：+$8,000 - 出口 10 倍：+$18,000 - 合计 $66,000 → CPR = $0.00066（上升——不平） 诊断：出口 + DB 副本超线性。 修复：加缓存层（Redis）→ 70% 读命中 → CPR 回 $0.00042。
常见问题
- ⚠只在当前负载算 CPR——看着行，却漏掉 10 倍时让你破产的超线性组件。
最佳实践
- ✓在 log-log 图上画 CPR vs 负载——平直线是目标；任何上弯是财务扩展 bug。
- ✓把 CPR 绑定价——若产品收 $0.001/请求而 CPR $0.0008，毛利 20% 且脆弱；目标 5 倍比。