CDN 技术：这次怎么落地的

边界条件才会告诉你方案能不能留。

最开始网站只有一台云服务器，流量上来之后问题就暴露了：

• 国内不同地区访问延迟差异巨大，用户投诉加载慢
• 晚上 8 点高峰期，源站带宽不够用，页面打不开
• 图片、静态文件这些重复请求占用了大量服务器资源

第一反应是"升级服务器配置"，但很快发现这是个无底洞。

问题是怎么来的

最开始网站只有一台云服务器，流量上来之后问题就暴露了：

• 国内不同地区访问延迟差异巨大，用户投诉加载慢
• 晚上 8 点高峰期，源站带宽不够用，页面打不开
• 图片、静态文件这些重复请求占用了大量服务器资源

第一反应是"升级服务器配置"，但很快发现这是个无底洞。用户多了一倍，资源就得加一倍，成本扛不住。

这时候才想起来：大部分请求其实是在重复获取相同的内容，为什么不就近缓存呢？

CDN 基本原理

CDN 的想法很简单：在各地部署边缘节点，用户访问时直接从最近的节点拿内容，不用每次都跑到源站。

核心价值就是把内容推送给用户，而不是让用户千里迢迢来取。距离近了，延迟自然就下来了。

选型与接入过程

CDN 服务商选择

市面上 CDN 服务商不少，我主要对比了几家：

国内：阿里云 CDN、腾讯云 CDN、七牛云 国外：Cloudflare、AWS CloudFront

最终选了阿里云，原因很务实：

• 节点多，覆盖好，特别是三四线城市
• 调试工具完善，有详细的缓存命中率监控
• 价格合理，按流量计费，适合小站
• 支持自定义域名和 HTTPS 证书

接入步骤

接入其实不复杂，但有几个坑要提前知道：

1. CNAME 配置

DNS 解析那里最容易出问题。服务商给你一个 CNAME 记录，你需要在域名解析那里把你的域名指向它。

# 原来的 A 记录
www.example.com.  A  1.2.3.4

# 改成 CNAME
www.example.com.  CNAME  example.com.cdn.example.com

第一次我直接改了 A 记录，结果网站直接挂了。CNAME 的作用是告诉 DNS：“这个域名的解析交给 CDN 去处理”。

2. 缓存规则配置

缓存规则是核心，配错了会出问题。我一开始把所有东西都缓存了，结果用户下单之后一直看到旧的价格。

# 合理的缓存规则
静态资源：
  - 后缀：js, css, png, jpg, webp, svg, font
  - 缓存时间：30 天
  - 忽略参数：是

HTML 页面：
  - 后缀：html, htm
  - 缓存时间：10 分钟
  - 忽略参数：否

API 接口：
  - 路径：/api/*
  - 缓存时间：不缓存

3. HTTPS 证书

现在的网站不上 HTTPS 基本不行，CDN 支持自带的证书，也可以上传自己的证书。我用了 Let’s Encrypt 免费证书，直接上传到 CDN 控制台就行。

踩过的坑

坑一：缓存未刷新导致更新不生效

第一次上线之后，改了个样式，刷新页面死活不生效。查了半天发现是缓存时间设置得太长，而且没有配置手动刷新。

解决：

• 开发环境关掉 CDN 或设置很短的缓存时间
• 上线新版本后，通过 CDN 控制台手动刷新缓存
• 重要资源用文件名哈希，改内容就换文件名

坑二：回源流量过大

上线第二天发现源站流量没降多少，监控一看，缓存命中率只有 30%。

排查原因：

• URL 里有随机参数，每次都是新请求
• 某些静态资源设置了 no-cache
• 热点内容没有预热，回源请求集中爆发

解决：

# 1. 配置忽略参数
不要把 ?timestamp=123456 这类参数计入缓存键

# 2. 检查响应头
确保静态资源返回正确的 Cache-Control
Cache-Control: public, max-age=2592000

# 3. 内容预热
上线前通过 CDN 提供的预热接口，提前把热点内容推到节点

坑三：跨域问题

部署到 CDN 之后，前端请求开始报跨域错误。

原因是 CDN 节点会缓存响应头，如果源站配置了 CORS 但 CDN 没配置，就会出现问题。

解决：

• 在 CDN 控制台配置 CORS 规则
• 确保 Access-Control-Allow-Origin 正确设置
• 避免使用通配符 *，明确指定允许的域名

效果对比

折腾完之后，效果还是比较明显的：

用户投诉基本没有了，服务器成本也降下来一些。

什么时候不适合用 CDN

CDN 不是万能的，有些场景用了反而更复杂：

小流量网站：如果日访问量不大，CDN 的费用可能比节省的服务器成本还高。

强实时性要求：比如股票行情、游戏数据，这类数据必须实时从源站获取，缓存反而会出问题。

频繁更新的动态内容：如果页面内容每分钟都在变，缓存命中率上不去，CDN 的意义不大。

团队没有运维能力：CDN 接入简单，但调优、监控、排错需要经验。如果团队没有这方面的人，上了反而增加复杂度。

写在最后

CDN 是个好工具，但它解决的是特定问题——通过就近缓存加速内容分发。

用之前先问自己：我的慢是因为距离远，还是因为代码写得烂？

如果是因为代码烂、数据库查询慢、架构设计不合理，上 CDN 只是治标不治本。先把基础打好，再考虑加 CDN。

折腾完 CDN 之后才发现：很多性能问题根本不是加一层缓存就能解决的。先把基础打牢，再上这些工具，效果才会真正出来。

可用性说明：本文发布于 2021 年 3 月，距今已超过五年。文中涉及的软件版本、接口、下载地址、命令参数和操作界面可能已经发生变化，部分方案在当前环境下可能失效。请结合官方最新文档核对后再操作，生产环境使用前务必先行验证。

版权声明: 本文首发于 指尖魔法屋-CDN 技术：这次怎么落地的（https://blog.thinkmoon.cn/post/10-cdn-practice-edge-caching/） 转载或引用必须申明原指尖魔法屋来源及源地址！