4. EC2自动伸缩与调度优化

EC2的闲置成本，本质上来自“容量按峰值准备、负载却按波峰波谷波动”这一矛盾。Auto Scaling的价值不是简单地“多开机器”，而是让容量曲线尽量贴合负载曲线：负载上升时补足实例，负载下降时及时回收，同时用混合实例、预测与计划策略处理那些“可预知但不可实时响应”的波动。本节围绕四件事展开：Auto Scaling组怎么配、混合实例策略怎么选、预测性伸缩什么时候用、计划伸缩怎么落地。

一、Auto Scaling组：容量边界与伸缩单位

Auto Scaling组（ASG）是伸缩的基本单位，它管理一组同质实例，并维护三个核心容量参数：最小容量（Min）、期望容量（Desired）、最大容量（Max）。Min决定“保底容量”，Max决定“成本上限”，Desired是当前目标值，伸缩策略实际调整的就是Desired。配置时最容易出错的是把Min设得过高——这等于长期为闲置容量付费；把Max设得过低——突发流量时无法扩容，性能受损。

ASG还需要绑定启动模板（Launch Template），其中定义AMI、实例类型、安全组、IAM角色、用户数据等。启动模板应尽量精简，把可变部分交给混合实例策略覆盖。健康检查方面，建议启用ELB健康检查，让不健康的实例被自动替换，而不是仅依赖EC2状态检查。冷却时间（Cooldown）用于避免伸缩震荡：默认300秒，若指标波动快可适当缩短，但过短会导致反复扩缩。

二、混合实例策略：用多种实例类型摊薄成本与风险

混合实例策略（Mixed Instances Policy）允许一个ASG同时使用多种实例类型和多种购买选项（按需、Spot、Savings Plans）。它的核心价值有两个：一是提高扩容成功率，避免单一实例类型在目标AZ售罄时无法扩容；二是利用Spot实例显著降低单位计算成本，同时用按需实例保底。

配置时通常设置按需基数（On-Demand Base）和按需比例（On-Demand Percentage）。例如：On-Demand Base = 2，On-Demand Percentage = 30%，表示前2台始终按需，超出部分中30%按需、70%Spot。这样既保证核心容量稳定，又让弹性部分享受Spot折扣。实例类型应选择2～4种规格相近的（如m5.large、m5a.large、m6i.large），并开启容量再平衡（Capacity Rebalance），在Spot中断前主动替换实例。

三、预测性伸缩：应对周期性波峰

预测性伸缩（Predictive Scaling）适合有明显周期规律的负载，例如每天上午9点流量上升、晚上10点下降。它基于CloudWatch历史数据训练模型，提前预测未来容量需求，并在预测值基础上预留缓冲。与动态伸缩相比，预测性伸缩的优势是“提前扩容”，避免动态策略因指标延迟而滞后。

启用时需要注意：至少需要24小时历史数据，建议14天以上；预测模式可选“仅预测”或“预测并缩放”。若业务周期稳定，可设为“预测并缩放”，让ASG按预测值调整Desired；若周期不稳定，可先“仅预测”观察准确度。预测性伸缩通常与动态策略配合使用：预测负责趋势，动态负责突发。

四、计划伸缩：把可预知的事件写进日程

计划伸缩（Scheduled Scaling）适合“已知时间点”的容量调整，例如大促、定时批处理、每周报表。它通过Cron表达式或一次性时间点，直接设定Min/Max/Desired。与预测性伸缩的区别是：计划伸缩是“人为指定”，预测性伸缩是“模型推断”。

例如，某业务每天8:30开始爬升，可在8:25设置Desired=8，20:00设置Desired=3。配置时要注意时区（默认UTC），以及计划动作与动态策略的冲突：计划动作会覆盖当前Desired，动态策略随后可能再次调整，因此建议在计划动作前后留出冷却窗口。

五、组合策略与成本判断

实际生产中，四类手段通常组合使用：ASG提供容量边界，混合实例策略降低单位成本，预测性伸缩处理周期趋势，计划伸缩处理已知事件。判断是否有效，可以观察三个指标：平均CPU利用率（是否长期低于30%）、扩容响应时间（是否在负载上升前完成）、Spot中断率（是否频繁触发替换）。若CPU长期偏低且无周期规律，应优先下调Min；若扩容总是滞后，应引入预测性伸缩；若Spot中断频繁，应提高按需比例或增加实例类型。

最后提醒：Auto Scaling不是“配完就忘”的功能。实例类型、Spot价格、业务周期都会变化，建议每月复查一次容量配置与成本报告，确保伸缩策略仍然贴合当前负载。