扩容的第一步不是加机器，是知道哪一项先满。
一、他先加了机器
用户从 120 涨到 160 的那两个月，祁越的账单从 55 美元涨到 130。他加了机器、升了套餐，页面还是偶尔转圈。
一次深夜排查，他发现真正的问题在数据库连接池：上限 20，峰值已经 9，而每个页面会开三个连接。加机器只是让更多进程去抢同一个池子。
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
加机器解决的是 CPU 与内存，不是所有瓶颈。 连接数、队列长度与存储都有独立的上限，钱花错地方不会变快。
账单涨了不等于容量不够。 先看每个资源的水位，再决定钱往哪加；账单只告诉你花了多少，不告诉你缺什么。
容量要看水位，不看绝对值。 9 个连接听起来很少，占 20 的上限是 45%，这才是要判断的数字。
水位要连续看四周。 单周峰值可能来自一次批处理；连续四周都在 70% 以上，才是真实趋势。
二、四个资源的水位
只看四个数，每周记一次。
| 资源 | 当前峰值 | 上限 | 水位 | 说明 |
|---|---|---|---|---|
| 数据库连接 | 9 | 20 | 45% | 每个页面开 3 个连接，池子按进程计 |
| 队列长度 | 320 | 1000 | 32% | 夜间批处理会堆到峰值 |
| 存储 | 1.8 GB | 10 GB | 18% | 每月增长 0.4 GB，主要是用户上传 |
| CPU | 62% | 100% | 62% | 用户流量约占 31 个百分点，批处理占 31 |
水位要取峰值，不取均值。 均值 20% 的连接池，峰值可能已经 90%；按均值扩容，永远慢一步。
上限要写真实值。 连接池上限是配置，存储上限是套餐，队列上限是你自己设的告警线；三者性质不同，不能混在一张图里比。
上限要能被改。 配置型上限（连接池、线程数）改一下就能扩容，别把它当成硬件限制；先确认数据库端也放得下。
CPU 要拆开看构成。 用户流量与批处理各占一半时，加机器对前者有效，对后者只是把账单翻倍。
批处理可以挪时间。 把夜间任务从高峰前挪到凌晨三点，常常比加核更有效，成本为零。
存储增长要看趋势。 0.4 GB/月是最近三个月的平均；若某月突然 1.2 GB，先查是不是多了备份副本。
三、三倍增长先撞哪堵墙
把每个资源乘以三，答案会很清楚。
当前水位：连接 9/20 = 45%；队列 320/1000 = 32%；存储 1.8/10 GB = 18%
三倍流量：
连接 27 > 20 → 先撞墙（配置上限，改配置即可）
队列 960 → 96%，逼近 1000 的告警线
存储 5.4 GB → 54%，仍安全
CPU = 31 × 3 + 31 = 124% → 超限，需加 2 核
存储触顶 = (10 − 1.8) ÷ 0.4 = 20.5 个月
连接池 20 → 50：成本 0 美元，需重启一次
加 2 核：约 +40 美元/月，在固定 55 里占比 73%
第一堵墙是配置，不是钱。 连接池从 20 调到 50 不花钱，只要确认数据库端的最大连接数也够。
配置改动也要有回滚。 改连接池后若数据库端先撑不住，要能在一分钟内改回原值。
第二堵墙是 CPU，但它排在队列后面。 队列 960 会先触发告警；先把阈值从 1000 降到 800，能在真正堵住前一周知道。
存储最不急。 20.5 个月才触顶，但它是最容易一次性跳变的：一次全量备份或一批大文件就能多吃 2 GB。
三倍是压力测试，不是预测。 真实增长可能是 1.4 倍，也可能是十倍；重要的是知道每个倍数下谁先倒。
四、扩容顺序与成本
顺序的原则是：先改配置，再改代码，最后才加钱。
| 顺序 | 措施 | 解决什么 | 月成本 | 何时做 |
|---|---|---|---|---|
| 1 | 连接池 20 → 50，并核对数据库上限 | 连接耗尽 | 0 | 现在 |
| 2 | 队列告警线 1000 → 800 | 提前一周发现积压 | 0 | 现在 |
| 3 | 页面复用连接，单页从 3 个降到 1 个 | 连接需求降到 1/3 | 0 | 一个月内 |
| 4 | 加 2 核，并给批处理设并发上限 | CPU 峰值 | 40 | 水位持续 70% 以上 |
| 5 | 对象存储加生命周期，冷数据转低频 | 存储增长 | −5 | 存储过 50% |
先做零成本的三项。 连接池、告警线与连接复用，通常能把 3 倍增长下的连接需求从 27 降到 9。
加钱要有触发条件。 「CPU 连续两周峰值超过 70%」比「感觉有点慢」可执行。
降本也是扩容的一部分。 冷数据转低频能抵掉一部分新增成本；先找能省的地方，再谈加钱。
扩容后要复测。 改完连接池，跑一次同样的峰值场景；不复测，你不知道改的是不是那个瓶颈。
复测要隔一天。 当天的缓存与连接复用会让结果偏乐观；第二天同一时段再看一次。
容量决策要写下日期与依据。 三个月后回看，才知道当时的判断对不对。
五、行动清单与复算验收
四个水位、一张表、一个顺序，容量就管住了。
- 每周记录连接、队列、存储、CPU 四个峰值。
- 为每个资源写下真实上限与来源。
- 把 CPU 拆成用户流量与批处理两部分。
- 用当前数据算一次三倍增长下的水位。
- 列出零成本的扩容措施并立刻执行。
- 为加钱措施写触发条件，不写「需要时」。
- 给队列与存储设两条提前告警线。
- 扩容后复测同一场景并记录结果。
验收标准：你能说出流量涨三倍时哪个资源先满、对应措施花多少钱；说不出，说明你还在用加机器代替容量判断。
使用边界与实操验收
本文处理的是一人产品的容量与成本判断，不涉及架构演进与压测方案。
压测不归本文。 四个水位是日常观测；要测极限，需要另做压测，成本也更高。
自动扩缩容不归本文。 一人产品的流量通常没有剧烈波动，手动扩更容易预测账单。
水位不等于体验。 连接 45% 时用户可能已经很慢；延迟仍要单独看。
别为峰值买全年。 一年只有两次大促，租用临时容量比常年高配便宜。
上限会随套餐变化。 升级套餐后要重算，否则表里的数字会误导决策。
成本要算全。 加机器会连带备份、流量与监控费用，40 美元可能变成 60。
记录每一次扩容的原因。 没有原因的扩容会变成习惯，账单会替你记住。
关键参考与核验范围
核验日期：2026-10-25。以下链接用于核对容量与过载处理的一般做法，本文未逐条引用其内容。
- Google SRE：处理过载 ：用于核对过载时的降级与配额思路。
- Google SRE：应对负载 ：用于核对接住流量峰值的常见手段。
引用口径。 本文只借用「按水位与增长倍数判断瓶颈」这一一般方法；9、20、320、1.8 GB、0.4 GB 与 40 美元全部是教学假设，与上述材料无关。
核验范围。 核验的是「四项水位能否支撑一次扩容决策」，不是比对某家云厂商的实例规格与价格。
如何自行复核。 取最近一周的峰值，按三倍重算四项水位；若结论与上次不同，说明基线已经变了。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。