干了这么多年CDN，我一直觉得它像个快递柜——东西放进去，用户就近取，快得很，但快递柜只会存和取，你要它在取件时顺便帮你验个货、改个包装、或者算个运费？对不起，它做不到，而Serverless就像个随叫随到的临时工，你给它一段代码，它帮你跑出个结果，但你得从总仓（源站）把它叫过来，一来一回，路上就慢了，把这两样东西塞进同一个边缘节点,有意思的事就来了。
技术概念拆解：别被缩写唬住
CDN的本质是“缓存+路由”，它把静态资源复制到离用户最近的边缘节点，然后通过智能DNS或HTTPDNS，让用户请求落到那个节点上，这里的“节点”以前只干一件事：命中了就返回，没命中就回源拉取，它没有计算能力,只有存储和转发。
Serverless的本质是“事件驱动的函数计算”，你写一个函数，上传到平台，平台在你需要时分配资源执行，按调用次数和耗时计费，你不用关心服务器，但代码跑在哪儿？通常跑在云厂商的地理区域中心的某个容器里，冷启动、网络跳数,都是延迟的来源。
边缘的逆袭，当CDN遇上Serverless
把二者结合，就是把函数运行环境塞进CDN的边缘节点，请求来了，先在CDN上查缓存——命中，直接返回；不命中，如果这个路由绑定了函数，那就地执行函数生成响应，再返回给用户，整个过程没有回源,没有跨地域的漫长往返。
方案对比：三种常见姿势
第一种，CDN边缘函数，你在CDN的缓存规则里挂一段JavaScript或WebAssembly，在请求到达时做修改、重写、鉴权，适合轻量逻辑，比如给响应头加个时间戳，或者根据User-Agent返回不同尺寸的图片，优点是延迟极低，缺点是不能跑重量级任务,超时限制通常在几十到几百毫秒。
第二种，CDN触发Serverless回源，当CDN缓存未命中时，请求回源到一个云函数，函数动态生成内容并返回，同时CDN把结果缓存下来，这种适合动态但可缓存的页面，比如个性化推荐结果（对同一用户有效），优点是函数本身不受边缘资源限制，使用成熟云厂商的Serverless，爽；缺点是首次请求仍有回源延迟，没完全消除“冷”的问题。
第三种，边缘Serverless平台（比如Cloudflare Workers、阿里云边缘函数计算），这是真正的融合：函数直接部署在边缘节点上，CDN和计算在一个进程内，请求直接进入函数，函数可以调用缓存API、存储API，或发起子请求，它既能做CDN的事，也能做Serverless的事，优点是灵活、低延迟、支持较大型应用；缺点是你得接受平台锁,调试和观察性也往往不如中心化环境。
三种方案不是替代关系,而是针对不同问题域。
适用场景分析：你能用它干什么
最典型的是动态API加速，假设你是订票系统，用户查询余票，请求要打到几公里外的数据库，用边缘函数，你可以在CDN节点上做一层本地缓存，键是“航班号+日期”，过期时间设30秒，同一时刻几千人刷同一个航班，只有第一个请求回源，其余全部在边缘命中——服务器压力直降99%,用户看票价的时间快了半个身位。
另一个是响应变换，你的源站返回JSON，但不同客户端要不同字段，以前得做多个接口，或者客户端自己处理，现在你可以在边缘函数里解析JSON，按User-Agent裁剪成移动端精简版或桌面完整版，再配合CDN的Vary,缓存还能按设备类型区分。
还有边缘A/B测试，你不想让用户感知到跳转，但又要让一部分人看到新页面，在边缘函数里读Cookie，按比例分配实验组，直接重写HTML里的脚本标签，这比用前端SDK更隐蔽,也不影响性能。
选型建议：别为时髦买单
我的建议很直白：先问自己，你的计算到底有多“重”。
如果只是改头换面、剪剪裁裁、查查缓存，选CDN边缘函数，别折腾Serverless，因为边缘函数的资源配额小，但胜在够快，而且通常免费额度内，如果你需要连接数据库、调用第三方API、做复杂的鉴权签名，而这些结果又可以缓存一段时间，那就选“CDN触发Serverless回源”，好处是回源逻辑可以复用你现有的云函数，成本低,改起来快。
如果你要做的是真正动态的、个性化的、无法缓存的业务（比如实时协同编辑的会话鉴权、按地理位置生成定制响应），并且你的用户分布在全球——那才值得上边缘Serverless平台，别小看平台锁，但换来的是每个用户都从最近的节点获取计算能力,这种体验是中心化服务器给不了的。
最后一句实话：CDN与Serverless的结合，不是把两个热点词汇焊在一起，而是让“靠近用户”从数据层面延伸到了计算层面，你不需要懂那么多术语，只需要记住——距离产生延迟，延迟产生流失，用边缘的脑子，替源站减负，替用户省时间,这才是硬道理。
发表评论