Cloudflare将cdnjs迁至开发者平台日均承载90亿请求

Cloudflare已完成JavaScript CDN服务cdnjs的整体迁移，将原先分布在自身与Google Cloud Platform上的发布基础设施，改为由Workers、R2、Workflows、Queues、Durable Objects、KV和Containers等开发者平台组件承载。R2成为已发布包文件的唯一权威来源，同时继续保持原有URL、文件内容及子资源完整性（SRI）哈希不变。

目前，cdnjs每天处理约90亿次请求，在超过330个Cloudflare数据中心中平均每秒约10.8万次请求，缓存命中率达到98.6%，约12%的网站会使用这项服务。Cloudflare将此次改造视为对其开发者平台进行大规模内部验证的案例。早在2020年，文件服务已迁移至Workers和Workers KV，并通过预压缩的Brotli、gzip资源提升传输效率，但发布流程仍依赖多套外部系统。

旧架构中，Google Cloud Functions定期检查npm发布包，Google Cloud Storage负责存储，Pub/Sub承担消息传递，虚拟机上的git-sync用于同步仓库内容；系统还以26个按字母划分的Cloud Functions监控包更新。由于GitHub仓库的packed存储已超过1.1TB，已发布文件同时存在于GitHub和KV中，整体链路较为分散。

新方案由R2保存发布文件，KV记录包元数据、版本和SRI哈希，Worker处理请求，Workers Cache提供缓存；若R2暂时无法提供文件，内容还会镜像至DigitalOcean Spaces作为后备。包的摄取过程改由Workflows编排：定时任务检查npm和GitHub发布，将包下载到R2，再为每个文件启动处理流程，完成内容提取、代码压缩、结果写回R2、KV元数据更新及Algolia搜索索引刷新。流程状态支持从最近完成的步骤恢复。

由于现有压缩算法必须将整个库加载进内存，压缩任务目前由Containers执行，而不是直接放在Workers中，后续Cloudflare正探索流式处理，以便迁移回Workers。为确保压缩或混淆不会改变SRI哈希，发布包的字节内容必须保持一致。迁移期间，平台还将Worker子请求上限从1000提升至1000万，并把Workflow步骤上限从1024提高到10000，另提供最高25000的可配置上限。最终架构形成R2存储制品、KV保存元数据、Workers负责交付、Workflows负责发布的分工。