服务器变慢、磁盘快满、数据库连接数打满，这几种信号经常同时出现。很多团队等到故障了才去扩容，仓促操作既可能影响线上服务，也容易买多了配置。先弄清楚瓶颈在哪，再选扩容方式，通常既稳又省。
先找出瓶颈在哪一层
CPU 高、内存不够、磁盘 I/O 慢、带宽被占满，这四种情况的处理办法各不相同。升 CPU 解决不了磁盘读写慢的问题，加带宽也救不了内存溢出。打开云监控，把近一周的 CPU 利用率、内存使用率、磁盘读写延迟和网络流量曲线拉出来看。留意峰值出现的时间，是每天固定时段，还是某次活动才有。如果 CPU 长期低于 30%，只是偶尔冲高，先考虑弹性伸缩，别急着加配置。
ECS 纵向扩容和横向扩容怎么选
纵向扩容是把单台实例的规格调大，比如从 2 核 4G 升到 4 核 8G。操作直接，但通常要停机重启，所以更适合单体应用或数据库这类不容易拆开的服务。停机窗口要提前和业务方对齐，不要在对方不知情的时候动手。
横向扩容是增加实例数量，前面挂负载均衡 SLB 分流。它更适合无状态的 Web 服务。配合弹性伸缩 AS，可以按 CPU 或请求量自动增减实例。前提是应用本身不依赖单机状态。会话信息和上传文件要放到共享存储或缓存里，否则新扩出来的实例各管各的，用户会遇到登录态丢失之类的问题。
规格变更前，还要检查实例所在可用区是否有目标规格的库存。库存不足时调整会卡住，停机时间白白拉长。
云盘与数据库：两类操作的风险不同
云盘扩容相对安全，多数情况下可以在线完成。但扩完容量，系统不一定马上能用。还要登录实例，扩展分区和文件系统。Linux 下一般要做分区调整并执行 resize 文件系统的命令，Windows 在磁盘管理里扩展卷即可。操作前先备份，并确认目标分区和设备名，别对着错误的盘执行命令。
云数据库 RDS 的扩容一般是规格变更或存储扩容。变更过程中会发生短暂的主备切换，应用端会感知到一次断连。所以最好选业务低峰期执行，并确认应用有断线重连机制，连接池能自动重建连接。不少线上故障并不出在数据库本身，而是应用拿着失效的连接一直报错，故障被放大。
如果瓶颈是读压力，可以加只读实例，把报表、搜索这类查询分流出去。写入压力没有变，只是读请求被分开了，所以这种办法往往比一直升配主库更对症。
一个电商团队的处理过程
某中型电商团队在大促前发现，订单服务响应时间从 200 毫秒涨到 2 秒以上。排查时看到，数据库 CPU 长期满载，应用服务器 CPU 只有 40% 左右。压力集中在数据库，应用层并不是主要问题。
团队分三步处理，没有对所有机器统一升配。第一步，提高商品查询的缓存命中率，让更多请求不必打到数据库。第二步，给 RDS 加一个只读实例，把报表类查询迁过去。第三步，给订单服务配置弹性伸缩，CPU 超过 65% 时自动扩容两台实例。
调整之后，大促期间数据库 CPU 峰值降到 70% 以下，订单接口响应稳定在 300 毫秒左右，整体成本也比全面升配低。这个案例里，团队先找到压力所在，然后只动该动的部分。
操作前后的检查清单
- 扩容前做快照或备份。出错时能回滚，比事后补救省事得多。
- 规格变更先在测试环境跑一遍，确认应用、驱动和中间件都兼容新规格。
- 弹性伸缩要设置冷却时间。指标在阈值附近波动时，没有冷却时间，实例会反复启停。
- 提前查看配额。部分资源超出默认配额时需要提交工单申请提升，流程可能比预想的慢。
- 扩容后持续观察监控曲线一段时间，确认瓶颈指标真的回落，而不是暂时被压下去。
判断时机，再动手
阿里云扩容的操作本身不难，难的是判断什么时候扩、用哪种方式扩。先看清瓶颈在哪一层，再决定纵向还是横向，最后用监控和自动化策略把资源管起来。按这个顺序做，扩容带来的停机和浪费都能控制在可接受的范围内。
