新手配置自动伸缩策略要先回答哪5个问题？

很多新手配置弹性云主机自动伸缩策略时，第一步就是填写 CPU 阈值。但自动伸缩并不是“超过 70% 就加机器”这么简单：请求高峰的持续时间、单台实例的处理能力、启动耗时以及业务是否保存本地状态，都会影响最终结果。

在创建伸缩组、绑定负载均衡或设置告警之前，建议先回答下面 5 个问题。答案越具体，策略越容易验证，也越不容易出现频繁扩容、容量不足或缩容误删的问题。

一、业务真正要保护的目标是什么？

弹性云主机自动伸缩策略首先要服务于业务目标，而不是服务于某个监控曲线。你需要先明确：是要保证接口响应时间、避免任务积压，还是控制高峰期间的主机成本？不同目标会产生不同的扩容信号。

• 面向在线请求：重点关注响应延迟、错误率、活动连接数和每秒请求量。
• 面向异步任务：重点关注消息队列积压量、单任务处理时间和消费者数量。
• 面向批处理：重点关注任务截止时间、并行度和单台实例的吞吐能力。

例如预约系统在开放时间前后可能出现短时流量峰值。此时只看 CPU 可能反应过慢，因为请求数已经增加，但程序尚未把 CPU 用满。若业务目标是维持接口可用，可以把高延迟或 5xx 错误率作为保护指标，把 CPU 作为辅助指标。

二、哪个指标最适合作为伸缩依据？

第二个问题是“什么变化意味着确实需要更多实例”。监控指标应与实例数量有清晰关系，并且能够在业务压力变化后较快反映出来。

优先选择可解释的业务指标

如果每台实例大致能稳定处理 40 至 60 个并发请求，可以将活动连接数或每实例请求数作为参考；如果实例负责消费队列，则“每实例待处理消息数”通常比 CPU 更直接。延迟适合做服务质量保护，但要注意数据库、缓存或外部依赖也可能造成延迟升高。

避免单指标决定全部动作

较稳妥的做法是设置主指标和保护指标。例如以每实例请求数触发扩容，同时要求错误率没有持续升高；或者以队列积压触发扩容，再用 CPU 和内存限制单台实例的异常负载。阈值应通过压测或历史监控估算，初始值可留出约 20% 至 30% 的余量，随后根据实际曲线调整。

三、最小、最大容量分别应该是多少？

第三个问题决定成本上限和故障时的承载边界。最小容量不是越小越好，最大容量也不能简单设置成一个很大的数字。

如果后端数据库最多只能承受 100 个并发连接，而每台主机应用会占用约 10 个连接，那么即使计算资源允许，也不能无限增加实例。配置弹性云主机自动伸缩策略时，应把数据库连接池、第三方接口额度和云资源配额一并纳入上限设计。

四、扩容和缩容需要等待多久？

第四个问题是动作节奏。主机启动、应用初始化、加载配置和通过健康检查，通常需要几十秒到数分钟，具体取决于镜像、启动脚本和依赖服务。扩容判断必须考虑这段延迟。

1. 先记录从创建实例到健康检查通过的平均耗时，并以较慢的一侧作为安全参考。
2. 为扩容设置连续观察窗口，例如连续 3 至 10 分钟超过阈值再执行，避免单个尖峰造成误动作。
3. 为缩容设置更长的观察窗口，例如连续 15 至 30 分钟低于下限后再执行。
4. 设置冷却时间或变更间隔，让前一次扩缩容有机会产生效果。

扩容通常应比缩容更积极，缩容则要更谨慎。对于启动慢、流量波动大的服务，可以采用阶梯式扩容：压力较小时增加 1 台，压力明显升高时增加 2 台或更多，但每次增加的数量仍应受最大容量约束。

五、实例能否安全地被替换或删除？

最后要确认业务状态是否保存在本地。若请求会依赖本地会话、临时文件或未同步的任务进度，缩容前必须先完成状态迁移或排空。

可执行的检查步骤如下：

1. 确认会话是否放在共享缓存或数据库，而不是某一台主机的本地内存。
2. 确认上传文件、任务结果和日志是否写入持久化存储或集中式日志系统。
3. 为实例配置健康检查、优雅退出和连接排空时间。
4. 对正在处理的异步任务设置确认机制，避免实例删除后任务丢失。
5. 先在低峰时手动移除一台实例，观察请求、任务和日志是否完整，再启用自动缩容。

如果实例无法安全替换，可以暂时关闭缩容，或只对无状态节点启用弹性云主机自动伸缩策略。这比为了节省少量主机费用而造成会话中断更稳妥。

把5个问题落成一份策略

完成判断后，可以按“目标—指标—边界—节奏—状态”的顺序记录配置。相关词包括扩容阈值、冷却时间、实例组和缩容保护。每项都应注明触发条件、执行动作、观察周期和回滚方式。

上线初期建议先采用保守配置：较宽的缩容条件、明确的最大实例数、较长的冷却时间，并保留扩缩容事件日志。运行一到两个完整业务周期后，再根据峰值、实例启动耗时和后端资源使用情况调整。这样制定的弹性云主机自动伸缩策略，才是可以解释、可以验证、也可以逐步优化的配置。

常见问题

1. 只用 CPU 指标可以吗？

可以作为起点，但不建议长期只依赖 CPU。I/O 等待、队列积压、连接数或外部依赖延迟，都可能让 CPU 指标失真。

2. 扩容阈值越低越安全吗？

不一定。阈值过低会导致实例频繁增加，带来成本和启动抖动。应结合单实例容量、启动时间和业务容忍度设置。

3. 为什么扩容后仍然延迟很高？

可能是数据库、缓存、网络带宽或第三方接口成为瓶颈。扩容前要确认新增实例确实能分担主要压力。

4. 缩容前最容易忽略什么？

最常见的是本地会话、未完成任务和临时文件。应先完成状态外置、任务排空和健康检查，再启用自动缩容。