CDN 设计深度教程：缓存策略 / 回源 / 边缘计算

CDN 已经从早期的静态文件分发演化成全球边缘计算平台。一个现代 CDN 既要把图片、视频、HTML 推到离用户最近的节点，又要在边缘上做鉴权、A/B 测试、AI 推理、个性化渲染。本文从缓存键、TTL/SWR、Origin Shield、地理路由、边缘函数、DDoS 防护一路深入，再讨论哪些场景不该上 CDN，帮助你在 2026 年做出更聪明的架构决策。

1. CDN 的本质与定位

CDN 的核心是把内容从源站复制到分布在全球的边缘节点，让用户从最近的节点拿到响应。延迟降低、带宽分摊、源站防压、抗 DDoS 是四大基础收益。今天的头部 CDN（Cloudflare、Akamai、Fastly、阿里云、腾讯云、CloudFront）已经覆盖数百个城市、数十万台机器，单一域名背后可能有数千个节点同时服务。

但 CDN 不是免费午餐。它是一个分布式缓存系统，缓存意味着可能返回旧内容；它跨网络运行，意味着回源链路可能比直连更长；它依赖第三方运营商，意味着源站和应用要为可观察性、隐私合规、回源安全付出额外代价。

因此设计 CDN 架构的第一步永远是先回答两个问题：哪些内容值得缓存？错误命中带来的代价能承受吗？

2. 缓存键设计：粒度与命中率

缓存键决定 CDN 如何判断两个请求是否等价。默认键大致是协议加主机加路径，但绝大多数业务都需要扩展。常见维度有：查询参数白名单（保留 page、size，忽略 utm_*）、Accept-Encoding（gzip/br 不同压缩单独缓存）、设备类型（PC vs 移动 vs 平板）、用户语言、地理国家、Cookie 中的 A/B 实验组等。

键越细，命中率越低，存储成本越高；键越粗，命中率高但风险大，可能给 PC 用户返回了移动版页面。良好的实践是清晰列出"哪些维度真的影响响应"，把它们纳入键，其余维度统一忽略或归一化。

现代 CDN 都支持自定义缓存键 DSL（Cloudflare Page Rules、Akamai Property Manager、阿里云 EdgeScript），运维要花时间认真校准。常见错误是把所有 query string 都纳入键，导致命中率惨淡；或没把 Cookie 纳入键，结果 A/B 实验互相串。

3. TTL 与 SWR：双段刷新策略

TTL（Time-To-Live）是缓存的新鲜期。命中且未过期直接返回；过期则要回源验证或拉取新内容。简单的 TTL 模式有个尴尬：恰好缓存过期那一刻所有请求都涌向源站，造成回源风暴。SWR（stale-while-revalidate）解决这个问题。

SWR 给缓存对象设两个时间：fresh 期内直接返回；超出 fresh 但仍在 stale 期内时，先把旧内容返回给用户保证零延迟，再异步发起回源刷新；超过 stale 期才阻塞回源。配合 stale-if-error 还能在源站故障时继续提供旧内容。

2026 年标准做法：HTML 设 TTL 60 秒 + SWR 600 秒，CSS/JS 文件名带 hash 走 1 年永不过期，图片类带 SWR + stale-if-error，API 缓存仅幂等 GET 且 TTL 极短。配合 JSON 格式化工具调试响应头可以快速验证策略是否生效。

4. Origin Shield 与回源优化

全球 CDN 节点上千，如果每个节点缓存独立过期，回源 QPS 会非常分散，源站可能被同一资源轰炸数百次。Origin Shield 引入一层中间节点：所有边缘节点都先去 Shield 节点拿，Shield 才向源站回源。同一个对象只回源一次，再下发到所有边缘。

Origin Shield 的位置选取要靠近源站（通常同区域或同骨干网），减少回源 RTT。对全球流量大、源站性能受限、热门内容集中的场景收益显著。Cloudflare Tiered Cache、Fastly Origin Shield、AWS CloudFront Origin Shield 都属于此类机制。

除此之外还有一些回源优化：Range Request 分块缓存大文件、连接复用与 keepalive、回源压缩（不回源 br，源站只产 gzip 即可）、回源限流防止突发洪水拖垮源站。复杂业务还可以用回源签名 + IP 白名单，避免源站被绕过 CDN 直接攻击。

5. 地理路由与流量调度

把用户请求引导到最近节点是 CDN 的看家本事。常见技术包括基于 anycast 的 IP 路由（Cloudflare 主要用此）、基于 GeoDNS 的 DNS 调度（Akamai、阿里云常用）、基于 EDNS Client Subnet 的精细解析、基于 BGP 的路由优化。

实务中要关注几件事：移动运营商的 GeoIP 信息常常滞后，Wi-Fi 出口 IP 与用户实际位置可能差几千公里；公司 VPN 用户会被解析到 VPN 出口，体验远不如裸奔；中国大陆与海外的网络划分要分别走不同 CDN 套件，避免跨境抖动。

2026 年新趋势是基于实时网络质量的智能调度：CDN 监控用户到各个节点的 RTT、丢包率、错误率，动态把 DNS 应答指向最优节点而不是地理最近节点。Cloudflare Argo Smart Routing、阿里全球加速、Akamai SureRoute 都属于此类。

6. 边缘计算：Workers / EdgeWorkers / 边缘函数

过去 CDN 只能改 Header，今天它可以跑代码。Cloudflare Workers 跑 V8 隔离环境，冷启动约 5ms；Akamai EdgeWorkers 跑 JavaScript 子集；Fastly Compute@Edge 跑 WASM；阿里云边缘 Serverless 提供 JS/Go 多语言；AWS Lambda@Edge 是较重的方案。

边缘函数典型用例：基于 Cookie 的 A/B 测试、URL 重写与 SEO 跳转、机器人流量识别、图片实时调整尺寸/格式、JWT 验证、API 聚合、个性化插值 HTML、AI 模型推理。任何对延迟敏感、计算量小、状态可外置的逻辑都适合放到边缘。

但边缘函数有限制：执行时间通常 50ms 以内、内存几十兆、不能跑长连接、慎用大依赖。重 IO 任务仍应回到区域级 FaaS 或后端服务。可以配合 curl 命令生成器调试边缘函数响应。

7. DDoS 缓解与安全策略

CDN 天然是 DDoS 缓解平台。L3/L4 攻击（SYN flood、UDP reflection）由全球 anycast 网络分散吸收，单个数据中心承受得住几百 Gbps；L7 攻击（HTTP flood、慢速攻击）则通过 WAF、Bot 管理、Rate Limit、人机验证（Turnstile、reCAPTCHA Enterprise）应对。

现代防护流水线大致是：连接层 anycast 分散、SYN cookie 与 SYN proxy 抗洗连、TLS 终结后入 WAF、再入限流与 Bot 评分、最后才到边缘函数与缓存层、缓存未命中才回源。每一层都能尽早阻断恶意流量，源站只看到清洗后的少量请求。

企业实践要点：永远把源站 IP 隐藏（用 Origin Shield 或 ALB），用证书绑定回源校验，开启 Argo Tunnel/Private Link 让源站不开公网入口；监控异常 5xx、流量曲线、缓存命中率突变，作为攻击早期信号。

8. 不该用 CDN 的场景与失败模式

CDN 适合可缓存、可重复、对全球用户开放的内容。下面几类场景应当谨慎或干脆不用：高并发写入接口（金融下单、消息发送）、个性化极高且不可缓存的 API（每次响应都不同）、低 QPS 小流量（命中率低、徒增费用）、私有内网与合规敏感数据（不希望经过第三方）、超大文件单点下载（带宽计费可能比对象存储直链更贵）。

典型失败模式：缓存键设计太宽误命中、TTL 设太长导致内容过期问题、忘了 Vary: Accept-Encoding 导致压缩混淆、源站直接暴露被绕过、回源没有限流被打挂、SSL 证书与 SNI 配错导致部分客户端报错。运维要把这些当作日常巡检项。

最后一点：CDN 不是上线即忘的产品，它需要持续观测命中率、回源量、首字节时间、错误率。把这些指标接入监控仪表盘，遇到上线发布、活动推广、节假日流量峰值才能快速做策略调整。

常见问题

缓存键应该如何设计？

缓存键决定哪些请求被视为相同。最简单的键是 URL，但生产中通常需要加入域名、查询参数白名单、Accept-Encoding、设备类型、地区等维度。键越精细命中率越低、占空间越多；键越粗回源越少但可能返回错误的版本。良好做法是只把真正影响响应的维度纳入键，其他参数显式忽略。

TTL 和 SWR 如何配合使用？

TTL 是新鲜期，SWR（stale-while-revalidate）是宽限期。命中且新鲜直接返回；过期但在 SWR 内则先返回旧内容再异步回源刷新，用户感知零延迟；超过 SWR 才同步回源。这种二阶段策略让首屏时间稳定，同时不放任内容长期陈旧，是现代 CDN 的标配。

Origin Shield 是必须的吗？

Origin Shield 是位于边缘节点和源站之间的中间层，用一组节点统一回源以聚合流量。对于流量大、源站资源紧张、跨地域用户多的服务非常值得；对于低流量站点收益不明显甚至增加延迟。需要根据回源 QPS、源站可承受 QPS 与全球用户分布做权衡。

边缘函数与传统 Lambda 有什么区别？

边缘函数运行在 CDN 节点，距离用户最近，冷启动通常在 10ms 以内甚至零冷启动；Lambda 这类区域级 FaaS 部署在某个云区域，跨区调用要走骨干网。边缘函数适合做请求改写、A/B 测试、轻量鉴权、个性化路由；重 IO、长任务、大依赖仍应放回区域 FaaS 或容器。

哪些场景不应该用 CDN？

强一致性写入（金融下单）、个性化高频更新且不可缓存的接口、低频小文件（缓存命中率几乎为零）、严格合规要求数据不出境的私有数据、内网服务都不适合直接套 CDN。如果硬上反而带来回源延迟、缓存污染、跨境合规风险。先评估是否真的有缓存空间再决定。