把站点挂到边缘:一次 CDN 接入的完整记录

主站的源站在海外,大陆用户直连的延迟一度是访问体验的最大短板。接入大陆边缘 CDN 之后,边缘命中的页面总耗时从约一秒降到零点一二秒,差了八倍。这篇把整个接入过程沉淀下来——不只是“怎么接”,更是“接完之后你怎么知道它是对的”。

接入前的三个决策

第一个决策是缓存粒度。内容站的需求天生分裂:词条页面希望边缘缓存得越久越好,登录态页面和搜索结果一刻都不能缓存,静态数据文件希望缓存但更新要及时。我们的规则引擎最终收敛成四条:主域名的缓存行为遵循源站响应头;动态程序后缀一律不缓存;图片类后缀遵循源站;JSON 数据文件强制边缘缓存三十天。

第二条规则配套一条纪律:凡是入边缘缓存的静态数据文件,引用时必须带版本参数。文件更新了、边缘三十天内还给旧版,这种事故发生一次就够记一辈子——版本参数让“更新”变成“新 URL”,天然绕开缓存。

第三个决策是调试能力的预留。选型时确认了一个关键细节:每个响应都会带一个缓存状态头,标明这次响应是边缘命中还是回源。这个头后来成了我们排障的第一入口——所有“我改了你怎么看不到”的争论,一个 curl 就能终结。

割接与验收

割接本身只是改解析。真正的功夫在验收:割接完成后,按真实解析路径逐类资源实测。HTML 要验证两个方向——公共页面应该从未命中变成命中;而登录态页面、离线更新脚本的“禁止缓存”响应头必须被边缘尊重,否则登录用户会互相看到对方的页面。带版本参数的静态资产要验证命中且不可变标记透传。裸域到 www 的跳转要在边缘完成而不是回源。

全部实测通过,才算割接完成。这个清单后来成了模板,第二个站接入时照单走了一遍,半小时完事。

规则表告诉不了你的事

接入后的日子里,我们被教育了三次“规则表之外还有行为”。

第一次:按规则表,动态程序后缀不缓存,我们默认 HTML 全部回源。后来用缓存状态头一查,匿名访问的 HTML 其实存在数百秒的边缘缓存。这是平台对无缓存头响应的默认策略。它对性能是好事,对“改完立刻生效”是坏事——于是清缓存的手段从一层变成两层:源站程序缓存之外,还有边缘的自动过期,急刷必须走控制台的刷新接口。

第二次:一次全站体检里,检测工具复扫的数字纹丝不动,报的还是修复前的旧颜色。源站实测明明是新的。最后发现是海外出口的边缘节点长时间持有旧 HTML 和旧样式表——同一时刻,不同地区的用户看到的可能是不同版本的站点。结论沉淀成验收铁律:验证修复要绕开边缘直连源站,或者给地址加随机参数强制穿透;全量收敛要么靠控制台刷新,要么等自然过期。

第三次:评估“把源站从海外挪走能带来多少收益”时,实测了三条路径的冷抓延迟——边缘命中十四毫秒、边缘未命中回源海外八百多毫秒、直连新源站四百毫秒。结论反直觉:挪源站只能砍掉回源那段的耗时,边缘命中的大头用户无感;真正该优化的是回源命中率。没有这组数字,决策就是拍脑袋。

缓存键与刷新的层级清单

规则引擎里最容易被低估的配置是缓存键。同一个地址带不带查询参数、参数大小写是否敏感,决定了它是同一份缓存还是两份。我们把它定为“查询串全保留且区分大小写”——宁可缓存份额碎一点,也不冒“不同内容共享一个键”的险。配套纪律:凡入缓存的静态数据文件,更新靠新版本参数,不靠刷缓存。

刷新手段最终梳理成四层,按生效速度排序:开发期改样式靠版本参数秒级生效;程序层缓存手工清;边缘有数百秒的自动过期兜底;急上线走控制台的刷新接口。每一层都要写进发布清单——发布事故的八成,是只清了一层缓存。最典型的一次:页面 HTML 是新的,样式表链接没带新版本参数,用户浏览器持有旧样式,渲染出一版“新结构旧皮肤”的页面,排查了半天才定位到样式那层。

什么情况下不该急着上 CDN

用一组实测数据泼一盆冷水。评估“源站挪近能提升多少”时,三条路径的冷抓延迟:边缘命中十四毫秒;边缘未命中、回源海外八百多毫秒;直连新源站四百毫秒。乍看搬源站能把最差情况砍半,细算才发现关键变量是命中率:边缘命中的用户已经很快,搬源站对他们无感;只有未命中的那部分用户受益,而收益还要乘上未命中率。如果内容更新频繁、命中率低,搬源站的收益远小于直觉;如果内容稳定命中率高,收益同样趋近于零。CDN 的收益模型是加权平均,不是最差情况的改善。

所以上 CDN 之前先回答两个问题:你的内容更新频率决定边缘缓存能存多久;你的访问分布决定命中率。两个问题都有数了,收益模型才算成立。

沉淀

回头看,CDN 接入的技术动作只占两成,剩下八成是三类事:缓存语义在每个资源类型上的明确化、每个行为假设的实测验证、以及一层层的缓存刷新手段的梳理——改代码要清程序缓存,改样式要防浏览器旧缓存,急上线要打控制台刷新。缓存这个东西,接的时候有多省心,排查的时候就有多少层。把它当分层系统来管理,而不是当一次性配置,是这次接入最大的收获。