大规模自用实践：将cdnjs迁移至Cloudflare开发者平台
内容提要
cdnjs已完全迁移至Cloudflare开发者平台，每日处理90亿请求。新架构以R2为存储核心，Workflows处理发布流程，KV存元数据，并利用Containers压缩文件。迁移中提升了平台限制（子请求上限至1000万，Workflow步骤至1万）。此举简化运维、增强可观测性，并可能支持未来ES模块服务。
延伸解读
迁移背后的平台能力提升
cdnjs迁移过程中，Cloudflare开发者平台针对实际需求提升了限制：Workers子请求上限从1000提升至1000万，Workflow步骤数从1024提升至10000（可配置至25000）。这些调整并非仅为cdnjs服务，而是对所有开发者开放，意味着平台在处理大规模、复杂工作流方面的能力得到增强，为类似高负载场景提供了更广阔的空间。
架构选择：R2与KV的分工
新架构中，R2作为文件内容的唯一存储，解决了KV在存储大文件（如source maps、字体包）上的限制，同时通过S3 API开放了目录访问。KV则仅存储元数据，利用其高读低写的特性。这种分工优化了存储成本与访问效率，也简化了数据一致性管理，因为文件内容不再分散在多个存储系统中。
迁移中的挑战与应对
迁移并非一帆风顺。早期尝试重新处理旧包导致文件字节不一致，SRI哈希变化，可能破坏用户固定哈希的引用，因此回滚。最终选择原样复制KV内容至R2，避免了重新生成。迁移过程中还面临子请求限制，通过按包名分片并使用Queues的至少一次投递保证，确保无遗漏。这些经验对类似大规模数据迁移具有参考价值。
未来展望：ES模块服务的可能性
文章指出，新架构使得未来提供ES模块服务成为可能。当前Workflows与Containers的组合已用于预压缩文件，同样可用于转换文件为ES模块格式。虽然尚未承诺，但这一可能性因平台能力的提升而变得现实，可能进一步扩展cdnjs的用途，适应现代前端开发趋势。
Q&A
cdnjs迁移到Cloudflare开发者平台后，每日处理多少请求？
cdnjs迁移后每日处理90亿个请求，平均每秒108,000个请求。
cdnjs迁移到Cloudflare开发者平台的主要原因是什么？
迁移的主要原因是为了简化运维和提升可观测性。旧架构涉及GCP Functions、VM和Cloudflare等多个组件，调试困难，且发布流程复杂。新架构统一在Cloudflare平台上，减少了运维负担。
cdnjs新架构中，R2、KV和Workflows分别承担什么角色？
R2作为文件内容的唯一真实来源，存储所有文件；KV存储元数据，如包信息、版本列表和SRI哈希；Workflows负责处理发布流程，包括检查更新、下载、处理和发布。
cdnjs迁移过程中遇到了哪些平台限制？
迁移中遇到了两个平台限制：每个Worker调用的子请求上限为1,000个，以及每个Workflow的步骤上限为1,024步。Cloudflare后来将子请求上限提升至1000万，Workflow步骤默认提升至10,000步，可配置至25,000步。
cdnjs如何保证文件在迁移过程中不丢失？
迁移时采用分片方式，按包名分片，并通过Queues的至少一次投递保证，确保每个包都能被处理，不会遗漏。
cdnjs未来可能支持ES模块服务吗？
有可能。新架构中的Workflows和Containers模式可以用于转换文件，未来可能支持ES模块，但尚未承诺。
