云上资源越来越多，容量问题已经不只是运维的事。大促流量冲上来、新业务上线、季节性起伏，哪一环判断错了，轻则接口变慢，重则服务降级。另一头，没人用的机器还在持续扣费。阿里云容量规划要做的，说到底就是在性能、稳定性和成本之间找一个能接受的平衡点。
阿里云容量到底指什么
阿里云容量一般指云上计算、存储、网络和数据库等资源能提供的规模和配置上限。单台ECS的CPU、内存、带宽是一层，地域、可用区、账号配额又是另一层。不少团队项目刚起步时只关心能不能跑起来，没想过能撑多少用户，等业务涨上来才发现卡点出在完全没料到的地方。
容量没规划好，通常会在三处体现：
- 稳定性：资源吃紧时，响应变慢、超时，严重时直接宕机。
- 成本：预留太多，闲置就是每月固定的支出；预留太少，临时加机器的代价往往更高。
- 节奏：容量心里有数，扩容就能提前排期，不必在大促前一天四处抢资源。
容量评估怎么做
先看业务，别先看机器
评估从业务指标开始。日活、峰值并发、订单量、接口调用量，这些数字要先拉出来。比如一个电商小程序日活20万，活动时瞬时并发大约是平时的8倍，那规划就该按这个峰值来做。如果只按平均值配置，活动一开场就会被打穿。
压测拿到单机基线
知道业务要多少，还得知道一台实例能扛多少。用压测工具模拟真实流量，记录不同负载下的CPU使用率、响应时间和错误率，单机的性能基线就出来了。一般会把CPU 70%左右当作安全水位，过了这条线就该考虑扩容，否则突发流量来了连缓冲都没有。
算总量，再留余量
峰值请求量除以单机承载能力，再乘上冗余系数，就是需要的实例数。假设峰值每秒8000次请求，单机稳定承载1000次，按70%水位算，单机实际只能放约700次，那就需要12台左右。如果还要跨可用区部署，要保证单个可用区故障后，留下的实例数量仍能扛住业务，这通常意味着整体规模还要再往上加。
阿里云上的常用工具
容量工具不少，单用一个往往不够，组合起来才顺手。
弹性伸缩
弹性伸缩能按CPU、内存或自定义指标自动增减ECS数量。流量波动明显的业务最适合用，比如在线教育的晚高峰，或者外卖平台的午晚餐时段。规则要同时配最小和最大实例数，最大值别拍脑袋定。还有一点容易忽略：新实例从创建到真正接住流量，通常要几分钟。触发线设得太晚，扩容就赶不上流量。
云监控与告警
云监控能采集ECS、RDS、SLB等资源的指标。容量相关的指标最好放进同一个看板，CPU、内存、磁盘、连接数都设多级阈值。比如CPU连续5分钟超过70%先发预警，超过85%再触发自动扩容。这样值班的同学还有时间判断，是真的流量涨了，还是某个进程失控。
预留实例与节省计划
长期稳定运行的核心业务，可以用预留实例券或节省计划压低单价。比如一个跑了一年以上的数据库集群，负载基本平稳，包年包月或预留方案一般能省下不少钱。购买前先用监控数据确认基础负载，再决定买多少。买多了，就是另一种浪费。
一个典型的规划过程
某本地生活服务平台每年年货节前都会遇到订单激增。以前主要靠经验估算，结果有两次因为数据库连接数不够，下单直接失败。之后他们改了做法：
- 复盘历史大促，整理近三年的峰值订单量，以及对应的数据库QPS。
- 订单服务和数据库分别压测，发现瓶颈在连接数，CPU反而还有余量。
- 把RDS最大连接数纳入容量指标，同时用连接池降低每个请求占用的连接。
- 大促前两周完成扩容评审，给弹性伸缩设好最大实例上限，并安排一次演练。
当年年货节期间系统平稳，资源利用率也在合理范围内，没有再出现连接数耗尽导致的下单异常。这个例子说明，容量出问题的地方常常不是最显眼的CPU。先找到真正的瓶颈，比一味加机器有用。
常见的坑
- 只盯平均值：平均负载会把峰值压力藏起来，规划要看峰值和分位数。
- 忘了依赖组件：应用扩了，数据库、缓存、消息队列如果没一起评估，很快就会成为新瓶颈。
- 配额没提前申请：ECS实例数、公网带宽这些配额都有上限，大促前就要和云服务商确认，需要的话提前申请提升。
- 扩容和回滚没演练：流程没试过，真出事的时候只能手忙脚乱。
持续调整，而不是一次做完
阿里云容量管理不是做一次就完事的工作。业务指标、压测基线、伸缩规则都会随业务变化，需要定期回看。每次大促、每次故障，都值得拿来修正容量模型。把这些记录留下来，下次评估就有据可依，云上资源才能既够用，又不白白浪费。
