容量规划是业务、系统、成本的动态校准，需从理解脉冲型流量出发，识别链路短板，按副本/预留/倾斜三重折扣算存储，以滚动验证替代一次性预测。
容量规划不是算术题，而是业务、系统、成本三者之间的动态校准。很多人一上来就列公式、堆监控指标，结果上线后发现预测偏差超40%，或者扩容刚完成，成本就超标。真正有效的容量规划，得从理解业务脉冲开始，再落到每个组件的承载边界，最后用数据闭环验证。
先读懂业务流量的真实形状
不能只看平均QPS。电商大促、视频点播、日志归档这些场景，流量都是脉冲型的——高峰可能比均值高5倍，但持续时间不到10分钟。光靠“日均×1.5”来预估，大概率低估峰值压力。
- 用全链路日志或APM工具（如SkyWalking、Jaeger）提取真实请求时间戳，聚合出小时级/分钟级的流量热力图
- 区分读写比例：读多写少的服务，缓存和CDN能扛掉70%+流量；写密集型服务（如订单创建），数据库和消息队列才是瓶颈入口
- 识别“伪高峰”：比如凌晨2点批量ETL任务触发的CPU尖刺，它不反映用户行为，但会吃掉计算资源，需单独建模
拆解系统链路，找到真正的容量短板
系统容量不是所有组件容量之和，而是最短那块板决定的。加了3台应用服务器，结果MySQL连接池满、Redis内存打爆、对象存储PUT并发超限——扩容反而放大故障面。
- 画一张端到端链路图：客户端 → LB → API网关 → 微服务 → 缓存 → 消息队列 → 数据库 → 对象存储/块存储
- 对每个环节标注当前实测上限：比如MySQL单实例建议连接数≤120，Kafka单分区吞吐≤10MB/s，S3 PUT并发建议≤200 req/s
- 重点盯住有状态组件：数据库、ZooKeeper、Nacos、HDFS NameNode——它们横向扩展难、升级窗口小、故障影响广
存储容量要算“三重折扣”
原始磁盘容量 ≠ 可用业务容量。HDFS、FusionStorage、aStor-EDS这类分布式存储，实际可用空间要连打三次折。
- 副本/纠删码折扣：副本因子3 → 原始容量÷3；EC 8+3 → 原始容量×8÷11 ≈ 73%
- 预留空间折扣：系统日志、快照、临时文件、JVM堆外缓存通常占5%~15%，生产环境建议按10%预留
- 数据倾斜折扣：HDFS中单节点磁盘使用率超过80%，就会触发balance阻塞；FusionStorage池内各节点实际利用率偏差＞15%，说明分布策略或热点未收敛
用滚动验证代替一次性预测
不做“一锤定音”的年度容量计划。把容量决策变成可度量、可回滚的运营动作。
- 每季度做一次“容量快照”：采集近30天核心指标P95值，对比上期变化率，超15%就触发复核
- 新业务上线前必须跑基线压测：不是测能不能跑通，而是测在目标QPS下，各组件的资源水位（CPU、内存、连接数、IOPS）是否在安全阈值内
- 建立容量健康分：给每个服务配置权重（如数据库权重0.4、缓存0.25、网络带宽0.15），按实时水位动态打分，低于60分自动告警并推送优化建议
