-
前言：为什么“容量评估”是决定系统能否活下去的核心能力？
- 系统崩溃不是因为坏
- 是因为 超出容量却无人知晓
- 容量规划是大厂 SRE/架构的核心任务之一
-
容量评估的三大核心指标
- 吞吐（Throughput）
- 延迟（Latency）
- 资源占用（CPU / 内存 / IOPS / 连接数）
-
企业级容量评估模型（黄金四步）
- 测量（Measure） ：真实流量画像、峰值 QPS、热点路径
- 建模（Model） ：每个服务的容量曲线
- 预测（Forecast） ：大促、活动、增长率预测
- 决策（Plan） ：扩容策略、预案、阈值
-
容量建模（最难也最关键）
- 线性模型 vs 多段模型
- 瓶颈识别（CPU-bound、IO-bound、DB-bound）
- “软上限”和“硬上限”概念
- 如何用压测数据拟合实际容量曲线
-
容量评估必备工具链
- APM（Skywalking / Jaeger）
- Prometheus + Grafana
- k6 / JMeter / Locust
- 实时热点分析
-
服务链路容量分析（全链路）
- 入口网关 → 应用服务 → DB → Redis → MQ
- 如何计算每一环的容量余量？
-
企业真实案例：双 11 大促容量规划
- 压测 → 瓶颈发现 → RT 建模
- 重点链路“弱点强化”（Redis 热 key）
- 最终稳定支撑百倍流量
-
总结
- 高可用不是“扛住了”
- 高可用是 “提前知道能扛住多少、哪里扛不住、怎么扛住”
