Cloudflare Worker路由：一个域名部署两个项目的完整方案

前后端分离架构下的域名难题

现代前端开发中，前后端分离已成为主流架构。前后端分离架构是指将用户界面（前端）与数据处理逻辑（后端）拆分为独立部署、独立开发的两个系统。前端通常编译为纯静态文件（HTML、CSS、JavaScript），托管在 CDN 或静态站点服务上；后端则以 API 形式提供数据。这种架构的优势在于前后端团队可以并行开发，部署互不影响，且静态资源可以充分利用 CDN 的全球缓存能力。但它也引入了跨域请求（CORS）、域名管理、服务编排等额外复杂度，尤其当一个逻辑上的「网站」实际由多个独立服务组成时，如何对外呈现统一的入口就成了必须解决的问题。

前后端分离架构的兴起与前端框架的成熟密切相关。2010 年之前，Web 开发主流模式是服务端渲染（如 PHP 的模板引擎、Java 的 JSP、Ruby on Rails 的 ERB），前后端代码耦合在同一个项目中。2010 年后，随着 AngularJS、React（2013 年）、Vue.js（2014 年）等 SPA 框架的出现，前端具备了独立构建复杂应用的能力，前后端分离逐渐成为行业共识。RESTful API 设计风格（由 Roy Fielding 在 2000 年的博士论文中提出）为前后端之间的数据通信提供了统一的接口规范，使得这种分离在实践中成为可能。

所谓跨域请求（CORS，Cross-Origin Resource Sharing），是浏览器出于安全考虑实施的同源策略限制——当前端页面的域名与它请求的 API 域名不一致时，浏览器会先发送一个预检请求（OPTIONS 请求）来确认服务端是否允许跨域访问。这意味着在前后端分离架构中，如果前端和后端使用不同域名，就必须在后端正确配置 CORS 响应头（如 Access-Control-Allow-Origin），否则请求会被浏览器直接拦截。这不仅增加了开发配置的复杂度，还会因为额外的预检请求带来轻微的性能损耗。如果能让前端和 API 处于同一域名下，CORS 问题就自然消失了——这也是本文方案的附带收益之一。

当一个博客系统被重构为分离形式后，往往会衍生出域名管理和用户体验上的问题。本文以一个实际的博客重构案例出发，介绍如何借助 Cloudflare Worker 路由，实现一个域名同时服务两个独立项目的方案。

重构后的博客采用了纯静态前端加数据接口的分离模式。通过浏览器开发者工具（F12）观察网络请求可以发现，博客本体的加载依赖特定域名下的接口。一旦该请求域名被阻止，页面将无法正常渲染，因为前端需要请求 post.json 这样的数据文件——它包含了所有文章列表，再根据文章的 slug 去拼接获取具体内容的详情。这种模式在技术上被称为「客户端渲染」（Client-Side Rendering, CSR），与之对应的还有服务端渲染（SSR）和静态站点生成（SSG）。CSR 的特点是首屏需要等待 JavaScript 执行和数据请求完成后才能展示内容，对 SEO 不太友好，但部署极为简单——只需要一个能托管静态文件的服务即可。

值得一提的是，CSR 之外的渲染策略各有适用场景。SSR 在每次请求时由服务器动态生成 HTML，首屏速度快且 SEO 友好，但需要服务器运行时（如 Next.js 的 Node.js 服务器）。SSG 则在构建时预生成所有页面的 HTML，兼具 SSR 的 SEO 优势和 CSR 的部署简便性，适合内容变化不频繁的场景（如博客、文档站）。近年来还出现了 ISR（Incremental Static Regeneration，增量静态再生）模式，结合了 SSG 和 SSR 的优点——静态页面在后台按需重新生成，用户始终访问缓存的静态页面。选择哪种渲染策略，本质上是在首屏性能、SEO 友好度、部署复杂度和内容实时性之间做权衡。

这种架构本身设计清晰、职责分明，但在实际运营中却暴露出一个容易被忽视的问题：RSS 订阅的地址管理变得混乱。

RSS 订阅遇到的实际困境

很多读者并不会直接打开博客域名去浏览文章，而是通过 RSS 阅读器（如 Follow）来订阅内容。这里需要先理解 RSS 的本质。

什么是 RSS

RSS（Really Simple Syndication）本质上是一个 feed，它包含了文章的所有原数据（metadata），但不携带任何前端渲染逻辑。可以把 RSS 理解为「文章的本体」——纯粹的内容数据流。像 Follow 这样的聚合工具，正是把众多 RSS 源汇聚在一起，让用户在一个界面里统一阅读多个博客的更新。

从技术层面看，RSS 最早由 Netscape 在 1999 年推出，经历了 0.9、1.0、2.0 等多个版本演进。它本质上是一份符合特定 XML Schema 的文档，包含 channel（频道信息）和多个 item（条目），每个 item 通常包含 title、link、description、pubDate 等字段。与之类似的还有 Atom 协议（RFC 4287），两者功能相近但格式略有不同。RSS 2.0 由 Dave Winer 在 2002 年定稿，至今仍是最广泛使用的版本，其规范相对宽松，允许通过命名空间扩展自定义字段（如 content:encoded 用于携带文章全文 HTML）。Atom 则是 IETF 标准化的产物，语法更严格、语义更明确，例如它区分了 summary 和 content，并且强制要求每个条目有唯一的 id。在实际应用中，大多数 RSS 阅读器同时兼容这两种格式。

RSS 阅读器通过定期轮询（polling）RSS 地址来检测是否有新内容发布，轮询频率通常在 15 分钟到数小时之间。现代阅读器还会利用 HTTP 的条件请求机制（If-Modified-Since 和 ETag 头）来避免重复下载未变更的内容，从而减少带宽消耗。一些高级的订阅服务（如 Feedly 的后端爬虫）还会根据源的更新频率动态调整轮询间隔。如果 RSS 地址不稳定或响应异常，阅读器可能会降低轮询频率甚至标记为失效源，直接影响读者的订阅体验。值得一提的是，RSS 在 2013 年 Google Reader 关闭后曾一度被认为「已死」，但近年来随着信息茧房问题的加剧和去中心化阅读需求的回归，RSS 正在经历复兴——Follow、Miniflux、Inoreader 等新一代阅读器的出现就是最好的证明。

除了文中提到的轮询机制外，WebSub（原 PubSubHubbub）协议提供了一种推送替代方案——当内容更新时，发布者主动通知订阅者的 Hub，Hub 再实时推送给所有订阅者，大幅降低更新延迟。此外，RSS 生态还包括自建服务（如 FreshRSS、Tiny Tiny RSS）、商业服务（如 Feedly、NewsBlur、The Old Reader）和新兴的去中心化协议（如基于 ActivityPub 的联合订阅）。在技术实现上，现代 RSS 生成工具通常会同时输出 RSS 2.0 和 Atom 格式以确保最大兼容性。

分离架构带来的订阅地址问题

问题在于，重构后 RSS feed 被托管在一个独立的 Cloudflare Worker 项目上，与前端项目使用的是不同的域名。这就导致用户如果想订阅，只能填写一个非直观的地址。这样的订阅地址既不美观，也不符合用户习惯——大多数人期望直接填写主域名或一个简洁的 RSS 路径即可完成订阅。互联网上已经形成了一些约定俗成的 RSS 路径惯例，如 /feed、/rss、/rss.xml、/atom.xml 等，许多 RSS 阅读器在用户输入域名时会自动尝试这些常见路径进行发现。如果 RSS 地址偏离这些惯例，不仅增加了用户的记忆负担，还会让自动发现机制失效。

更麻烦的是，由于域名不统一，一些聚合器在轮询抓取时可能出现异常，导致订阅失效，无法正常获取更新。

Cloudflare Worker 路由的解决方案

针对上述问题，Cloudflare 提供的 Worker 路由功能给出了优雅的答案。它的核心思路是：在同一个域名下，根据不同的请求路径，将流量分发到不同的后端项目。

Cloudflare Worker 基于 V8 引擎的 Isolates 技术运行，每个 Worker 实例在轻量级隔离环境中执行，启动时间仅需几毫秒，远低于传统容器或虚拟机。V8 Isolates 是 Chrome 浏览器 JavaScript 引擎的底层隔离机制，它允许在同一个进程内创建多个完全隔离的执行上下文，每个上下文有独立的堆内存和全局对象。与 Docker 容器需要完整操作系统层面隔离不同，Isolates 在语言运行时层面实现隔离，因此内存开销极小（通常只需几 MB），冷启动时间可以控制在 5 毫秒以内。这使得 Cloudflare 能在单台边缘服务器上同时运行数千个不同租户的 Worker，而不会出现性能瓶颈或安全问题。

V8 Isolates 之所以能成为边缘计算的基石，关键在于它解决了多租户环境下安全隔离与性能之间的矛盾。传统的容器隔离（如 Docker）需要完整的 Linux namespace 和 cgroup 机制，启动一个容器通常需要数百毫秒到数秒。而 V8 Isolate 的创建成本仅在微秒级别。Cloudflare 在 2018 年推出 Workers 时选择了这一技术路线，使其能够在全球边缘网络上以接近零成本运行数百万个独立的代码实例。与此同时，WebAssembly（Wasm）作为另一种边缘执行方案正在崛起，Fastly 的 Compute@Edge 就基于 Wasm，它允许开发者使用 Rust、Go 等编译型语言编写边缘逻辑，在某些 CPU 密集型场景下性能优于 JavaScript。

Worker 部署在 Cloudflare 遍布全球 300 多个城市的边缘节点上，请求会被路由到离用户最近的节点执行，因此天然具备低延迟和高可用性。这种全球分布式部署意味着无论用户身处东京、纽约还是圣保罗，他们的请求都会在地理上最接近的节点被处理，网络往返时间（RTT）通常可以控制在 20 毫秒以内。

Worker 路由（Routes）是 Cloudflare 提供的流量匹配机制：当请求的 URL 匹配某条路由规则时，该请求会被拦截并交由对应的 Worker 处理，而非直接到达源站。路由规则支持通配符（如 example.com/api/*），使得精细的路径级流量分发成为可能。路由的匹配遵循最长前缀匹配原则——当多条规则都能匹配同一个请求时，最具体的那条规则优先生效。例如 example.com/api/v2/* 会优先于 example.com/api/* 匹配。此外，还可以设置「排除路由」（即路由到 None），明确指定某些路径不经过任何 Worker 处理。这种机制本质上是在边缘层实现了反向代理的功能，但无需维护任何服务器基础设施。

配置步骤详解

具体操作非常简单，在 Cloudflare 控制台中：

1. 找到目标 Worker 项目，进入「自定义与路由」（Custom Domains / Routes）设置
2. 选择「新加路由」，添加一条自定义路由规则
3. 将特定路径（例如 rss.xml）指向 RSS feed 的 Worker 项目

配置完成后，域名下绝大多数路径的请求仍然被发往原始的前端项目，而唯独 rss.xml 这个路径的请求会被路由到 RSS feed 项目。

需要注意的是，Worker 路由与 Cloudflare Pages 的自定义域名之间存在优先级关系。当一个域名同时绑定了 Pages 项目和 Worker 路由时，Worker 路由的优先级更高——这正是本方案能够生效的前提。也就是说，Pages 负责处理所有「兜底」的请求（前端静态文件），而 Worker 路由只在特定路径上「截胡」，将请求导向其他服务。这种优先级机制让两套系统能够和谐共存。

Cloudflare Pages 是专门为前端静态站点设计的托管服务，支持与 GitHub/GitLab 仓库直接集成实现自动部署。Pages 项目会自动获得全球 CDN 分发和免费 SSL 证书。当 Pages 与 Workers 路由并存于同一域名时，Cloudflare 的流量处理链路为：DNS 解析 → Cloudflare 边缘节点 → 检查 Worker 路由规则 → 匹配则执行 Worker，不匹配则回落到 Pages。这种设计让开发者可以渐进式地为静态站点添加动态能力，而无需迁移整个架构。Pages Functions（基于 Workers 运行时）则提供了更紧密的集成方式，允许在 Pages 项目内直接编写服务端逻辑。

效果与实际价值

通过这一配置，实现了「两个独立项目共用一个域名」的目标。用户只需在阅读器中填写 域名/rss.xml，即可稳定订阅博客，Follow 等聚合器的轮询也不会再出问题。

这种方案的价值在于：

• 对外统一：用户看到的始终是一个域名，符合直觉，降低认知成本
• 对内解耦：前端项目和 RSS feed 项目依然是完全独立的两套代码和部署，各自维护、互不干扰
• 零额外成本：利用 Cloudflare 现成的边缘路由能力，无需额外搭建 Nginx 反向代理服务器。Cloudflare Workers 的免费计划每天提供 10 万次请求额度和 10 毫秒 CPU 时间限制，对于个人博客的 RSS 订阅场景完全够用

对比传统方案：Worker 路由 vs Nginx 反向代理

在传统方案里，要在一个域名下聚合多个服务，通常需要 Nginx 反向代理或 API 网关。Nginx 是目前使用最广泛的高性能 Web 服务器和反向代理软件，全球约 34% 的活跃网站使用 Nginx（根据 W3Techs 的统计数据）。Nginx 由 Igor Sysoev 在 2004 年首次发布，采用事件驱动（event-driven）的异步非阻塞架构，能够用极低的内存占用处理数以万计的并发连接——这与 Apache HTTP Server 基于进程/线程的模型形成鲜明对比，也是 Nginx 能在高并发场景下脱颖而出的核心原因。

作为反向代理时，Nginx 接收客户端请求，根据配置文件中的 location 块规则将请求转发到不同的上游服务（upstream），再将响应返回给客户端。典型的配置可能如下所示：一个 location / 块代理到前端服务，一个 location /api/ 块代理到后端 API，一个 location /rss.xml 块代理到 RSS 生成服务。这种方案灵活且功能强大，支持负载均衡（round-robin、least connections、ip-hash 等策略）、请求改写（rewrite）、缓存（proxy_cache）、限流（limit_req）等高级特性。

但它的代价是需要一台始终运行的服务器，需要处理 SSL 证书续期（虽然 Let's Encrypt 配合 certbot 可以自动化，但仍需初始配置和监控）、配置文件管理、日志监控、安全更新等运维工作。Nginx 本身虽然稳定，但承载它的服务器依然存在单点故障风险——如果这台服务器宕机，所有经过它的服务都会中断。要实现高可用，就需要引入负载均衡器、健康检查、故障转移等更多基础设施，复杂度呈指数级增长。对于个人开发者或小型项目而言，这些运维开销往往与项目本身的规模不成比例。

而 Cloudflare Worker 路由把这种能力下沉到了边缘节点，两者的核心区别如下：

对比维度	Nginx 反向代理	Cloudflare Worker 路由
需要服务器	是	否
运维成本	中等	几乎为零
配置方式	编辑配置文件	控制台点击或 API
全球加速	需额外 CDN	自带边缘节点
适用场景	复杂路由逻辑	路径级别分发
高可用性	需自行搭建	平台内置
扩缩容	手动管理	自动弹性

当然，Nginx 在某些场景下仍然不可替代。例如需要对请求体进行复杂转换、需要与内网服务通信、需要精细的缓存策略控制，或者需要在同一入口处理 WebSocket 长连接与 gRPC 协议混合流量时，一台可完全掌控的 Nginx 服务器仍是更灵活的选择。选择哪种方案，本质上取决于项目的规模和复杂度——对于个人博客和独立开发者的项目而言，Worker 路由这种「无服务器 + 边缘路由」的组合尤其友好。

扩展应用场景

同样的思路不仅限于 RSS feed，当项目规模扩大时，可以通过增加路由规则来横向扩展更多子服务：

• /api/* 路由到后端 API Worker
• /rss.xml 路由到 RSS feed Worker
• /sitemap.xml 路由到站点地图生成 Worker
• /og/* 路由到 Open Graph 图片动态生成 Worker（用于社交媒体分享时的预览卡片）
• 其他路径正常访问前端静态站点

这种模式在微服务架构中被称为「BFF」（Backend For Frontend）或「API 网关」模式的轻量级变体。传统微服务架构中，API 网关（如 Kong、Traefik、AWS API Gateway）承担着请求路由、认证鉴权、限流熔断等职责，但这些网关本身也是需要部署和维护的基础设施。Cloudflare Worker 路由以声明式的方式实现了其中最核心的「请求路由」能力，虽然功能覆盖面不及完整的 API 网关，但对于中小型项目已经足够。

这种模式让你无需改动任何一个已有项目，就能在同一域名下不断接入新服务，保持架构的整洁和可维护性。

从更宏观的视角来看，Cloudflare Worker 路由方案是边缘计算（Edge Computing）趋势的一个缩影。边缘计算将计算逻辑从集中式数据中心推向网络边缘，靠近终端用户，从而降低延迟、减少带宽消耗。根据 Gartner 的预测，到 2025 年将有 75% 的企业数据在传统数据中心或云之外的边缘进行处理，这一比例在 2018 年仅为 10%。边缘计算的兴起与 5G 网络普及、IoT 设备激增以及实时计算需求增长密切相关。

与之配合的 Serverless 模型让开发者无需关心服务器的供给、扩缩容和运维——平台按需分配资源，按实际调用次数计费。Serverless 的计费粒度通常精确到单次请求和毫秒级执行时间，这意味着没有流量时成本为零，不存在传统服务器那样的「闲置浪费」。除 Cloudflare Workers 外，类似的平台还有 AWS Lambda@Edge（基于 CloudFront CDN 的边缘计算服务）、Vercel Edge Functions（与 Next.js 框架深度集成）、Deno Deploy（基于 Deno 运行时的全球分布式部署平台）、Fastly Compute@Edge（基于 WebAssembly 的边缘计算）等。这些平台虽然实现细节不同，但核心理念一致：让开发者只关注业务逻辑，把基础设施的复杂性交给平台。

这种模式特别适合请求量波动大、对延迟敏感、但单次计算量不大的场景，如路由分发、A/B 测试、请求鉴权、内容个性化、地理位置检测、请求头改写等。

可以说，这正是现代前端架构的一种实用范式——用平台能力抹平架构复杂度，把精力真正留给内容和产品本身。

核心要点

• 前后端分离架构在带来开发效率提升的同时，也引入了域名管理和服务统一入口的挑战，尤其是 CORS 跨域和多域名维护的问题
• RSS 订阅地址对稳定性和直觉性有很高要求，独立域名的 RSS 服务会导致用户体验下降和聚合器抓取异常
• Cloudflare Worker 路由基于 V8 Isolates 技术在全球边缘节点运行，通过路径匹配规则实现同一域名下的多服务分发，本质上是无服务器化的反向代理
• 相比 Nginx 反向代理，Worker 路由免去了服务器运维、SSL 管理和高可用搭建的成本，特别适合个人开发者和中小型项目
• 该方案具备良好的可扩展性，通过增加路由规则即可接入 API、sitemap、OG 图片生成等更多子服务，是微服务网关模式的轻量替代
• 边缘计算 + Serverless 是基础设施演进的大趋势，开发者应善用平台能力来降低架构复杂度，将注意力聚焦在产品和内容本身