当业务流量突然飙升，比如促销活动或热点事件，应用服务器往往瞬间被请求淹没。此时，负载均衡与弹性伸缩的组合是应对流量突增的关键架构。负载均衡将流量分发到多个后端实例，而弹性伸缩根据负载自动调整实例数量，两者协同，才能既保证可用性又控制成本。本文以一个典型的电商秒杀场景为例，讲解如何一步步构建这样的系统。
场景：一次促销带来的流量洪峰
假设你的电商平台即将在 10:00 开始限时抢购，预计流量会是平时的 10 倍。如果只靠固定数量的服务器，要么在高峰期过载，要么在低谷期浪费资源。弹性伸缩的价值就在于：它能根据实时负载自动增加或减少 EC2 实例，正如 AWS 文档所述，EC2 提供了按需、可扩展的计算容量，你可以根据需要启动任意数量的虚拟服务器，并在流量增加时扩展容量，在流量下降时缩减容量。
第一步：设计弹性伸缩组
首先，你需要创建一个弹性伸缩组（Auto Scaling Group），它定义了最小、最大和期望的实例数量。例如，设置最小为 2，最大为 20，期望为 5。然后，配置启动模板，指定 AMI、实例类型、安全组等。这里的关键是选择合适的实例类型，AWS 文档指出，每种实例类型在计算、内存、网络和存储资源方面有不同的平衡，你需要根据应用是 CPU 密集型还是内存密集型来选择。
第二步：配置负载均衡器
负载均衡器是流量的入口，它将请求分发到后端的 EC2 实例。你可以使用 Application Load Balancer (ALB) 或 Network Load Balancer (NLB)。将负载均衡器与弹性伸缩组关联后，新启动的实例会自动注册到负载均衡器，退出时自动注销。负载均衡器还提供健康检查，自动移除不健康的实例，确保只有健康的实例接收流量。
第三步：制定伸缩策略
弹性伸缩策略决定了何时扩容或缩容。常见的有基于 CloudWatch 指标的策略，比如 CPU 利用率超过 70% 持续 5 分钟，则增加 2 个实例；低于 30% 持续 15 分钟，则减少 1 个实例。你也可以使用目标追踪策略，直接指定 CPU 利用率为 50%，系统会自动调整。注意，策略的冷却时间（Cooldown）很重要，它可以防止频繁伸缩导致的抖动。
第四步：利用缓存减轻源站压力
在流量突增时，即使弹性伸缩快速扩容，源站也可能承受巨大压力。此时，CDN 缓存可以大大减轻负载。Cloudflare 的缓存文档指出，缓存将频繁访问的内容（如图片、视频或网页）存储在离用户更近的数据中心，从而减少源服务器负载并提高性能。你可以配置缓存规则，指定哪些资源需要缓存以及缓存时长，还可以使用 Tiered Cache 优化内容传递。这样，大量静态请求被 CDN 拦截，源站只需处理动态请求，弹性伸缩的压力也大大降低。
第五步：安全与权限控制
弹性伸缩涉及自动创建和销毁实例，因此安全至关重要。AWS 安全支柱强调，需要遵循安全最佳实践。确保你的启动模板使用最小权限的 IAM 角色，安全组只开放必要的端口。负载均衡器应配置 HTTPS 和 WAF 规则，防止恶意流量。此外，对弹性伸缩组设置 CloudTrail 日志，以便审计。
典型误区与失败条件
在实践中，有几个常见误区：1）只配置扩容策略，忽略缩容，导致成本失控；2）伸缩策略过于敏感，频繁启停实例；3）没有预先配置足够的实例类型配额，导致扩容失败；4）健康检查配置不当，误杀正常实例。务必在测试环境模拟流量突增，验证伸缩逻辑。
总结
结合负载均衡与弹性伸缩，是应对流量突增的可靠方案。通过合理设计伸缩组、配置负载均衡、利用缓存，并注意安全与成本，你可以构建一个既能应对洪峰又不会浪费资源的系统。记住，弹性伸缩不是一劳永逸，需要持续监控和调整。
参考资料
延伸阅读