弹性伸缩：从固定规格到按量扩缩容的实操要点

固定规格的服务器最容易两头浪费。按峰值买，平时大半资源闲置，账单常年偏高；按均值买，活动一来就排队超时，用户先感受到卡顿。弹性伸缩要解决的不是“机器够不够”，而是“机器数量能不能跟着负载走”，让容量在需要时自动长出来，在空闲时自动缩回去。

一、先定伸缩的依据，再谈策略

伸缩组要先回答三个问题。第一，看什么指标：CPU 是最常用的，但对 IO 密集型业务，请求队列长度、平均响应时间或每实例并发连接数往往更准，单看 CPU 容易在数据库先瓶颈时误判。第二，阈值定多少：扩容阈值要留出余量，比如 CPU 持续 5 分钟高于 70% 再扩；缩容阈值要明显低于扩容阈值，两者之间留出缓冲带，避免在临界点反复横跳。第三，冷却时间设多长：一次扩容后要等新实例真正接管流量再评估，冷却太短会连续扩出多余实例，冷却太长则高峰期反应迟钝。

二、三种策略各有适用场景

定时伸缩适合规律明确的业务，比如工作日白天流量高、夜间低，提前把实例数抬上去，比等指标触发更快。动态伸缩适合波动不可预测的业务，指标触发后自动扩缩，关键是阈值和冷却要调好，否则就是在高峰期反复折腾。步进伸缩适合负载陡增的场景，指标偏离越大，一次扩的步子越大，避免一次只加一台、追不上峰值。三种策略可以叠加：定时打底保证基线，动态兜底应对突发，步进处理陡增，组合起来比只用一种更稳。

三、扩容之前，先确认应用能不能横向扩展

伸缩的前提是应用本身可横向扩展。无状态服务最容易，实例加进来就能分流；有状态服务要先处理会话问题，会话存在本机内存里，新实例接管后用户会被迫重新登录，解决办法是会话外置到缓存或数据库，或者用负载均衡的会话保持，但后者会削弱分流效果。数据库同样是瓶颈：应用实例翻倍，连接数和查询量也跟着翻倍，连接池、读写分离和慢查询治理要先到位，否则扩出来的实例只会更快地把数据库打满。启动速度也要同步考虑，镜像过大、启动过慢，新实例还没就绪高峰可能已过。

四、缩容要比扩容更谨慎

扩容失败影响的是体验，缩容失误影响的是可用性。缩容时要先摘流量再关机，让负载均衡把已有连接排空，而不是直接终止实例导致请求中断。缩容节奏要慢于扩容，比如扩容 5 分钟评估一次，缩容可以 15 分钟评估一次，并且设置最小实例数保底，核心服务任何时候都不缩到零。另外要区分“缩容”和“关停”：夜间低峰可以缩到最小实例数，但不要把有定时任务、长连接或后台消费者的实例一并关掉，先确认哪些实例承载了不能中断的工作。

五、一份最小可用的检查清单

伸缩指标已选对，不只看 CPU；扩容与缩容阈值之间留有缓冲带，冷却时间已按实测调过；应用无状态或会话已外置，数据库连接池和慢查询已治理；缩容先摘流量再关机，最小实例数已设保底；定时与动态策略已组合，基线与突发都有覆盖。五项全过，弹性伸缩才算从“能自动加机器”变成了“按量花钱、峰值不垮”。

弹性伸缩的目标不是机器越多越好，而是容量刚好够用。指标、阈值、冷却、应用状态和缩容节奏五处调到位，固定规格的两头浪费才能真正省下来。