弹性伸缩支持定时任务和报警任务（含目标追踪规则）两种自动伸缩方式。在同时使用这两种方式时，如果配置不当，可能导致定时扩容被报警任务覆盖，最终容量不符合预期。本文介绍定时任务与报警任务的协同机制，并提供最佳配置方案，帮助您避免伸缩冲突。
问题场景
当伸缩组同时开启期望实例数、定时任务和报警任务（如目标追踪规则）时，可能出现以下问题：定时任务在指定时间触发扩容，但扩容尚未完成时，报警任务随即触发并覆盖了定时任务设置的期望实例数，导致扩容未生效。
典型案例
原因分析
上述问题的根本原因在于定时任务与报警任务的执行机制差异：
对比维度 | 定时任务（仅修改期望实例数） | 报警任务 |
执行方式 | 仅修改期望实例数的值，不直接触发伸缩活动 | 立即触发伸缩活动并同步修改期望实例数 |
生效时间 | 期望实例数修改后，需要等待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分钟的生效延迟，期间报警任务可能覆盖该值。
即使扩容成功，由于最小实例数未同步调整，目标追踪规则可能将实例数缩容到预期以下。
是否需要在定时任务中同时设置最大实例数？
通常不需要。最大实例数一般保持一个固定的上限值，以防止异常情况导致实例无限扩容。如果您的业务场景需要在不同时段设置不同的实例上限，也可以在定时任务中同步调整最大实例数。
如果不使用目标追踪规则，而是使用简单规则的报警任务，还会有冲突吗？
是的，同样可能出现冲突。无论报警任务关联的是简单规则、步进规则还是目标追踪规则，只要报警任务在定时任务的生效延迟期内触发，都会覆盖期望实例数。本文的解决方案对所有类型的报警任务均适用。