容量规划是业务、系统、成本的动态校准，需从理解脉冲型流量出发，识别链路短板，按副本/预留/倾斜三重折扣算存储，以滚动验证替代一次性预测。

容量规划不是算术题，而是业务、系统、成本三者之间的动态校准。很多人一上来就列公式、堆监控指标，结果上线后发现预测偏差超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分自动告警并推送优化建议