Cloudflare 将每天 90 亿次请求的 JavaScript CDN 迁移到其开发者平台

Cloudflare已经将 cdnjs "完整迁移到其开发者平台，用Workers、R2、Workflows、Queues、Durable Objects、KV和Containers替换了分布在Cloudflare与Google Cloud Platform上的发布基础设施。迁移还将R2设置为已发布包文件的权威来源，同时保留了现有的URL、包内容和子资源完整性（Subresource Integrity，SRI）哈希。 Cloudflare 表示 "，cdnjs当前大约每天处理90亿次请求，平均在超过330个Cloudflare数据中心中每秒约108,000次请求。该服务报告缓存命中率为98.6%，约12%的网站使用cdnjs。Cloudflare将此次迁移描述为在广泛使用的公共服务规模上对其开发者平台进行 内部验证（dogfooding） "的示例。 此次迁移基于2020年的一次架构调整，Cloudflare当时将cdnjs的文件服务迁移到了 Workers "和 Workers KV "，在常规流量下替代了专用源服务器，同时保留外部源作为回退方案。Cloudflare还引入了预压缩的Brotli和gzip资源以提高传输效率。 然而，发布路径一直保持着分散的状态：Google Cloud Functions定期检查npm以获取发布包、Google Cloud Storage存储包、Pub/Sub负责消息传递，并且有一台运行git-sync的虚拟机同步仓库内容。系统使用26个按字母分片的Cloud Functions来监控包更新。与此同时，GitHub仓库的packed存储已超过1.1 TB，而已发布的文件在GitHub和KV中都有表述。 先前的cdnjs发布与服务架构（来源： Cloudflare博客 "） 新架构将 Cloudflare R2 "作为已发布文件的权威来源。KV存储包的元数据、版本和SRI哈希，Worker负责请求处理， Workers Cache "提供缓存层。如果R2无法提供文件，已发布内容还会镜像到DigitalOcean Spaces作为回退方案。 包摄取现在由 Cloudflare Workflows "进行编排。一个定时工作流会检查npm和GitHub的发布，将包下载到R2，并为单个文件启动处理工作流。处理流水线提取包内容、进行代码压缩与压缩存储处理结果到R2、更新KV中的元数据，并刷新Algolia搜索索引。工作流状态允许在失败后从上次完成的步骤恢复处理。 采用R2、Workers、KV与Workflows的新cdnjs架构。（来源： Cloudflare博客 "） 压缩处理存在一定限制，因为现有的处理算法需要将整个库缓冲到内存中。因此，Cloudflare使用 Containers "来完成压缩工作，而不是直接在Workers中运行。Cloudflare表示正在探索流式支持，未来可能将此处理迁移到Workers。 保持包字节不变至关重要，因为对混淆或压缩的更改可能会改变SRI哈希。迁移还暴露了平台限制，促使Cloudflare将Worker子请求限制从1,000提高到1,000万，并将Workflow步骤从1,024提升到10,000，可配置上限为25,000。最终的架构使用R2存储制品、KV存储元数据、Workers负责交付、Workflows负责发布。 查看英文原文： Cloudflare Migrates JavaScript CDN Serving 9B Requests a Day to Its Developer Platform "