2、伸缩策略基础：手动伸缩 vs 自动伸缩、伸缩的触发条件、冷却时间与稳定性
好，咱们进入第二章。这一章是伸缩策略的基石，说白了就是搞清楚「什么时候扩、什么时候缩、怎么扩才不会出乱子」。我见过不少团队，一上来就搞自动伸缩，结果业务一波动，系统反而先崩了。嗯，基础不牢，地动山摇。
2.1 手动伸缩 vs 自动伸缩
先聊聊最原始的方式——手动伸缩。你想想看，半夜三点被报警电话叫醒，爬起来登录控制台，点几下鼠标把实例数从 10 台加到 50 台。这就是手动伸缩。我早期做运维时，这种事干过不下百次。
手动伸缩的特点：
- 控制权完全在你手里——想什么时候扩就什么时候扩，想扩多少就扩多少。
- 适合可预见的流量高峰——比如双十一大促，提前几天就把资源准备好。
- 缺点也很明显——反应慢、容易出错、人肉运维成本高。
我记得有一次，客户说「明天有活动，流量会翻三倍」。我手动加了 20 台机器，结果活动提前两小时开始了，流量瞬间暴涨，我还在吃晚饭……从那以后，我对自动伸缩就特别上心。
自动伸缩呢？ 它是系统根据预设规则，自动调整资源数量。说白了，就是让机器替你干活。
- 优点：响应快、7x24 小时在线、减少人为失误。
- 缺点：配置复杂、容易误判、需要反复调优。
我的建议：初期先用手动伸缩摸清业务规律，等数据积累够了再上自动伸缩。别一上来就全自动，容易翻车。
2.2 伸缩的触发条件
自动伸缩的核心，就是触发条件。你总得告诉系统「什么时候该干活」吧？常见的触发条件有这几类：
2.2.1 基于指标的触发
这是最常用的方式。系统监控 CPU、内存、请求量等指标，超过阈值就触发伸缩。
| 指标 | 典型阈值 | 说明 |
|---|---|---|
| CPU 使用率 | > 70% 持续 5 分钟 | 计算密集型业务常用 |
| 内存使用率 | > 80% 持续 3 分钟 | 缓存或大数据场景 |
| 请求 QPS | > 1000 持续 2 分钟 | Web 服务最常用 |
| 网络带宽 | > 500 Mbps 持续 1 分钟 | 流媒体或文件传输 |
这里有个坑：单一指标容易误判。我曾经遇到一个场景，CPU 飙到 90%，但其实是后台在做数据压缩，业务请求量并不大。结果自动伸缩加了一堆机器，白白浪费钱。所以，我习惯用多个指标组合判断，比如「CPU > 70% 且 QPS > 500」才触发扩容。
2.2.2 基于时间的触发
如果你能预测流量高峰，比如每天早上 9 点上班、晚上 8 点活动开始，那就用定时伸缩。提前 10 分钟把资源准备好，用户无感知。
# 伪代码示例：定时伸缩策略
schedule:
- time: "08:50"
action: scale_up
target: 20 instances
- time: "22:00"
action: scale_down
target: 5 instances我个人习惯把定时伸缩作为「保底方案」。即使自动伸缩出了问题，定时策略也能兜底。
2.2.3 基于预测的触发
这是比较高级的玩法。用机器学习模型预测未来几分钟的流量，提前扩容。我参与过的一个项目，用 LSTM 模型预测 QPS，准确率能到 85% 以上。不过，这需要大量历史数据，小团队慎用。
小技巧：刚开始做自动伸缩时，先用「基于指标 + 基于时间」的组合策略。等业务稳定了，再考虑预测式伸缩。
2.3 冷却时间与稳定性
好，接下来是重点——冷却时间。这东西看着简单，但坑特别多。
什么是冷却时间？ 就是一次伸缩动作完成后，系统需要等待一段时间，才能进行下一次伸缩。为什么要等？因为新启动的机器需要时间初始化、加载缓存、注册服务。如果刚扩完又触发扩容，就会造成「抖动」。
我举个例子：
- 你的 CPU 阈值是 70%
- 流量来了，CPU 升到 75%，触发扩容，加了 2 台机器
- 新机器启动需要 3 分钟，这 3 分钟内 CPU 还是 75%
- 如果没有冷却时间，系统会再次触发扩容，又加 2 台
- 等新机器都起来了，CPU 降到 30%，你又得缩容
你看，这就是典型的「伸缩震荡」。我曾经在一个电商项目中遇到过，冷却时间设得太短，结果一晚上扩了 30 次、缩了 28 次，云厂商账单直接翻了三倍。嗯，那次的教训很深刻。
2.3.1 冷却时间怎么设？
没有标准答案，但有几个经验值：
| 业务类型 | 建议冷却时间 | 说明 |
|---|---|---|
| Web 服务（轻量） | 60-120 秒 | 启动快，冷却可以短一些 |
| Java 应用 | 180-300 秒 | JVM 启动慢，需要更长时间 |
| 大数据/机器学习 | 300-600 秒 | 加载模型、数据分片耗时 |
| 数据库/缓存 | 120-180 秒 | 数据同步需要时间 |
注意：冷却时间不是越长越好。设得太长，流量高峰来了你扩不动；设得太短，又容易震荡。我建议从 120 秒开始，观察一段时间再调整。
2.3.2 稳定性策略
除了冷却时间，还有几个手段能提升伸缩稳定性：
- 步进伸缩：每次只扩/缩固定数量（比如每次加 2 台），而不是一次性加很多。避免过度反应。
- 最小/最大实例数：设置一个范围，比如最少 3 台、最多 50 台。防止缩到 0 导致服务不可用，也防止扩太多导致成本失控。
- 预热期：新机器启动后，先不接入流量，等健康检查通过后再加入负载均衡。我习惯给 30 秒的预热时间。
- 慢启动：新机器刚上线时，只分配少量请求，慢慢增加到正常水平。这能防止「雪崩效应」。
说白了，伸缩策略的核心就是「稳」字。你想想看，如果伸缩本身比业务波动还剧烈，那还不如不伸缩。
2.4 小结
这一章我们聊了手动伸缩和自动伸缩的区别，也讲了触发条件的三种方式：基于指标、基于时间、基于预测。最后重点强调了冷却时间和稳定性策略。我个人觉得，冷却时间是自动伸缩里最容易忽略、也最容易出问题的地方。你配置好策略后，一定要做压力测试，看看实际效果。
下一章，我们会深入聊聊「水平伸缩 vs 垂直伸缩」，以及它们各自的适用场景。到时候见。