Cloudflare 近期宣布將其知名的開源 JavaScript 與 CSS 庫 CDN 服務 cdnjs 全面遷移至自家的開發者平台。cdnjs 作為全球極其重要的基礎設施，目前約有 12% 的網站在使用該服務，日均處理請求量高達 90 億次，平均每秒需應對 10.8 萬次請求。這次遷移不僅是技術架構的升級，更是 Cloudflare 實踐 Dogfooding（開發者對自家產品進行壓力測試）的典型案例，旨在證明其伺服器端平台能夠承載極大規模的公共服務。
背景與舊有架構的痛點
在本次全面遷移之前，cdnjs 的運作採取了一種混合雲的分散式架構。雖然 Cloudflare 在 2020 年就已將文件分發層移至 Workers（一種在邊緣節點執行的輕量級伺服器端腳本）與 Workers KV（一種分佈式鍵值存儲），以取代傳統的來源伺服器，但其背後的發佈流程（Publishing Path）依然依賴於外部基礎設施。
當時的發佈流程高度依賴 Google Cloud Platform，包含使用 Google Cloud Functions 定期監控 npm 上的套件更新，並將檔案儲存在 Google Cloud Storage 中，同時利用 Pub/Sub 處理訊息傳遞，並透過虛擬機運行的 git-sync 進行儲存庫同步。這種分佈式設計導致了管理複雜度增加，且 GitHub 儲存庫的體積已增長至 1.1 TB，而發佈的文件在 GitHub 與 KV 之間存在冗餘，缺乏單一且高效的真相來源。
核心架構的重組與運作方式
為了簡化流程並提升效率，Cloudflare 將整個發佈與分發鏈路整合至其開發者平台。在新架構中，R2（Cloudflare 的 S3 兼容對象儲存服務）正式成為所有已發佈套件文件的唯一真相來源（Source of Truth），取代了之前的 Google Cloud 儲存。而套件的元數據、版本資訊以及 SRI 哈希值（Subresource Integrity，用於驗證檔案未被篡改的安全性標記）則儲存在 KV 中。
在發佈流程上，Cloudflare 引入了 Workflows（一種可編排的伺服器端工作流工具）來協調套件的攝取。系統會透過排程工作流檢查 npm 與 GitHub 的更新，將套件下載至 R2，隨後啟動個別文件的處理工作流。這些處理步驟包括解壓縮套件、進行代碼壓縮（Minification）與文件壓縮，將結果存回 R2，更新 KV 元數據，並同步更新 Algolia 搜尋索引。由於 Workflows 具備狀態管理能力，即使在處理過程中發生故障，也能從最後一個完成的步驟恢復，而不需要重新開始整個流程。
技術挑戰與實務限制
在遷移過程中，Cloudflare 面臨的主要技術挑戰在於壓縮演算法的記憶體限制。目前的壓縮處理需要將整個庫緩存在記憶體中，這超出了 Workers 的執行環境限制。因此，Cloudflare 採取了折衷方案，使用 Containers（容器化環境）來執行壓縮任務，而非直接在 Workers 中處理。目前官方正研究串流（Streaming）支持，期許未來能將此步驟完全移至 Workers 中執行。
此外，維持檔案位元（Bytes）的一致性至關重要。因為任何微小的壓縮或最小化差異都會導致 SRI 哈希值改變，進而導致使用該 CDN 的網站因安全性驗證失敗而無法載入腳本。為了確保無縫遷移，Cloudflare 必須確保新舊環境產出的檔案完全一致。
影響與平台演進
這次大規模遷移直接推動了 Cloudflare 開發者平台功能的演進。在實作過程中，cdnjs 的需求揭露了平台原有的限制，促使 Cloudflare 顯著提升了配額：將 Worker 的子請求（Subrequests）上限從 1,000 次大幅提升至 1,000 萬次，並將 Workflow 的步驟上限從 1,024 步提升至 10,000 步（最高可配置至 25,000 步）。
最終，cdnjs 達成了一個極其精簡的技術棧：使用 R2 儲存成品、KV 管理元數據、Workers 負責全球分發，以及 Workflows 驅動發佈流程。目前的系統在超過 330 個數據中心運行，快取命中率（Cache Hit Rate）高達 98.6%，證明了全棧伺服器端架構在處理海量靜態資源分發時的穩定性與高效能。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。