边缘计算范式已从小众部署策略转变为一等架构选择。随着 Cloudflare Workers 现在支持 D1 —— 他们的分布式 SQLite 数据库 —— 全球分布式应用亚 50ms 响应时间的承诺已成为现实。
本文探索如何构建一个在边缘处理 RSS Feed 的数据采集管道，标准化内容，并从最近的存在点（PoP）提供给客户端。关键洞察是，边缘优先架构并不意味着只有边缘 —— 它意味着边缘优先。
架构概览
典型的 EdgeFeed 采集管道由三层组成：采集器、转换器和存储器。每一层作为独立的 Worker 运行，通过 Durable Objects 进行协调通信。
边缘计算的真正力量不仅仅是速度 —— 而是在数据被消费的地方处理数据，将延迟从限制转化为优势。
采集器在 cron 触发器上运行，以可配置的间隔拉取 RSS Feed。它处理 HTTP 缓存、ETag 验证和条件 GET 以最小化带宽消耗。以下是采集逻辑的简化版本：
export default {
async scheduled(event, env, ctx) {
const feeds = await env.DB.prepare(
'SELECT url, etag FROM feeds WHERE active = 1'
).all();
for (const feed of feeds.results) {
const response = await fetch(feed.url, {
headers: { 'If-None-Match': feed.etag }
});
if (response.status === 304) continue;
const xml = await response.text();
const etag = response.headers.get('etag');
await env.DB.prepare(
'UPDATE feeds SET etag = ?, raw_xml = ? WHERE url = ?'
).bind(etag, xml, feed.url).run();
}
}
};D1 作为数据真相源
Cloudflare D1 提供跨区域复制的 SQLite 兼容数据库。虽然它并非为高写入负载设计，但作为面向客户端提供标准化 Feed 数据的读多写少存储，表现出色。
我们采用的模式很简单：在边缘本地写入，从最近副本读取。一致性是最终一致的，这对于几秒钟内的陈旧度可接受的 RSS 内容来说是可接受的。
一个重要的考虑是连接池。由于 Workers 是短暂的，每次调用都会创建新的数据库连接。D1 透明地处理这一点，但值得注意连接开销包含在你的 p99 延迟预算中。
性能特征
我们的基准测试显示以下典型 Feed 服务工作负载结果：
- 读取延迟（单行）：
~5ms，最近 PoP - 读取延迟（50 行）：
~12ms，使用预处理语句 - 写入延迟（单行）：
~15ms，含复制 - 缓存命中率：
94.2%，跨所有 PoP
这些数据相比请求必须穿越多个网络跳才能到达中心化数据库的传统架构有显著提升。边缘原生方式消除了通常占据请求时间主导地位的跨区域延迟。
对 RSS 阅读器应用的启示很明确：通过在边缘处理和提供 Feed 内容，我们可以提供一种无论用户身在何处都感觉本地的阅读体验。Workers 负责计算、D1 负责存储、全球 Cloudflare 网络负责传输的组合，为内容中心型应用创造了极具吸引力的技术栈。
EdgeFeed 正构建于这一架构之上，过去三个月我们以中位响应时间低于 20ms 提供 RSS 内容。如果你对技术细节感兴趣，EdgeFeed 工程博客深入介绍了这一架构。