华为云弹性伸缩 AS 实战：伸缩组、策略与冷却时间的避坑指南

前言

业务流量很少是一条直线。促销、开学、月末结算、突发热点，都可能让流量在短时间内翻几倍；反过来，夜间和节假日又可能闲下来。如果按峰值买机器，平时就在烧钱；按均值买机器，峰值就可能扛不住。弹性伸缩 AS（Auto Scaling）要解决的，就是「按需增减计算资源」这件事。

AS 本身不难理解，但真正落地时，经常卡在几个细节上：伸缩配置和云服务器模板到底怎么配、告警策略触发后为什么迟迟不加机器、冷却时间到了却还在等、缩容把还在处理请求的实例干掉了。本文按「先建什么、再怎么触发、缩容怎么不伤业务、上线前查什么」的顺序整理一遍。文中涉及的指标名、默认值、配额和可选项，请以华为云官方文档和控制台页面为准，这里给的是设计思路，不是固定参数。

一、先分清：伸缩组、伸缩配置、伸缩策略

AS 里最容易混的是这三个概念：

• 伸缩组：一堆「同类」云服务器的集合，绑定了 VPC、子网、安全组、负载均衡（可选），并规定最小数、最大数、期望数。
• 伸缩配置：新建实例时用的「模板」——镜像、规格、磁盘、登录方式、用户数据脚本等。可以理解成「下一台机器长什么样」。
• 伸缩策略：什么时候加、什么时候减——常见是告警策略（看 CPU、内存、入带宽等）和定时/周期策略（已知高峰）。

常见坑是：伸缩组建好了，策略也配了，但伸缩配置里的镜像是很久以前的，装的依赖、Agent、业务包都不对；或者安全组、子网和现有业务不一致，新扩出来的机器根本接不进流量。建议把「当前线上标准机」的配置固化成伸缩配置，并用同一套初始化脚本（cloud-init / 用户数据）保证新实例开箱可用。

二、策略怎么选：告警 vs 定时

没有哪种策略能包打天下，通常是组合使用：

• 定时 / 周期策略：适合可预见的高峰，比如每天 9 点到 11 点、每周五晚上。好处是提前扩容，用户来了机器已经在；坏处是预测错了会浪费或不够。
• 告警策略：适合波动难预测的场景。常见做法是看 CPU 使用率、活跃连接数、队列堆积、ELB 后端时延等。阈值要结合业务基线，不要照抄「CPU 超过 70% 就扩」——有的服务常态就在 65% 附近。

告警策略还要配合「连续多次超过阈值」来过滤毛刺，这点和云监控 CES 告警的思路一致。扩容灵敏度可以高一点，缩容要更保守：宁可晚几分钟缩，也不要在流量还没真正落下时把实例干掉。

三、冷却时间：为什么「触发了却不加机器」

冷却时间（cooldown）是很多「策略明明触发了却没动作」的原因之一。伸缩活动开始后，在冷却时间内，同一伸缩组通常不会立刻再执行下一次伸缩，避免指标抖动导致机器刚加完又加、刚减完又减。

落地时注意三点：

1. 冷却时间要覆盖「新实例从创建到真正能接流量」的时间。如果业务启动要两分钟，冷却却只有几十秒，下一轮策略可能在实例还没就绪时又触发，或者你误以为「没扩成功」。
2. 手工调整期望数、或某些强制伸缩，和策略触发的冷却可能相互影响，排查时先看伸缩活动历史，而不是只盯策略配置页。
3. 指标周期 × 连续次数 ≈ 从问题出现到触发的延迟；再加上冷却和新实例启动时间，才是「用户侧感知到的扩容时延」。核心链路要把这三段时间加在一起评估。

四、健康检查、负载均衡与实例保护

如果伸缩组挂了弹性负载均衡 ELB，新扩的实例要先通过健康检查才会进流量；缩容时也建议优先摘除已经不健康的实例。这里有几个细节：

• 健康检查宽限期：新实例刚启动时，业务进程可能还没起来，检查失败是正常的。宽限期要大于应用启动时间，否则实例会被反复判定异常。
• 缩容前的连接排空：直接删实例，会把还在处理的请求掐断。能和 ELB 配合时，先把实例从后端摘掉、等连接自然结束，再删除。
• 实例保护：有的机器跑了不能随意杀掉的任务（特殊会话、一次性批处理）。对这些实例开启保护，避免被自动缩容选中。

伸缩活动历史和 ELB 后端状态要一起看：AS 显示「已添加实例」，但 ELB 上还是异常，流量照样进不去——问题往往在安全组、健康检查路径或应用监听端口，而不是 AS 本身。

五、缩容比扩容更伤人

扩容失败，最坏是性能差一点；缩容选错实例，可能直接造成部分用户失败。建议：

• 缩容策略更保守：更高的阈值、更多的连续次数、更长的观察窗口。
• 优先缩「最闲」或「最老」的实例，并避开有保护标记的。
• 无状态服务更适合自动缩；有状态、本地缓存很重的服务，要么先改造，要么缩容前做会话迁移/缓存预热。
• 最小实例数不要设成 0，除非你非常清楚冷启动成本和可用性风险。

六、上线前检查清单

• 伸缩配置中的镜像、规格、磁盘、安全组、子网与线上一致；用户数据脚本能完成依赖安装、Agent、服务注册。
• 最小 / 期望 / 最大实例数合理，配额足够支持扩到最大数。
• 告警策略指标来源正确（基础监控 vs Agent），阈值参考了业务基线，并用连续次数过滤毛刺。
• 冷却时间 ≥ 实例就绪时间；健康检查宽限期 ≥ 应用启动时间。
• 若绑定 ELB：健康检查路径、端口正确；缩容有摘流/排空意识；关键实例已开保护。
• 做一次演练：手动改期望数或制造负载，观察从触发 → 活动历史 → 实例就绪 → 进流量的全链路耗时。
• 有回滚预案：策略可临时停用，期望数可手工拉回。

结语

弹性伸缩不是「配了 CPU 告警就完事」。伸缩配置要能复制出真正可用的机器，策略要贴合业务峰谷，冷却和健康检查决定了扩容是否来得及，缩容规则和实例保护决定了会不会误伤。把这几件事在上线前演练清楚，AS 才能从「控制台上的几个开关」变成峰值时靠得住的自动运维能力。欢迎交流你们在伸缩策略上的实践。