一粟 · yisu.app
· 13 min read
CDN

CDN 选型与边缘计算的决策框架

并不是最新、最贵的 CDN 就一定好。基于用户分布、内容类型、回源成本做机房画像,再匹配供应商的节点覆盖与协议能力,这套决策框架比「直接对接某大厂」更稳。附三套备选方案的成本对比。

选 CDN 之前,先画「机房画像」

很多人评估 CDN 的第一步是看品牌或价格。结果往往是「最新最美的不是最适合的」。我习惯先做一件事:在内部资料里画一份「机房画像」,描述这次选择的客观约束。

画像包含至少八个维度:

  1. 用户分布:按国家、省、城市分布的活跃用户数。
  2. 内容类型:静态资源(图片/视频)/ 动态 API / 流媒体。
  3. 冷热比例:长尾 vs. 头部内容占比。
  4. 回源成本:每分钟回源带宽上限、平均回源包大小。
  5. 协议能力:HTTP/2、HTTP/3、QUIC、TLS 1.3 支持情况。
  6. 边缘能力:Workers、Functions、WASM 支持。
  7. 安全合规:WAF、DDoS、CC 防护、地域合规要求。
  8. 计费模型:按带宽 / 按请求 / 按存储 / 按边缘函数 GB-s。

把这八条填完,下一步选型就不再凭感觉。

用户分布:决定「节点覆盖」权重

如果你的用户集中在长三角与珠三角,那么「国内大厂 + 国际节点齐备」的 CDN 是合适的。如果你的用户在海外 50 国都有 1 万 DAU,那么更看重「全球 PoP 数」而非任何大厂的「精细化功能」。这是为什么我们曾经为出海业务「完全弃用某国内大厂」。

# 简化版用户分布画像
user_distribution:
  cn-east: 45%
  cn-south: 30%
  cn-north: 10%
  apac: 8%
  other: 7%

content:
  type: streaming_long
  avg_size: 3.2MB
  p50_size: 1MB
  p99_size: 12MB

# 评估指标
required:
  pops: ["apac", "oceania", "africa"]
  http3: yes
  wasm: yes
  waf: yes
  budget_usd_month: 12_000

内容类型:决定「回源模型」

不同内容对 CDN 的压力完全不同:

类型缓存命中收益回源惩罚边缘函数价值
静态图片极高
流媒体分片中(清单合并)
动态 API极高
用户个性化内容极低极高

如果你的内容以动态 API 为主,那么 CDN 的「边缘函数丰富度」「回源连接复用」「智能回源」会成为评估核心。如果大部分是静态资源,那么任何大厂的「命中率」就够用。

边缘函数:别把它当「时髦词」

过去一年我们对边缘函数做了大量生产化尝试。结论是:它在某些场景下是真的能改变架构的:

  • 请求改写:把 mobile/desktop/region 的不同主机名合并到一个节点上处理。
  • 轻量鉴权:JWT 校验、A/B 分流。
  • 聚合请求:合并多个微服务响应。
  • 灰度路由:按特定 header 把新版本试投到边缘。

但是!边缘函数也有一些明确「不宜」的场景:

  • CPU 密集计算(>50ms)。
  • 与中心数据库强耦合的事务。
  • 每次都依赖远端存储的结果合并。
边缘函数是「被滥用最多的云概念」。不要为了炫技而迁移。

成本对比:三种主流选型的数字

2026 年的当下,国内媒体和电商业务常见三种 CDN 选择。我用一个真实流量做粗算:

方案静态带宽月费动态回源月费边缘函数WAF
阿里云 CDN + 函数计算¥0.18/GB¥0.60/GB¥0.13/GB·s按防护包 ¥300/月
Cloudflare Pro / Business$0 (固定费 + 超额)回源不计$0.50/M 请求
自建 Nginx + 多机房流量费(机房间)自研

对于 100TB 月流量业务,三者综合成本相差不大,但「可控性」「SLA」「合规能力」是完全不同的属性。我的判断是:

  • 小团队 / 出海:选 Cloudflare 等全球厂商。
  • 中型团队 / 国内:选阿里 / 腾讯 / 华为。
  • 大型团队 / 复杂业务:自建 + 第三方混用。

避坑:选型合同里的几条隐藏条款

CDN 合同和 SLA 文档里有一些隐藏的代价:

  1. 缓存命中率折扣:有些供应商给出 95% 命中率折扣,但实际能跑到 80%,成本会比预期高。
  2. 跨区域回源:看似便宜,但回源到远端机房时,单次延迟可能飙升。
  3. WAF 误拦:未调通的 WAF 会严重干扰业务。
  4. 缓存预热:大文件预热要额外排队。

正式签合同前,最好把这些条款拿出来研读一遍。

迁移与回滚:上线前的基本动作

CDN 是「一上一下」的「全局件」。错误的切流会让一个事故变成灾害。我的做法:

  • 用 weighted DNS 或 HTTP 302,让流量逐步切。
  • 预热重点路径的缓存。
  • 保留 30% 旧 CDN 的「影子流量」,对比指标。
  • 预案明确到「谁执行、回切 DNS TTL 多少秒」。

看似烦琐,但任何一次「切 CDN 翻车」都会让你明白这些动作的必要性。

边缘计算未来三年的几个判断

我押注的几个趋势:

  • WASM 边缘会取代部分 Workers:跨语言、可移植性更好。
  • 边缘 KV 一致性增强:CRDT 算法进入工业级。
  • 边缘 AI 推理:小模型(小于 1B)会下放到节点。
  • 回源 + 边缘的统一调度:现在的「边缘 + 回源」二段模型会变成「连续调度」。

给团队的简短清单

  • 任何 CDN 选型都先画机房画像。
  • 把内容拆成「静态 + 动态 + 个性化」,分别评估。
  • 不要忽视合同与回滚预案。
  • 边缘函数要有真实场景再上,炫技是大忌。