一个人要不要自建CDN？从99CDN企业版看可行条件与运维边界

“要不要自建 CDN”这是一个很值得反复讨论的问题尤其是当你只有一个人维护整套网络服务的时候。我这次以 99CDN 企业版为切入点完整走了一遍从部署边缘节点、接入源站到多区域访问测试和异常排查的流程。先说结论自建 CDN 不是不可行但它的可行建立在几个非常具体的条件之上。如果你只是想省钱或者觉得商业 CDN 太贵那自建未必能让你省心反而可能把成本转移到运维和排障上。但如果你要的是可控性、可观测性和对缓存策略的完全掌握那这种尝试就值得做。一个人做网络服务最容易产生的错觉是“工具越大越好”。CDN 就是这样一套体系单看概念并不复杂让用户从离自己更近的节点拿资源减少回源压力和访问延迟。可真要自己搭起来就会遇到一系列和概念无关的问题节点怎么选、回源怎么设计、缓存怎么失效、证书谁来续期、源站 IP 怎么藏。这些问题每一个都不至于难倒一个人但它们叠加在一起会吃掉你大量本应用来写业务的时间。这也是为什么我更愿意把这次尝试理解为不是“自研 CDN”而是“用成熟方案做一套自己能控制的网络分发系统”。1. 先想清楚你需要的到底是 CDN还是一次流量链路改造1.1 为什么一个人也会想自建 CDN商业 CDN 已经很成熟了按量付费、全球节点、智能调度、安全防护看起来什么都不缺。但真到某些业务场景里商业 CDN 给的是一套标准服务你只能在默认规则里做选择。比如缓存规则不够细、日志保留时间短、回源行为不透明、某类请求被平台策略限制。对普通业务来说这些不是问题可一旦你的业务对访问链路、资源更新时效、日志留痕有特殊要求商业产品的边界就会变得很明显。我这次尝试 99CDN 企业版背景也很简单想做一套能自己控制边缘节点、自己决定缓存策略、回源链路完全可查的 CDN 服务。不是从零写调度和缓存而是用企业版方案把 CDN 常见能力打包起来部署到自己的机器上。这个定位很重要因为它决定了整件事的难度。如果你以为自建 CDN 就是自己写一个 Nginx 加缓存模块那后续的证书、监控、刷新预热、异常流量处理都会变成无底洞。成熟方案的价值就是把这些工程能力先兜住让你把精力放在配置和测试上。1.2 判断真需求的三条标准在动手之前我一般先问自己三个问题我是不是对回源链路、缓存规则、节点位置有明确的控制需求我是不是需要把日志、访问记录、源站响应数据完整保留下来我是不是能接受一个需要自己盯监控、自己处理证书、自己维护节点状态的系统如果三个问题的答案都是否那就别自建。直接用商业 CDN按量付费出现问题找服务商从成本和时间上都是更优选择。如果至少前两条成立自建 CDN 才有讨论价值。很多人一开始只是想省钱结果搭完之后发现为了省那点流量费自己多付出了十倍的时间成本。这是自建 CDN 最常见的“假需求”。1.3 一人团队的技术边界一个合格的 CDN 系统拆开看至少包含这些部分DNS 调度、边缘节点、缓存层、回源策略、健康检查、日志与监控、刷新预热、HTTPS 证书管理、安全防护。一个人全部从零实现不是不可能但从工程回报率看非常不划算。真实 CDN 的难度通常不在“缓存怎么存”而在“缓存怎么失效”“回源异常怎么降级”“证书过期怎么避免”“用户看到的到底是哪个节点”这类细节上。所以“自建 CDN”这四个字对一人团队来说更准确的理解是“自建 CDN 服务”用开源方案或企业版产品把控制端、节点、源站组合起来形成一套自己可管理的体系。这样你拥有的是流量链路的控制权而不是把所有软件都写一遍。99CDN 企业版这类方案本质上就是帮你完成“组件组装”把 CDN 常用的控制台、节点接入、缓存规则、证书配置等能力集成好。你需要做的是理解底层逻辑然后把配置调对。2. 搭建之前先把四个基础问题定下来2.1 节点规划你的 CDN 覆盖到哪里CDN 的价值在于“离用户更近”。如果你只有一个边缘节点而且这个节点和源站还在同一个机房那它本质上是一个带缓存的 Nginx 反代不能算 CDN。对一人团队来说最合理的起步方式是先有一个源站再根据用户分布选一到两个边缘节点。用户主要集中在华东边缘节点就放华东用户分散就至少放两个区域。节点不是越多越好因为每多一个节点你就多一台机器要维护多一层日志要看多一个证书要处理。如果你刚开始只能部署一个节点也不必觉得没有意义。先把单边缘节点跑通验证回源、缓存、刷新、证书这一套流程是否正常再慢慢加节点。这是一个从“单点缓存”走向“区域分发”的过程不要一上来就追求全国甚至全球覆盖。对一个人来说能稳定的节点比看起来漂亮的节点地图重要得多。2.2 回源链路缓存未命中时源站能不能扛住自建 CDN 最容易忽略的是回源设计。用户第一次访问某个文件边缘节点没有缓存就会回源站拉取。如果回源链路设计得不好并发一高源站瞬间被打挂。回源方式一般有 HTTP 回源、内网回源、对象存储回源。个人或小型团队最常见的是 HTTP 回源边缘节点通过公网或内网向源站发起请求拿到资源后缓存到边缘节点再返回给用户。这里要注意回源 Host 和回源超时。回源 Host 填错了源站上的虚拟主机无法识别请求会返回错误页面回源超时设置太短大文件还没拉完就断掉用户就会看到 502。实际操作中我会先确认源站自己的访问路径是正常的再配置回源地址和回源 Host。回源链路是不是通比边缘节点本身更能决定用户能不能拿到内容。如果你发现自建 CDN 后访问速度反而变慢第一步不是调缓存参数而是看回源请求是不是因为超时被反复重试。2.3 缓存规则不是所有资源都适合长缓存缓存规则是自建 CDN 配置里的核心也是最容易出错的部分。很多人以为缓存时间越长越好实际上要分资源类型。如果 HTML 页面被缓存七天你发布新版本后用户只能看到旧页面如果接口被缓存用户数据实时性就没了。下面这个判断表是我在实际配置里经常用的基准具体时间要结合业务调整。资源类型建议缓存时长注意点HTML 页面60 秒到 10 分钟或不做缓存长缓存会导致发布后页面不更新CSS / JS7 天版本变化时建议修改文件路径参数图片 / 小文件7 到 30 天内容更新频繁的图片要单独缩短时间音视频 / 大文件30 天以上配合 Range 回源避免二次加载API 接口一般不缓存如果确实需要控制在 5 秒内自建 CDN 之后你会慢慢理解一个词叫“缓存命中率”。命中率高回源少源站压力小访问速度也稳定命中率低说明你的缓存规则和业务不匹配。对静态资源为主的站点命中率应该能到 90% 以上如果大量请求都是动态接口CDN 能发挥的空间本来就有限。2.4 域名与证书最容易被忽略的前置条件自建 CDN 需要至少两个域名视角用户访问的加速域名以及源站域名。加速域名建议独立设置比如cdn.example.com不要和源站域名混用。这样方便以后切换 DNS、调整证书、做灰度验证。HTTPS 证书最好由边缘节点统一处理边缘节点和源站之间可以走内网或 HTTP。好处是证书只维护一份用户侧看到的是完整 HTTPS 链路回源环节少一层 TLS 开销。证书问题是自建 CDN 最典型的事故来源。商业 CDN 会自动帮你续期自建方案里这个动作很容易被忘掉。我建议从第一天就把证书自动续期配置好不要用手动续期的方式否则半年后一次证书过期就会让整个站点出现“浏览器打开不安全”的尴尬局面。域名解析 API 权限也要提前准备好因为后面做 DNS 切换、自动签发证书都会用到。3. 以 99CDN 企业版为例把最小闭环跑通3.1 部署前需要准备的环境我这次尝试 99CDN 企业版省去了很多从零组装的工作但前置环境还是要准备干净。一个比较稳妥的配置是这样的一台源站服务器跑你的实际业务建议至少 2 核 4G带宽根据业务量评估。至少一台边缘节点服务器磁盘容量要留足因为缓存文件会持续增加。一个可以解析的域名并有 DNS 管理权限。一个可用的 HTTPS 证书或者支持自动签发证书的方案。管理端口和防火墙规则控制端、节点之间的通信端口要先确认别装完才发现互相访问不了。这里有一个很容易踩的坑不要在你的源站机器上又跑数据库、又跑缓存、又跑 CDN 控制端。一个人维护的时候机器能少则少但角色要分开。源站、边缘节点、控制端如果挤在同一台机器上一旦缓存占满磁盘或控制端异常你的业务也会跟着受影响。3.2 搭建主流程控制端、节点、源站、域名四步走99CDN 企业版这类方案的通用流程大致可以归纳为四步初始化控制端。控制端负责管理节点、域名、证书和缓存规则。添加边缘节点。节点会从控制端拉取域名和缓存配置。添加源站。源站地址决定了节点回源时去哪个服务器拿数据。创建加速域名。配置回源 Host、缓存规则和证书然后把 DNS 解析指向边缘节点。不同版本的界面和字段会有差异但底层的网络逻辑是一样的。你要做的事情不是记住每个按钮而是理解每一步在整个流量链路里的位置。控制端是大脑节点是触手源站是内容库域名是用户入口。四者接起来流量才走得通。3.3 最小可运行配置示例如果你第一次搭建议先绑定一个带版本号的静态资源路径来验证比如https://cdn.example.com/static/test.txt。对应的配置可以参照这个表配置项示例值说明加速域名cdn.example.com用户实际访问的域名源站地址origin.example.com边缘节点回源时请求的服务器回源 Hostorigin.example.com源站用来识别虚拟主机的字段缓存规则/static/*缓存 7 天静态资源路径缓存规则/api/*不缓存动态接口路径HTTPS 证书cdn.example.com证书边缘节点直接终止 TLS配置完先不要急着切换全站 DNS。用本地 hosts 文件把cdn.example.com指向边缘节点 IP访问测试文件确认响应正常再考虑让线上用户接入。很多人自建 CDN 失败不是配置不对而是步子迈太大一把梭全量切换出了问题连回退方案都没有。3.4 第一刀切多小先让一个路径跑起来我比较推荐的方案是把某个目录先切成 CDN 流量。比如先只加速/static/路径剩下的动态请求依然直接访问源站。跑一两天观察缓存命中率、源站负载和访问日志稳定后再把图片目录、下载目录加进来。这样即使出问题影响面也可控。自建 CDN 是一套系统但它首先要能作为一个“局部中间层”工作而不是一开始就试图接管所有东西。4. 自建 CDN 的测试不能只看“首页能打开”4.1 功能连通性测试确认请求真的经过了 CDN搭建完成后的第一个测试不是打开浏览器看页面而是确认流量链路是否按要求工作。一个很简单的办法是用 curl 看响应头curl -I https://cdn.example.com/static/test.txt观察响应头里是否有 CDN 节点相关的标记比如X-Cache、Via、Age或者边缘节点特有的 Server 信息。如果响应头里看不到任何中间层痕迹就要查 DNS 是否真的解析到了边缘节点或者本地是否有缓存。另一个判断方法是去源站日志里看请求来源。如果边缘节点正常工作源站日志里应该只能看到边缘节点 IP 的回源请求而不是大量直接来自用户 IP 的请求。4.2 缓存生效测试命中与回源要分开看缓存是否生效可以用两次请求来验证。第一次访问静态文件记录响应头里的X-Cache: MISS或Age: 0第二次访问看是否变成X-Cache: HIT并且源站日志里没有新增请求。如果产品没有暴露缓存状态可以通过源站访问日志数量来判断同一个文件访问两次源站日志里只有一条记录说明第二次被缓存拦截了。这里可以把自动化测试加进来。不要每次都手动 curl写一个简单脚本循环请求某个静态文件检查响应头里的缓存状态超过 N 次非 HIT 就告警。对一个人来说自动化测试不是“要不要做”的问题而是“如何用最简单脚本替自己盯着线上”的问题。一个十几行的 shell 或 Python 脚本就能把重复检查自动化掉。4.3 多地区和弱网测试CDN 的价值要在不同网络下体现如果你的业务用户分布在不同城市测试就不能只在本地局域网做。可以找在线拨测工具或者在不同云厂商的区域各开一台低配机器用 curl 请求同一个资源比较 DNS 解析结果和响应时间。理想状态下华东用户解析到华东节点华南用户解析到华南节点响应时间应该比直连源站更短。弱网测试同样重要。用网络工具模拟丢包、延迟、带宽限制看用户在弱网环境下能否拿到内容、是否会等待过久、是否有超时重试。自建 CDN 很多时候不是“快不快”的问题而是“在弱网下稳不稳定”的问题。如果源站带宽本身很小而你又没有限制回源并发用户请求一多边缘节点会不断回源排队最终表现为页面加载慢、图片反复加载失败。4.4 异常状态和源站保护测试测试不能只测“正常情况”。你需要主动制造一些异常场景比如把源站服务停掉看边缘节点是否返回 502错误信息是不是友好把证书撤掉看 HTTPS 访问是否失败查看 4xx、5xx 状态码分布确认问题出在边缘节点还是源站。更关键的是源站保护测试。如果你已经配置了防火墙只允许边缘节点回源 IP 访问源站端口就可以验证一下直接用 curl 访问源站地址应该失败通过 CDN 访问同一个资源应该正常。这一条非常重要因为很多自建 CDN 翻车不是节点出了问题而是源站 IP 暴露后被人绕过 CDN 直打源站整个服务直接不可用。注意源站保护不是可选项。只要做了自建 CDN就必须确保除了边缘节点之外其他来源不能直接访问源站。否则你在缓存上做的所有努力都会被一次绕过打得稀碎。4.5 五维测试评估表把测试经验沉淀成一张表方便以后每次调整配置后复查检查维度通过标准未通过时先排查什么功能连通curl 能看到 CDN 特征头DNS 解析、DNS 缓存、边缘节点状态缓存命中二次访问命中源站无新请求缓存规则、文件 URL 是否变化、刷新任务区域分发不同地区解析到对应节点节点配置、DNS 解析策略、节点健康状态异常降级源站挂掉后错误提示明确回源超时、健康检查、502 日志源站保护直连源站失败CDN 访问正常防火墙规则、安全组、回源 IP 白名单这五维测试不是只做一次。每次调整节点、缓存规则或证书之后至少要跑一遍前三维确认没有把线上链路改坏。测试应该是持续行为而不是交付前的仪式。5. 一个人长期维护真正的成本在“看不见的地方”5.1 证书过期和缓存不刷新是最常见的两个事故自建 CDN 上线之后第一个容易踩的坑是证书过期。商业 CDN 的服务商会在后台自动续期你感知不到自建方案里证书续期变成了你自己的责任。如果控制端支持自动签发证书务必把自动续期开启并且定期做一次续期演练不能等到证书过期的邮件出现才处理。第二个坑是缓存不刷新。你更新了源站上的文件但用户拿到的还是边缘节点上的旧版本。解决办法有两个方向一是资源文件名带版本号或 hash每次更新换一个新 URL二是使用 CDN 的刷新功能主动清除指定路径的缓存。路径带版本号比刷新更可靠因为刷新一旦失败或者漏刷了一个 CDN 节点用户还是会看到旧内容。5.2 日志、监控、告警缺一不可一个人维护一套 CDN最大的问题不是你处理不了故障而是你不知道已经发生了故障。访问日志、回源日志、节点磁盘占用量、带宽曲线、5xx 错误率这些指标至少要有一个能看到的地方。不用做得特别复杂一套能够记录日志、定时统计、异常告警的轻量方案就够。告警规则要克制。不要每个异常都发告警否则一天收到几百条你很快就不看了。我一般只保留四类告警节点不可达、5xx 比例超过阈值、磁盘使用率超过 80%、证书剩余有效期低于 15 天。这四类告警基本覆盖了自建 CDN 最致命的问题又不会让人产生“狼来了”的疲劳。5.3 容量和磁盘缓存是拿磁盘换速度边缘节点的缓存会持续占用磁盘。如果缓存目录没有清理策略时间长了磁盘会满进而影响节点进程甚至导致整个服务器卡死。在实际使用中要关注缓存淘汰策略、缓存目录上限、磁盘增长趋势。你可以设置一个阈值比如磁盘使用率达到 80% 时告警达到 90% 时手动或自动清理缓存。如果节点需要缓存大量视频或镜像文件磁盘规划就更加重要。缓存命中再高文件还是要落到磁盘上。对一个人来说与其无限扩大缓存目录不如从源站层做好文件体积优化、从业务层做好 URL 版本管理减少无效缓存。5.4 源站安全被绕过是自建 CDN 最大的坑自建 CDN 之后你的源站 IP 就成了最需要保护的信息。一个直接请求源站的用户可以绕过缓存、绕过安全策略、拿到源站最新内容甚至拖着源站发起高并发请求。防护思路至少要有两层网络层限制在防火墙或安全组里只允许边缘节点的回源 IP 访问源站端口。应用层校验在回源路径上增加自定义 Header 或鉴权信息边缘节点回源时带上源站校验通过才返回内容。第二层看起来更安全但也更复杂。如果团队只有一个人建议先做第一层把 80/443 端口对外访问限制到边缘节点 IP。等整个链路稳定了再评估是否需要做回源鉴权。安全测试也不是可选项。上线前至少要模拟一次“绕过 CDN 访问源站”的验证确认直连源站请求会被拒绝。6. 什么时候该收手自建 CDN 的适用边界6.1 比较适合自建的三种场景自建 CDN 并不是一个“绝对行”或“绝对不行”的命题它有自己的适用边界。从我这次尝试的经验看比较适合的场景有三种内部系统或工具站用户量不大但对数据链路、日志留存有要求。静态资源为主的内容站图片、文档、CSS、JS 占大头缓存命中率天然高。特定用户群或区域集中的业务节点不需要铺全国一个边缘节点就能覆盖主要用户。在这些场景里自建 CDN 的成本可控收益明确出现问题也容易排查。6.2 不建议自建的场景反过来下面这些场景我建议你再想想业务流量高峰不可控可能突然出现几倍甚至几十倍增长。用户分布在全国甚至全球需要密集节点和智能调度。对外提供可用性承诺要求 99.9% 以上 SLA。团队只有一个人且没有时间看监控、处理告警。需要复杂的视频直播、动态加速、全球范围实时调度等能力。这些需求不是“加油就能解决”的。商业 CDN 那么多年的节点积累、调度算法和边缘网络并不是一个一个人维护几个节点就能替代的。6.3 务实的混合方案自建节点 商业 CDN 兜底对一人团队来说更务实的路径其实是混合架构平时流量走自建节点你自己掌握缓存策略和日志一旦遇到异常流量、节点故障或需要重大版本发布通过 DNS 快速切回商业 CDN。这个方案听起来不如“全自建”纯粹但它给了你一个很关键的兜底能力。前提是你必须把 DNS 切换文档写好。写清楚加速域名、源站地址、DNS 服务商、切换步骤和回退条件。不要等到故障发生的那一刻再去翻控制台手忙脚乱。技术选型的核心不是证明自己什么都能做而是让系统在你自己能承受的维护边界里稳定运行。回到开头的问题自建 CDN 可行吗我的答案已经很具体了可行但它的可行建立在“用成熟方案构建可控链路”这个前提上而不是从零自研一套 CDN。以 99CDN 企业版这类方案为起点先跑通最小闭环再做五维测试再把证书、刷新、日志、监控、源站保护这些“看不见的运维”补上最后给自己留一条切回商业 CDN 的退路。一个人不是不能做网络服务关键是要选择一个让你把精力放在业务上、而不是整天救火的维护边界。如果哪天自建带来的维护量已经超过它解决的问题就果断切回去。技术选型没有唯一解只有最适合你当前状态的答案。