前年双十一，我守着朋友的电商小站。晚上九点流量准时起来，我盯着监控屏幕，手指悬在"购买 ECS"按钮上随时准备手动加机器——那晚我们加了三次，每次都是客户先发现卡，我们后知后觉买机器，机器还没初始化完，高峰已经过了。
去年同一个站，我啥也没干。晚上九点流量起来，伸缩组自己从 2 台涨到 6 台；凌晨两点流量退了，机器自己缩回去。我全程在看剧。
这篇就把弹性伸缩 ESS 讲明白：它怎么知道什么时候加机器、四种伸缩规则怎么选、以及配错了会闹出什么笑话。
一、ESS 是个"包工头"，不是"机器"
先纠正一个常见误解：ESS 自己不提供算力，它是调度算力的包工头。你给它一个伸缩组，告诉它"用这个镜像、这个规格"，它按规则决定什么时候开 ECS、什么时候关 ECI、什么时候缩。ECS 库存紧张时还能通过资源预定提前锁定实例，防止该扩容时扩不上来——这个能力 2025-07 上的，专治"扩容失败"。
伸缩组的核心配置就三样：
| 配置 | 作用 |
|---|---|
| 伸缩配置 | 用什么镜像、什么规格、什么安全组 |
| 最小/最大实例数 | 弹性的边界，兜底不能破 |
| SLB/RDS 关联 | 新机器自动挂上负载均衡和白名单 |
第三项是懒人福音：自动配置 SLB 与 RDS 访问白名单，新机器起来自己入队，不用你再登控制台点半天。
二、四种伸缩规则，别只会一种
ESS 支持定时、目标追踪、步进、简单告警四类规则，还能混合调度。我按好用程度排个序：
目标追踪（最推荐）：你只说"CPU 保持在 50%"，它自己算该开几台。适合波动有规律但幅度摸不准的业务——90% 的场景用这一个就够。
定时伸缩：晚九点到十二点固定 6 台。适合规律极强的业务，比如我知道每晚有推送任务。规则简单、可预测，缺点是不管实际流量，到点就扩。
步进伸缩：CPU 到 70% 加 2 台，到 85% 加 4 台。适合对响应速度敏感、愿意多花点钱买余量的场景。
简单告警伸缩：CPU 过线就加一台，最原始也最容易误判——尖峰一来就连加三台，峰过了再一台台缩，钱就这么烧的。
三、垂直伸缩：被低估的一个能力
除了水平加机器，ESS 还能做垂直伸缩：按计划或基于云监控指标，自动调整按量付费 ECS 的 vCPU 和内存规格。业务高峰自动升配、低峰自动降配。
什么时候用垂直？有状态服务最合适——比如数据库、缓存，你没法靠加机器分摊单连接压力，但升配是真管用。无状态的 Web 层优先用水平伸缩，两个不冲突，可以混着来。
四、三个坑，都是我朋友交过学费的
坑一：没配冷却时间。扩容是有时延的（开机、挂 SLB、健康检查，三五分钟），伸缩规则如果"看一眼 CPU 高就加一台"，这几分钟里能连续触发好几次，最后多开一倍机器。冷却时间必须配，给扩容留出生效窗口。
坑二：最小实例数设成 0。看起来省到极致，其实凌晨第一次请求来了再开机，用户对着白屏等三分钟。留 1~2 台常驻，把冷启动成本摊在平时。
坑三：缩容比扩容快。默认策略下缩容动作往往很果断，半夜流量一掉直接砍到底，第二天早高峰又得重新预热。缩容可以更保守一点——同样用目标追踪，缩容目标比扩容目标设低一档。
五、成本估算：动手前先算账
ESS 控制台里有个资源成本估算功能，执行伸缩前可以对不同实例规格、计费模式、磁盘带宽组合做费用预估。搭配按量 + 抢占式实例组合交付（竞价实例跑无状态任务，成本能砍一半以上），弹性伸缩"该省的省、该花的花"这个承诺才算真落地。
最后给个直白的建议：只要你业务的流量有明显的峰谷规律，就用 ESS。朋友那个站上了伸缩之后，去年双十一的资源成本比前年手动加机器还低了三成——同样的钱，买的是睡得着觉。
如果你的服务也卡在"平时浪费、高峰崩溃"的两难里，可以去弹性伸缩产品页看看，先拿一个非核心的伸缩组试跑一周，比看十篇架构文都管用。
