流量有两种成分，扩容也不能只靠一种策略

多数在线业务的流量由两部分构成：一部分是可预期的节律性波动，例如白天高峰、凌晨低谷、工作日与周末的差异；另一部分是难以提前判断的突发流量，可能来自推广活动、热点事件或上游调用的变化。前者适合用定时调度提前布局，后者需要弹性伸缩实时响应。只用其中一种，往往要么在突发面前反应不及，要么在低谷期持续为闲置资源付费。

两种机制的分工

弹性伸缩：面向不确定的波动

弹性伸缩基于监控指标触发，常见信号包括CPU利用率、内存占用、网络带宽、请求数、连接数和队列积压等。当指标持续超过设定阈值时触发扩容，回落到合理区间并稳定一段时间后触发缩容。它的优势是跟随真实负载，缺点是指标采集、聚合、判断存在延迟，实例从创建到可服务也需要启动时间，因此更适合应对幅度不确定、时间点不确定的流量变化。

定时调度：面向可预期的节律

定时调度按预设时间点或周期规则调整期望实例数，不依赖实时监控数据，到点即执行。它适合业务节律相对稳定的场景，也适合在流量高峰到来之前完成预热，让实例在压力到达前就进入就绪状态。对于每周固定时段的活动、每日固定时段的业务集中，定时规则的确定性往往优于纯阈值判断。

组合思路：定时打底，弹性兜底

把两者叠加使用，核心思路是让定时调度负责可预期的峰谷切换，让弹性伸缩负责超出预期的部分。

1. 梳理业务节律。基于历史监控数据识别每日、每周的流量高点与低点，找出重复出现的模式，作为定时规则的依据。
2. 用定时任务设定基线与峰谷。在高峰前提前扩容，在低谷后有序缩容，使资源规模与业务节律大致吻合。
3. 把弹性策略叠加在定时结果之上。定时规则给出基础容量，弹性策略在该基础上按实际指标增减，吸收超出预期的部分。
4. 设置合理的冷却时间与扩缩容步长。扩容可以相对积极，缩容应更保守，避免流量短暂回升时反复震荡。

需要说明的是，不同云平台对定时策略与动态策略共存时的生效方式（如优先级、取最大值或最小值）实现不同，配置前应以所用平台的文档为准。

关键配置要点

• 缩容比扩容更谨慎：为缩容设置更长的观察窗口和冷却时间，防止实例数频繁上下。
• 关注应用启动时间：配合生命周期钩子与就绪检查，确保实例完成初始化后再接入负载均衡。
• 指标要贴合真实瓶颈：CPU不一定是最灵敏的信号，线程池、连接数、队列长度往往更早反映压力。
• 保留合理的最小实例数：为缩容后的突发留出缓冲，也避免关键组件被同时缩掉。
• 处理好有状态部分：数据库连接池、会话数据、后台任务节点在缩容时需要优雅下线。

成本视角：把资源分成三层

从成本结构看，可以把资源分为三层：长期稳定的基线容量、按节律变化的过渡容量、应对突发的弹性容量。定时调度主要优化中间层，让非高峰时段的资源随业务一起回落；弹性伸缩则覆盖最上层，只在真正需要时短暂增加资源。两者的共同目标不是把资源压到最低，而是在稳定性与资源占用之间找到平衡点。至于采用按量、包年包月还是预留方式，需要结合业务稳定程度和各平台的计费规则单独评估。

常见误区

• 只配置扩容规则，不考虑缩容，低谷期资源长期闲置。
• 用定时任务完全替代弹性伸缩，遇到超出预期的流量没有应对手段。
• 阈值设置过于灵敏，实例数频繁变化，反而影响服务稳定性。
• 忽略应用启动与依赖初始化时间，扩容完成但服务尚未就绪。
• 只扩应用层，数据库、缓存或第三方接口成为新的瓶颈。

上线后的验证与迭代

组合策略上线后，需要持续观察几类信息：扩容触发时间与流量到达时间的差值、缩容后是否出现性能回落、实例利用率的分布是否合理、是否存在长时间空转的实例。同时结合节假日、活动日历等可预期变量，定期回顾并调整定时规则。业务节律会变化，伸缩策略也不是一次配置就长期有效，定期复盘才能让成本与体验持续保持在合理区间。