引言：全球化业务的底层逻辑变了
当用户分布在全球 200 多个国家，网站的加载速度不再是“加分项”，而是“入场券”。传统的单点部署或少量 CDN 节点早已无法满足低延迟、高可用和安全合规的复合需求。以 AWS CloudFront 和 Cloudflare 为代表的云厂商，在过去十年里持续迭代其全球网络，从纯静态缓存加速器进化为集边缘计算、DDoS 防护、动态路由于一体的 Web 应用平台。这篇文章不代表任何厂商立场，只探讨架构在实际演变中的关键节点与取舍。
第一阶段：静态内容加速的“军备竞赛”
CloudFront 的起源：与 S3 深度绑定的缓存层
CloudFront 最早是为解决 S3 存储桶的全球访问延迟而设计。它的逻辑很简单：在全球建立边缘站点，缓存静态文件（图片、CSS、JS），并通过 AWS 内部网络回源。这一阶段的架构特点是“中心化回源 + 边缘缓存”，缓存命中率直接决定了加速效果。运维人员需要手动配置 TTL、刷新规则和源站分组，对缓存策略的依赖极高。
Cloudflare 的差异化：Anycast 与反向代理
Cloudflare 从一开始就采用 Anycast 路由技术。所有边缘节点共享同一组 IP，用户请求自动路由到最近的节点。这比 CloudFront 的 DNS 逐级解析更快，且天然具备抗 DDoS 能力（流量被分散到全节点）。但早期 Cloudflare 仅提供 7 层反向代理，不支持自定义源站协议。它更像一个“网关”，而 CloudFront 更接近“缓存层”。
这一阶段的演进本质：从“内容加速”走向“连接加速”。架构师开始关注 DNS 解析时间、TCP 握手优化、TLS 会话复用等传输层面的改进。CloudFront 推出了区域性边缘缓存，Cloudflare 引入了 Argo Smart Routing，动态路由优化正式登上舞台。
第二阶段：动态内容与安全能力的融合
边缘计算打破缓存限制
静态缓存对 API 接口、个性化页面天然无力。2017-2019 年，CloudFront 推出 Lambda@Edge，Cloudflare 推出 Cloudflare Workers。两者允许在边缘节点执行自定义 JavaScript/Python 代码，直接改写请求、响应，甚至实现 A/B 测试、URL 重写、身份校验等业务逻辑。此时，全球 Web 架构从“CDN + 源站”演变成“边缘函数 + 智能路由 + 源站”。
安全不再是附加品
CloudFront 依托 AWS WAF 和 Shield 提供 Web 应用防火墙和 DDoS 防护；Cloudflare 则直接将其 Web 应用防火墙、Bot 管理、SSL 证书集成到套餐中。值得注意的是，Cloudflare 的安全能力默认开启，而 CloudFront 需要额外付费配置。这一差异影响了很多初创公司的选型：如果团队安全人手不足，Cloudflare 的“开箱即防”更具吸引力；如果已有 AWS 生态，CloudFront 的深度集成更利于统一运维。
真实场景中，动态加速与安全策略的耦合带来新问题：WAF 规则可能误伤正常流量，边缘 Workers 中的 bug 会影响所有区域。架构演进中，灰度发布和链路追踪（如 CloudFront 实时日志、Cloudflare 的 Workers Logpush）成为必备基础设施。
第三阶段：全球负载均衡与多活架构
CloudFront 的起源优先与加权路由
对于多区域部署的应用，CloudFront 通过 Lambda@Edge 结合 Route 53 实现基于延迟或地理位置的回源选择。但这需要额外开发。2020 年后，CloudFront 推出了起源组（Origin Group）和故障转移能力，用户可以配置主备源站，当主源不可用时自动切换。这算是原生多活的第一步，但仍缺乏跨区域的会话保持。
Cloudflare 的智能路由与 Load Balancing
Cloudflare 提供了独立的负载均衡产品，支持健康检查、地理路由、加权比例分配，并且与 Workers 深度结合。你可以编写一个 Worker 根据请求头动态选择回源 IP，甚至实现金丝雀发布。更关键的是，Cloudflare 的 Argo 隧道允许内网源站不暴露公网 IP，通过反向连接将流量引入私有网络，这对混合云架构非常友好。
这一阶段的核心矛盾：当业务需要“主动回源”而非“被动缓存”时，CDN 的角色从加速器变成了“全球流量调度器”。架构师需要思考：session 是否要全局同步？数据写操作是否要限定主区域？边缘计算能否承担轻量状态存储？CloudFront 和 Cloudflare 都推出了边缘 KV 存储（CloudFront 依靠 DynamoDB Global Tables 间接实现，Cloudflare 有 Workers KV），但写入一致性和延迟依然不如中心化数据库。
第四阶段：边缘计算成为一等公民
Cloudflare Workers 的崛起与生态
Cloudflare 直接将 Workers 定位为“无服务器计算平台”，不只用于 CDN 场景。它支持 WebAssembly、Durable Objects（有状态对象）、Queue（消息队列），正试图构建一个完整的边缘应用运行时。典型的例子是：将认证 JWT 验证、API 网关速率限制、SSR 渲染等从服务器迁移到边缘节点，用户请求平均延迟降低 50-80ms。Cloudflare 还推出了 Pages，将静态网站部署与边缘函数绑定，形成“边缘即 PaaS”的体验。
CloudFront 的 Lambda@Edge 与 CloudFront Functions
AWS 的做法更克制：Lambda@Edge 只能在 CloudFront 的四个事件钩子（Viewer Request/Response, Origin Request/Response）中运行，且超时时间限制严格（5秒/30秒）。2021 年推出的 CloudFront Functions 进一步简化轻量级处理（如 URL 重写、Header 修改），但功能有限。这反映了 AWS 的策略：边缘计算应做简单的事情，复杂计算留在区域中。CloudFront 的演进方向是“与 AWS 全栈能力无缝连接”，而非取代区域计算。
这两种哲学导致架构选择的分化：如果你的业务逻辑靠近用户端就能解决，Workers 更灵活；如果你的业务需要操作 RDS、SQS、DynamoDB 等重型服务，保留 CloudFront + 区域 Lambda 的组合更可靠。
现状与选型指南：没有银弹
延迟优先场景：Cloudflare 胜出
Cloudflare 节点数量超过 320 个，Anycast 网络使得首次连接延迟低至 10ms 以下。对于全球游戏服务器、实时协作工具、轻量 API 网关，Cloudflare 的 Workers 和 Durable Objects 能提供亚秒级响应。
复杂企业架构：CloudFront 更适合
如果公司已经在使用 AWS 的 ECS、RDS、ElastiCache、SQS 等服务，CloudFront 的深度集成可以降低运维复杂度。特别是需要将 CDN 日志导入 Athena 分析、使用 CloudFormation 自动化部署、结合 IAM 精细权限控制的企业，CloudFront 的开放性更佳。
安全合规考量
Cloudflare 的全球网络默认加密，但数据包经过其边缘节点时，对于某些受监管行业（如金融、医疗）可能引起合规质疑。AWS CloudFront 允许用户选择边缘节点位置、关闭某些区域（如中国节点），并提供 SOC、PCI DSS 认证报告。架构师需要根据数据主权法规调整部署策略。
未来：边缘与终端的模糊边界
CloudFront 和 Cloudflare 都在探索 WebAssembly、流式传输、HTTP/3 等新协议。更重要的是，它们正与 5G 边缘计算平台（如 AWS Wavelength、Cloudflare Network Interconnect）结合，将计算推至运营商基站。这意味着未来的全球 Web 架构不再区分“客户端”和“服务器”，而是由多个边缘层（设备端、运营商边缘、云厂商边缘、区域节点）共同协作完成一个请求。
对于架构师来说，理解这一演进的关键不是记住每个产品的特性，而是掌握“延迟/一致性/成本”三者的权衡。无论你选 CloudFront 还是 Cloudflare，其底层逻辑都是：将计算和数据尽可能地推向用户，同时保持编程模型足够简单。
延伸阅读