弹性伸缩支持定时任务和报警任务(含目标追踪规则)两种自动伸缩方式。在同时使用这两种方式时,如果配置不当,可能导致定时扩容被报警任务覆盖,最终容量不符合预期。本文介绍定时任务与报警任务的协同机制,并提供最佳配置方案,帮助您避免伸缩冲突。
问题场景
当伸缩组同时开启期望实例数、定时任务和报警任务(如目标追踪规则)时,可能出现以下问题:定时任务在指定时间触发扩容,但扩容尚未完成时,报警任务随即触发并覆盖了定时任务设置的期望实例数,导致扩容未生效。
典型案例
原因分析
上述问题的根本原因在于定时任务与报警任务的执行机制差异:
|
对比维度 |
定时任务(仅修改期望实例数) |
报警任务 |
|
执行方式 |
仅修改期望实例数的值,不直接触发伸缩活动 |
立即触发伸缩活动并同步修改期望实例数 |
|
生效时间 |
期望实例数修改后,需要等待30秒~1分钟才生效 |
立即生效 |
|
冲突风险 |
在等待生效的窗口期内,可能被其他任务覆盖 |
执行后直接更新期望实例数为当前实际值 |
核心问题:当定时任务仅修改期望实例数时,该操作不是一次原子性的、立即生效的容量变更。在30秒~1分钟的生效延迟期间,报警任务可能基于当前的实际实例数触发伸缩活动,并重新计算和覆盖期望实例数。
最佳实践:定时任务控制基座容量,报警任务控制弹性容量
方案概述
采用"基座 + 弹性"的分层容量模型,将定时任务和报警任务的职责明确分离:
-
基座容量(定时任务负责):通过定时任务同步设置最小实例数和期望实例数,保证业务高峰期的底线容量不被报警任务缩容。
-
弹性容量(报警任务负责):通过目标追踪规则或报警任务,在基座容量之上根据实际负载动态增减实例。

操作步骤
以下通过一个示例场景说明推荐配置:假设业务需要在每天早上8:00将实例数从日常的10台扩容至50台,晚上22:00恢复日常水平,同时使用目标追踪规则维持CPU使用率在60%。
步骤一:创建定时扩容任务
创建一个定时任务,在业务高峰开始时同步设置最小实例数和期望实例数,确保基座容量立即生效且不会被报警任务覆盖。
-
登录弹性伸缩控制台。
-
在左侧导航栏,单击伸缩组管理。
-
找到目标伸缩组,单击伸缩组名称进入详情页面。
-
单击伸缩规则与任务页签,在定时任务列表下,单击创建定时任务。
-
创建定时扩容任务,配置如下:
配置项
值
任务名称
scheduled-scale-up
执行时间
每天早上8:00(或业务高峰开始时间)
重复周期
按天
伸缩方式
伸缩组内实例数量设置
最小实例数
50
期望实例数
50
关键配置:伸缩方式选择伸缩组内实例数量设置,同时设置最小实例数和期望实例数为50。这样定时任务执行时会同步修改伸缩组的最小实例数和期望实例数,确保容量不会被报警任务缩容到50台以下。
步骤二:创建定时缩容任务
创建一个与扩容任务成对的定时缩容任务,在业务高峰结束后将最小实例数恢复到日常水平,避免资源浪费。
-
在定时任务列表下,单击创建定时任务,配置如下:
配置项
值
任务名称
scheduled-scale-down
执行时间
每天晚上22:00(或业务高峰结束时间)
重复周期
按天
伸缩方式
伸缩组内实例数量设置
最小实例数
10
期望实例数
10
步骤三:配置目标追踪规则
创建目标追踪规则,让报警任务在定时任务设定的基座容量之上,根据实际负载自动进行弹性伸缩。
-
单击伸缩规则与任务页签,在伸缩规则列表下,单击创建伸缩规则。
-
创建目标追踪规则,配置如下:
配置项
值
伸缩规则类型
目标追踪规则
指标类型
(ECS)平均CPU使用率
目标值
60%
目标追踪规则会根据CPU使用率在伸缩组的最小实例数和最大实例数之间自动调整实例数量。由于定时任务已将最小实例数设置为50,即使CPU使用率较低,实例数量也不会低于50台。
配置后的执行效果
|
时间 |
事件 |
最小实例数 |
期望实例数 |
实际效果 |
|
每天 08:00 |
定时扩容任务触发 |
10 → 50 |
10 → 50 |
立即开始扩容至50台 |
|
08:00~22:00 |
目标追踪规则持续工作 |
50 |
≥50 |
CPU使用率高于60%时,在50台基础上继续扩容;低于60%时最多缩容至50台 |
|
每天 22:00 |
定时缩容任务触发 |
50 → 10 |
50 → 10 |
恢复日常容量水平,多余实例逐步释放 |
|
其他时段 |
目标追踪规则持续工作 |
10 |
≥10 |
根据CPU使用率在10台基础上弹性伸缩 |
配置要点总结
-
定时任务选择"伸缩组内实例数量设置"伸缩方式,同时设置最小实例数和期望实例数,而非仅修改期望实例数。
-
成对创建定时任务:扩容和缩容任务成对出现,确保高峰期结束后最小实例数能恢复到日常水平,避免资源浪费。
-
最小实例数、期望实例数、最大实例数三者的关系:
-
定时任务通过设置最小实例数和期望实例数控制基座容量。
-
报警任务/目标追踪规则在最小实例数和最大实例数之间进行弹性调整。
-
系统内置规则保证最小实例数 ≤ 期望实例数 ≤ 最大实例数,优先级清晰,无需额外设计冲突规避机制。
-
常见问题
-
定时任务扩容成功后,如果CPU使用率较低,目标追踪规则会不会把实例缩回去?
不会。定时任务同步设置了最小实例数,目标追踪规则不会将实例数缩容到最小实例数以下。这就是为什么同时设置最小实例数的关键。
-
定时任务只修改期望实例数是否可行?
不建议。仅修改期望实例数存在以下风险:
-
期望实例数修改后有30秒~1分钟的生效延迟,期间报警任务可能覆盖该值。
-
即使扩容成功,由于最小实例数未同步调整,目标追踪规则可能将实例数缩容到预期以下。
-
-
是否需要在定时任务中同时设置最大实例数?
通常不需要。最大实例数一般保持一个固定的上限值,以防止异常情况导致实例无限扩容。如果您的业务场景需要在不同时段设置不同的实例上限,也可以在定时任务中同步调整最大实例数。
-
如果不使用目标追踪规则,而是使用简单规则的报警任务,还会有冲突吗?
是的,同样可能出现冲突。无论报警任务关联的是简单规则、步进规则还是目标追踪规则,只要报警任务在定时任务的生效延迟期内触发,都会覆盖期望实例数。本文的解决方案对所有类型的报警任务均适用。