本文是 CDN 系列的架构篇。原理篇《CDN 技术体系：从分发原理到工程落地》解释调度与缓存机制，实战篇《CDN 接入与运营实战》说明配置和验证。本篇关注选型前的问题：业务究竟需要什么分发能力，哪些差异值得增加系统复杂度？
以一个准备拓展海外市场的内容社区为例，我们需要同时服务公开文章、图片、前端资源和登录接口。选择 CDN 的依据应是这些请求的访问分布、响应语义和恢复目标，而不是给供应商按印象排名。
从流量和业务承诺形成需求
请求量、字节量和业务重要性是三种不同口径。图片可能占大部分字节，API 却占大部分请求；一个流量很小的支付接口，也可能比大量公开图片更需要严格保护。
| 需要收集的事实 | 影响的决策 |
|---|---|
| 各类内容的请求数、字节数与大小分布 | 请求计费、流量计费、压缩与分片 |
| 用户地域、运营商、终端和访问时段 | 节点覆盖、调度及性能分组 |
| 更新频率与允许的最大陈旧时间 | TTL、验证、Purge 与版本化 |
| 登录态、权限与内容协商维度 | 共享缓存边界、缓存键、鉴权位置 |
| 突发流量、缓存冷启动和源站容量 | 中间层、准入限制和预热 |
| 故障期间允许的业务行为 | 多源站、多 CDN、降级与切换 |
新产品缺少数据时，可以使用明确标记的假设做初步估算，再通过试流量修正。不能把“社区通常 65% 带宽为静态”当成当前业务的事实，更不能据此直接推导必须上两家 CDN。
性能目标应按业务与地域给出。例如公开文章的首次可见内容、图片完成时间、登录 API 的错误率，各有不同意义。缓存 HIT 的边缘处理时间不能代表包含 DNS、建连和终端渲染的用户体验。
划清分发系统中的职责
DNS 或流量管理系统选择入口；CDN 缓存可复用响应并代理其他请求；Origin Shield 聚合回源；源站负责权威业务状态。这些能力可以由不同产品组合，不要求所有系统采用相同层数。
WAF、鉴权和限速也可以出现在多个位置，但需要确定权威执行点。边缘验证 Token 可以提前拒绝无效请求，业务对象级权限仍应与实际数据一致。把“复杂业务权限”全部交给源站前的一层通用 WAF，并不能替代应用授权。
边缘计算应围绕已测得的收益选择。靠近用户的改写或计算可能降低等待，但状态访问、运行限制、发布回滚和可移植性也需要纳入设计。能够放到边缘，不表示一定应该迁移。
中间层与源站容量一起设计
Origin Shield 在重复未命中、跨区域回源或源站计算昂贵时可能有效。决定是否启用，应比较增加的一跳、命中机会、请求费用和源站保护效果，没有通用的“五十个节点”或“一亿请求”门槛。
源站应覆盖需要回源的业务及可接受的故障场景。平时只有 5% 请求回源，不代表源站只需准备总峰值的 5%；发布、批量失效和缓存策略错误都可能改变这一比例。不能承受全量时，应设计限流、有界排队或允许范围内的旧内容响应。
内容策略围绕可共享性和新鲜度
| 内容 | 默认起点 | 需要验证 |
|---|---|---|
| 带内容哈希的 JS/CSS/字体 | 长新鲜期、immutable | 新资源先发布，旧版本保留 |
| 公开文章和入口 HTML | 根据更新目标选验证或短 TTL | 发布、列表页与入口的失效链路 |
| 公开 UGC 图片 | 对象版本化或短 TTL 加失效 | 可见性变化、删除与浏览器旧缓存 |
| 公共榜单与公告 | 业务允许时短 TTL 或 SWR | 最大陈旧时间与更新失败行为 |
| 个人消息、购物车 | 默认不做共享缓存 | 身份隔离、no-store 与规则覆盖 |
版本化适用于构建产物，也适用于 UGC。上传新图片时创建新对象 ID 或版本路径，再更新业务引用即可。旧 URL 继续表示旧对象；如果要求立即禁止访问，仍需独立的鉴权和撤销策略。
max-age=31536000 是一年新鲜期，不是永不过期，也不保证对象一直驻留在 CDN。浏览器、边缘和源站各有缓存与版本边界，发布方案必须贯穿这些位置。
Purge、短 TTL 与 SWR 也不是互斥的选项。选择组合时先回答能否继续提供旧内容；涉及权限撤销或错误价格时，不能只追求更高命中率。
全球化：服务覆盖与数据处理分开核对
同一供应商品牌可能有不同网络、运营主体、合同和控制面。不能把“全球产品默认配置”与“该厂商全部地区的服务能力”混为一谈。
Cloudflare 提供单独的 China Network，不能写成在中国大陆完全没有节点。CloudFront 在中国也有由本地运营方提供的独立服务，接入与账户条件应分别核对。是否适合当前业务，还需测量覆盖、产品功能和合同条件。Cloudflare China Network、Amazon CloudFront 中国服务
使用中国大陆加速服务时，应按服务商的接入要求核对域名备案等条件；备案和数据跨境要求是不同问题。个人信息与重要数据出境取决于主体、数据类型、规模、用途及适用机制，不能概括为“所有大陆用户数据都不得出境”。促进和规范数据跨境流动规定
GDPR 也不是“欧盟数据一律不能进入美国”。第三国传输可以涉及充分性决定、适当保障或特定例外；边缘节点在欧盟，不代表日志、管理访问、密钥和分包处理全部位于欧盟，更不自动完成合规。欧盟委员会国际数据传输说明
落实到架构，应列清请求正文、Cookie、IP、日志、源站数据和备份分别经过哪里，由谁处理。GeoDNS 只是调度工具，解析器位置、ECS 与缓存都影响精度，不能单独作为数据地域边界。
单 CDN、多 CDN 与多地域源站
先比较单供应商的实际方案是否满足目标。只有覆盖、故障恢复、合同或成本收益足以抵消运维复杂度时，再引入多 CDN；全球化不天然要求两家供应商。
多 CDN 需要统一内容版本、缓存键、鉴权、证书、失效和指标。备用 CDN 还应保持可接管容量与配置，切换后的冷缓存回源也要测试。两家供应商若共享同一个 DNS、源站或控制流程，仍有共同故障点。
多地域源站则是另一项决定。只读静态内容可以从一个权威发布源复制，不需要多写冲突协议；业务写入如果分布在多个地域，才需要进一步明确数据所有权和一致性。不能为了减少一次静态资源回源，顺带引入不必要的多主数据库。
供应商选型以同一负载比较
产品清单只做候选发现。验证阶段使用相同资源、地域、时段和协议，分别观察冷缓存与热缓存、首次建连与连接复用、正常和故障恢复。
| 维度 | 具体证据 |
|---|---|
| 用户体验 | 分地域与运营商的真实用户数据及拨测 |
| 缓存行为 | Cookie、Authorization、Vary、Range、失效和错误响应测试 |
| 恢复能力 | 目标故障下的切换、重试、冷缓存和源站保护 |
| 运营能力 | API、日志时延、变更审计、证书和工单响应 |
| 商务条件 | 实际地域流量、请求、附加功能与承诺量报价 |
| 迁移成本 | 缓存规则、边缘代码、签名格式和配置导出 |
标准 HTTP 语义降低了迁移成本，却不代表零迁移。不同 CDN 的默认规则、头处理和计费范围依然可能不同。不要用没有测试依据的星级表、固定“最强”排名或不同套餐的起步价格替代这张证据表。
TCO：先统一单位，再计算收益
下面用假设价格演示模型，不是供应商报价。假设每月向用户交付 100 TB，采用十进制 1 TB = 1000 GB，CDN 流量价 0.17 元/GB，源站出口价 0.8 元/GB。进一步简化为回源字节量等于交付字节量乘未命中比例，暂不计重试、预热和再验证。
| 字节命中率 | CDN 交付费 | 回源量 | 源站出口费 | 两项合计 |
|---|---|---|---|---|
| 90% | 17000 元 | 10 TB | 8000 元 | 25000 元 |
| 95% | 17000 元 | 5 TB | 4000 元 | 21000 元 |
| 99% | 17000 元 | 1 TB | 800 元 | 17800 元 |
在这些假设下，从 90% 提高到 99% 节省 7200 元，CDN 向观众交付的字节量并没有减少。若用请求命中率代替字节命中率，或把十进制 TB 与 1024 换算混用，就会得到错误账单。
完整 TCO 还包括请求费、Shield、图片处理、边缘计算、安全功能、跨区复制、源站计算与维护人力。峰值、95 分位带宽和按流量计费是不同合同模式，应将同一段实际流量轨迹代入计算。
优化优先级也由数据决定：图片尺寸与格式可能减少实际交付字节，缓存键优化主要减少重复回源，多 CDN 可能降低报价却增加固定成本。没有测量时不承诺固定节省百分比。
从观察到决策，避免把症状当根因
监控需要同时覆盖用户、CDN 和源站。RUM 接近真实终端体验，但受采样、浏览器 API 和上报成功率影响；拨测提供可控的地域与网络比较，两者互补。
Web 的 Core Web Vitals 使用 LCP、INP、CLS，FID 已被 INP 替代。它们描述加载、交互和布局体验，不能全部归因于 CDN；应用 JavaScript 执行同样可能是瓶颈。INP 指标说明
| 观察 | 后续有区分度的检查 |
|---|---|
| 命中率下降 | 区分发布冷启动、长尾变化、策略绕过和缓存键分裂 |
| 边缘 TTFB 升高 | 比较 HIT/MISS、用户网络、节点处理与连接阶段 |
| 回源失败 | 分别核对 DNS、TLS、网络、源站响应和规则变化 |
| 某运营商慢 | 比较实际入口与同地区其他网络，而非只看节点地图 |
| 费用升高 | 拆成交付字节、请求、附加功能和地域价格变化 |
告警既要围绕用户影响，也要覆盖即将耗尽的源站容量等可行动风险。固定“命中率低于 85%”不适合所有内容，阈值应基于正常分布、业务目标和处理动作。
最终的架构输出，应是一组可以验证的决定：哪些内容共享，允许多旧，经过哪些网络与处理主体，失效如何完成，故障由谁接管，成本按什么口径计算。这样新增市场、增加供应商或调整流量时，团队有明确依据，而不是每次重新凭印象选型。