流量突然上涨时，先让边缘节点接住可缓存的请求，再由负载均衡器把必须访问源站的请求分配到健康后端。内容分发网络与云负载均衡协同处理突发访问的架构，重点不是让两个组件重复做同一件事，而是减少源站压力并控制剩余流量。
先分清两层各自负责什么
CDN 将图片、样式文件、脚本等内容缓存到靠近用户的边缘节点；请求命中缓存时，通常不必回到应用服务器。动态请求或缓存未命中的请求，则转发至源站。云负载均衡器位于源站入口，将这些请求分配给多个后端，并通过健康检查避开异常实例。
例如，Amazon CloudFront 可以作为边缘分发层，AWS Application Load Balancer（ALB）接收回源流量，再将请求转给相应目标组。ALB 处理应用层路由和后端分配；它不能替代 CDN 缓存，也不能自动消除应用本身的容量限制。这样的分工构成了内容分发网络与云负载均衡协同处理突发访问的架构。
突发时，瓶颈往往出现在回源链路
促销页面带来的请求并非都能缓存。商品图片通常适合缓存，而购物车、账户信息、库存变化和提交订单等内容往往需要动态处理。若把个性化响应误设为共享缓存，可能返回错误内容；若所有请求都绕过缓存，源站又会承受不必要的压力。
因此要关注缓存命中率和源站回源量，并检查缓存键是否包含必要的查询参数、Cookie 或请求头。只把确实影响响应内容的字段纳入缓存键；不应缓存的路径则明确设置为转发至源站。具体规则需结合应用行为验证，不能只按文件后缀判断。
上线前按步骤准备
- 划分请求类型：列出静态资源、可缓存页面和必须动态处理的接口，逐条确认缓存策略与过期时间。
- 配置源站入口：将 CDN 的源站指向负载均衡器，而不是单台实例；设置目标组、健康检查路径和合理的超时参数。
- 准备扩容策略：后端可通过自动扩缩容增加实例，但新实例启动、加载数据需要时间。按应用的启动速度和负载特征设置阈值，并预留容量，不要等到请求排队后才扩容。
- 保护回源服务：配置访问控制、限流和应用防护规则，避免异常请求绕过 CDN 直接冲击源站。确保源站访问策略允许 CDN 回源，同时限制不必要的公网入口。
- 进行渐进演练：在测试环境逐步增加并发，观察负载均衡器请求数、后端响应时间、错误率和扩容耗时；再验证缓存清理、健康检查失败及实例恢复流程。
选型与故障边界
以 ALB 这类七层负载均衡器为例，它适合按域名或路径分流 HTTP 应用；四层负载均衡器更侧重 TCP、UDP 连接转发，适合需要传输层处理的服务。选哪一种，取决于协议和路由需求。无论使用哪种，负载均衡器只负责分配连接或请求，后端数据库、缓存服务和应用线程池仍可能成为瓶颈。
单区域架构较易管理，但区域级故障时仍可能整体不可用；多区域部署可增加故障切换能力，却需要处理数据一致性、会话和流量切换策略。对大多数系统，应先把单区域的缓存规则、扩缩容和回源保护做扎实，再按可用性目标评估跨区域方案。内容分发网络与云负载均衡协同处理突发访问的架构，最终效果取决于整条链路，而非单一产品。
常见问题
CDN 能代替云负载均衡吗？
不能完全代替。CDN 擅长边缘缓存和内容分发；动态请求仍需由源站入口分配到可用后端。
动态页面能不能缓存？
可以评估短时缓存，但要先确认内容是否因用户、权限或实时数据而不同，并谨慎设置缓存键和有效期。
开启自动扩缩容后就不需要压测了吗？
仍需压测。扩容存在启动延迟，而且数据库等依赖服务未必能同步扩展，演练可提前发现这些限制。
流量上涨时应先扩容还是先调缓存？
先确认请求组成和瓶颈：可缓存内容优先检查缓存策略；动态请求过多则检查后端容量与依赖服务，再按结果扩容或限流。
