"业务卡了，加台机器吧"——这句话在很多团队几乎是条件反射。但扩容是一笔持续的开支，加错了不仅浪费钱，还可能掩盖真正的问题（比如一个慢查询、一把全局锁，加再多机器也治不好）。反过来，该扩不扩，高峰期被打挂，损失更大。所以扩容的关键，是用数据判断"到底该不该扩、扩多少、怎么扩"。
这篇文章给一份扩容前的评估清单：先看哪些核心指标、指标到什么水位才算该扩、怎么区分"该扩容"还是"该优化"、成本怎么测算、纵向和横向怎么选，最后给一套理性扩容的决策流程。文中阈值和倍数为经验值，务必用你自己业务的实际数据校准。
一、扩容前先想清楚三件事
- 现在是哪一项到瓶颈了？ 是 CPU、内存、磁盘、网络，还是应用自身（锁、慢查询、GC）？扩错方向等于白花钱。
- 是真瓶颈还是能优化掉？ 很多"容量不足"其实是配置问题或代码问题，优化成本远低于扩容。
- 扩多少、扩完能撑多久？ 按当前增长趋势估算，避免刚扩完又不够，或大幅闲置。
没有这三个答案就下单买机器，十有八九是浪费。
二、扩容前要评估的核心指标
下面这张表是评估清单，按"资源层"和"业务层"分组：
| 类别 | 指标 | 观察方式 | 经验水位 |
|---|---|---|---|
| CPU | 整体与峰值利用率 | top、mpstat、监控 | 峰值持续 > 60%~70% 警惕 |
| 内存 | 使用率、swap 使用 | free、vmstat | 持续 > 70%~80%，swap 在用 |
| 磁盘 | 空间利用率 | df | > 70%~80% 需处理 |
| 磁盘 | 性能：await、%util、IOPS | iostat | await 明显升高、%util 近 100% |
| 网络 | 带宽利用率、丢包重传 | sar、ss、监控 | 持续 > 70% 购买带宽 |
| 业务 | QPS 余量 | 压测 + 监控 | 峰值吃掉可承载能力的 > 70% |
| 业务 | P95 / P99 响应时间 | 应用监控 | 超过 SLO 即告警 |
| 业务 | 并发连接数 | ss、应用监控 | 接近连接上限或增长过快 |
| 业务 | 错误率（5xx、超时） | 应用监控 | 抬头就要查，持续升高要扩 |
关键不是单个指标超标就扩，而是"多项指标同时接近水位、且呈上升趋势"。 单看 CPU 60% 就扩，容易过度配置；多个指标一起顶到边，才是真需要扩容。
三、怎么读这些指标：看水位，更看趋势
- 看水位：当前离上限还有多少余量。经验上，生产环境长期跑在 70% 以上就该考虑扩容，因为突发流量、故障转移（少了机器）、大促都会让使用率瞬间抬高。
- 看趋势：是平稳、还是持续上升？如果利用率每周爬高几个百分点，即使现在只有 50%，也要提前规划——按趋势很快就会到顶。
- 看峰值而非均值：业务有高峰低谷，均值 30%、峰值 90%，一样是危险的。评估必须看业务高峰时段的数据。
- 看长尾：P99 响应时间涨了，说明最慢的那部分用户已经受影响，比平均 QPS 更能反映问题。
四、区分"该扩容"和"该优化"
这是最容易搞错的一步。在决定加机器前，先排除能被优化掉的问题。
| 现象 | 更可能是 | 优先动作 |
|---|---|---|
| CPU 高、热点集中 | 代码/算法低效 | 优化热点，未必扩 |
| CPU 高、业务量真涨 | 容量不足 | 扩容 |
| 内存高、有内存泄漏 | 代码缺陷 | 修复泄漏，别急着加内存 |
| 内存高、缓存设计合理 | 容量不足 | 扩容 |
| 磁盘 %util 高、慢查询多 | 查询/索引问题 | 优化 SQL 与索引 |
| 磁盘 %util 高、写入量真大 | 容量不足 | 扩容或换更快盘 |
| QPS 不涨、CPU 也不高 | 锁竞争/下游瓶颈 | 优化代码或下游 |
| 响应时间随并发非线性上升 | 排队/锁/连接池 | 调参优化 |
| 多项指标随流量线性上升 | 真实容量不足 | 扩容 |
判断口诀：如果瓶颈集中在某个可控点（某条 SQL、某个锁、某个低效函数），先优化；如果所有资源都随流量均匀逼近上限，那才是真容量不足，需要扩容。
优化的性价比通常更高：优化一条慢查询，可能顶得过好几台机器。
五、成本测算
扩容决策必须算钱。核心指标是"每 QPS 成本"：
每 QPS 月成本 ≈ 单机（或整体）月成本 ÷ 可支撑 QPS
用它做几件事：
- 比较方案：一台高配机 vs 多台低配机，谁每 QPS 成本低？
- 算增量成本：业务 QPS 要涨 50%，需要多花多少钱？
- 比较"优化"和"扩容"：投入人力优化某个热点，能省下几台机器、几个月回本？
- 定预算：按增长预测，提前估出未来半年的扩容预算。
测算时要算全成本，别漏项：
- 计算资源（机器/实例）费用。
- 带宽费用（尤其大流量业务，带宽可能比机器还贵）。
- 存储费用（数据盘、备份、快照）。
- 负载均衡、CDN、对象存储等配套。
- 监控、日志、运维人力。
六、纵向扩容 vs 横向扩容
| 维度 | 纵向扩容（换更强单机） | 横向扩容（加更多机器） |
|---|---|---|
| 做法 | 加 CPU/内存/换更快的盘 | 增加实例，靠负载均衡分摊 |
| 优点 | 改动小、见效快、无分布式复杂度 | 弹性好、可高可用、理论上限高 |
| 缺点 | 有单机上限、成本非线性上升、仍单点 | 需要无状态化、分布式改造、运维成本 |
| 适合 | 单机未到上限、快速应急、有状态单点 | 流量大且增长快、要求高可用 |
选择建议：
- 短期应急、单机还有空间：先纵向，快速缓解。
- 长期、增长快、要高可用：走横向，让应用无状态化，靠负载均衡扩展。
- 有状态服务（如数据库）：纵向更常见，横向要靠分库分表、读写分离，复杂度高。
多数互联网业务的终局是横向扩展，但纵向扩容是过渡期宝贵的"救命稻草"。关键是让应用尽早具备横向扩展的能力（无状态、会话外置、共享存储）。
七、一套理性的扩容流程
- 监控报警：核心指标设阈值，持续超标才告警，避免毛刺误触发。
- 拉数据：看高峰时段、多项指标、以及近几周趋势。
- 判性质：是容量不足，还是可优化的问题？先排除优化空间。
- 定量：用压测的单机能力和当前峰值 QPS，算出需要几台、留多少冗余。
- 算成本：比较纵横向方案，算每 QPS 成本，符合预算再执行。
- 灰度扩容：先加一部分，观察指标是否改善，再全量。
- 复盘：记录本次扩容依据、效果、成本，作为下次决策的基线。
常见问题
Q1：CPU 到多少该扩容？
没有统一数字。经验上峰值持续超过 60%~70% 就该规划，但这要结合趋势和其他指标。如果只是短时毛刺、其他指标都很松，未必需要扩。
Q2：怎么判断是容量不足还是代码问题？
看瓶颈是否集中在可控点。热点函数、慢查询、锁竞争属于代码/配置问题，优先优化；所有资源随流量均匀逼近上限，才是真容量不足。
Q3：加机器后性能没改善，为什么？
可能是扩错了方向（瓶颈在磁盘或下游），也可能加了机器但共享了同一个单点（如单库、单缓存），或者应用无法并行。先定位再扩容。
Q4：冗余要留多少？
生产环境一般让系统在峰值时仍保留 30%~40% 余量，同时保证少一台机器也能扛住（N+1）。可用性要求高的业务留更多。
Q5：扩容和优化的先后顺序？
永远先看能不能优化。优化往往成本更低、效果更持久；优化到极限、确实是流量增长导致的容量不足，再扩容。
总结
- 扩容前先想清楚三件事：瓶颈在哪、能否优化、扩多少够用，避免盲目加机器。
- 评估指标分资源层（CPU/内存/磁盘/网络利用率、await、%util）和业务层（QPS 余量、P95/P99、连接数、错误率）。
- 看水位更看趋势和峰值；多项指标同时逼近上限才是真需要扩容。
- 区分"该扩容"和"该优化"：瓶颈集中在可控点先优化，资源随流量均匀逼近上限才扩容。
- 用"每 QPS 月成本"做决策，算全成本；短应急用纵向、长增长用横向，并灰度验证。所有阈值与倍数为经验值，以自身业务数据为准。
企业QQ咨询
