边缘计算与CDN的融合，本质上是在全球分布式节点上同时解决内容分发和计算问题。当你需要为全球用户提供低延迟的动态API、图像处理或个性化页面时，单纯依赖源站或传统CDN缓存都不够。本文基于Cloudflare的公开文档，从缓存、无服务器计算和DDoS防护三个维度，给出可操作的架构设计步骤。
场景一：动态内容响应慢，缓存命中率低
假设你的应用有大量动态API请求，但部分响应其实可以缓存几秒钟。直接让所有请求回源会拖垮源站，而过度缓存又会返回陈旧数据。此时需要设计分层缓存策略。
步骤1：配置Cache Rules精细控制缓存
Cloudflare的Cache Rules允许你指定哪些资源应被缓存以及缓存时长。你可以根据URL路径、文件扩展名、请求头等条件设置规则。例如，对 /api/status 这类变化不频繁的接口，设置缓存60秒；对用户个人信息则跳过缓存。判断依据是数据更新频率和业务容忍度。
步骤2：启用Tiered Cache降低回源压力
Tiered Cache将频繁访问的内容缓存在多个层级位置，减少直接回源次数。对于静态资源（图片、CSS、JS），这能显著提升命中率。但注意，如果你的源站需要实时日志，可能需要权衡缓存带来的延迟。
步骤3：利用持久化存储延长缓存时间
Cloudflare的持久化存储（如KV）可以增加缓存时长，尤其适合不常变化的元数据。将热点数据写入边缘KV，可减少对源站的依赖。但要注意一致性：KV是最终一致的，不适合强一致场景。
场景二：需要全球部署无服务器函数，但不想管理基础设施
当你的业务逻辑需要靠近用户执行，比如A/B测试、请求改写、地理位置定制响应，传统CDN无法满足。Cloudflare Workers提供了在边缘运行JavaScript的serverless平台。
步骤1：用Wrangler CLI初始化项目
安装Wrangler后，运行 wrangler init 创建项目。Worker的代码会在每个边缘节点执行，无需配置服务器。你可以通过Bindings连接外部服务，比如KV存储、D1数据库或外部API。
步骤2：处理请求并返回定制响应
在 fetch 事件中编写逻辑，例如根据用户所在国家返回不同版本页面。由于代码在全球节点运行，延迟极低。注意Worker的资源限制（CPU时间、内存），超时会导致错误。
步骤3：结合缓存与Worker
Worker可以调用Cache API将响应缓存到边缘，但需要手动管理缓存键和失效。常见误区是忘记设置 Cache-Control 响应头，导致缓存不生效。
场景三：源站遭受DDoS攻击，服务不可用
当攻击流量涌入时，CDN的防护能力至关重要。Cloudflare提供自动化的DDoS防护，覆盖L3/4和L7层。
步骤1：了解默认防护机制
Cloudflare会自动检测并缓解DDoS攻击，无需手动干预。系统包含动态缓解规则，可识别SYN flood、ACK flood、DNS随机前缀攻击等。对于常见攻击，默认配置足够。
步骤2：定制防护规则
如果默认规则误伤正常流量，你可以自定义Managed Ruleset。例如，调整阈值、添加IP访问规则。但过度定制可能降低防护效果，建议从宽松开始逐步收紧。
步骤3：结合边缘计算增强防护
使用Workers编写自定义防护逻辑，例如基于请求频率限制或挑战页面。但注意，Worker本身也会消耗资源，需要合理设计。
架构设计中的常见误区
- 忽略缓存一致性：缓存时间设置过长导致数据陈旧，尤其在动态API场景。应使用Cache Rules精确控制，并利用Purge API及时清理。
- 混淆边缘计算与源站计算：并非所有逻辑都适合移到边缘，涉及大量数据计算或强一致性的操作应留在源站。
- 忽视DDoS防护的配置：依赖默认设置而不测试，可能在高攻击流量下出现误杀或漏防。建议进行压测。
架构设计决策表
需求方案取舍
静态资源加速CDN缓存 + Tiered Cache命中率高，但更新需Purge
动态API加速Cache Rules + Workers灵活，但需管理缓存键
安全防护DDoS防护 + 自定义规则默认省心，定制需谨慎
参考资料
延伸阅读