弹性伸缩ESS配置：应对流量洪峰
电商大促、在线教育开课、突发热点新闻……这些流量洪峰场景如果准备不足，轻则页面卡顿，重则系统崩溃。阿里云弹性伸缩（ESS）可以根据业务负载自动调整ECS实例数量，帮你平稳度过每一个流量高峰。
「弹性伸缩ESS配置：应对流量洪峰」并不是一个孤立的话题。ECS 实例选型与算力规划同时牵动容量规划、网络划分、弹性伸缩与容灾边界等多个层面，只有把它们当作一个整体来推进，才能避免上线之后反复返工、被动救火。
核心概念
伸缩组：一组具有相同业务场景的ECS实例集合。配置最小实例数、最大实例数、期望实例数，以及关联的SLB和RDS。
伸缩配置：定义自动创建的ECS的规格（实例类型、镜像、安全组、数据盘等）。一个伸缩组可以有多个伸缩配置，ESS会按优先级选择。
伸缩规则：定义伸缩的触发条件和动作。比如"CPU利用率>70%时增加2台ECS"。
伸缩活动：每次扩容或缩容都是一个伸缩活动，可以在控制台查看详细日志。
伸缩模式
定时模式：已知流量规律时使用。比如电商平台每天晚上8-10点是高峰，配置定时任务在19:30扩容5台，22:30缩容。
动态模式：根据监控指标自动触发。配置云监控报警任务作为触发源，当CPU/内存/网络指标超过阈值时自动伸缩。适合流量不可预测的场景。
固定模式：手动调整期望实例数，立即执行伸缩。适合紧急扩容。
最佳实践
伸缩组的ECS加入SLB后端后，新创建的实例会自动接收流量。但应用需要时间启动和预热（如加载缓存、建立数据库连接），所以配置预热时间（InstanceWarmup），在预热期间新实例不会被计入伸缩指标计算。
缩容策略建议选择"优先移除最早创建的实例"，保证运行时间长的实例被优先替换。配合SLB的健康检查，确保缩容时不会移除正在处理请求的实例。
使用启动模板而非启动配置，可以支持更多高级特性（如GPU实例、抢占式实例）。混合使用按量实例和抢占式实例可以进一步降低成本。
落地前的自检清单
- 容量与规格：是否用真实压测数据而非经验估算来定规格，是否预留了弹性空间。
- 网络与边界：网段划分是否留有扩展余地，安全组是否遵循最小开放原则。
- 弹性与容灾：扩缩容策略是否经过演练，故障切换路径是否清晰、可回退。
- 可观测性：关键链路是否有指标、日志与告警覆盖，出问题能否快速定位。
这四件事做到位，ECS 实例选型与算力规划才算真正「落地」，而不是停留在方案文档里。
把ECS 实例选型与算力规划放回架构全局来看
单点的最优解，叠加起来未必是全局最优。评估ECS 实例选型与算力规划时，建议先明确业务的峰值模型与故障容忍度，再倒推资源与网络该怎么设计：哪些负载是稳定基线、哪些是突发流量、哪些可以容忍短暂中断，答案不同，架构取向也完全不同。
在此基础上再谈规格与参数，才有意义。否则很容易陷入「先买资源、再找用途」的被动局面，成本与复杂度都会随之上升。