1. 拆解名字cloudflare-os 到底在說什么1.1 名字里的三層意思cloudflare-os 這個(gè)標(biāo)題第一眼看上去挺唬人很容易讓人以為 Cloudflare 官方發(fā)布了一個(gè)操作系統(tǒng)。但稍微熟悉云服務(wù)的人都知道Cloudflare 做的是 CDN、安全防護(hù)、邊緣計(jì)算這一整套東西它并沒有像微軟、谷歌那樣推一個(gè)面向大眾的操作系統(tǒng)。那為什么技術(shù)社區(qū)里還經(jīng)常出現(xiàn)這個(gè)叫法我的理解是這個(gè)名字其實(shí)指向了三層不同的東西。第一層是基于產(chǎn)品堆疊的“操作系統(tǒng)感”。Cloudflare 的 Workers、Workflows、KV、D1、R2、Access、Logpush 這些產(chǎn)品組合在一起已經(jīng)覆蓋了一個(gè)傳統(tǒng)操作系統(tǒng)最核心的功能Worker 是進(jìn)程Workflows 是調(diào)度器Cron Triggers 是定時(shí)任務(wù)KV 和 D1 是文件系統(tǒng)與數(shù)據(jù)庫R2 是對(duì)象存儲(chǔ)Access 是登錄認(rèn)證Logpush 是內(nèi)核日志。把這些拼起來看它確實(shí)有資格被戲稱為“云操作系統(tǒng)”。第二層是社區(qū)對(duì)“邊緣操作系統(tǒng)”的探索。很多開發(fā)者并不滿足于只把 Cloudflare 當(dāng)作 CDN 或前端托管平臺(tái)而是想把它當(dāng)成一臺(tái)分布在全球、天然帶容災(zāi)、不需要運(yùn)維的“巨型主機(jī)”來用。在這種心態(tài)下cloudflare-os 變成了一種個(gè)人實(shí)驗(yàn)的代號(hào)用邊緣平臺(tái)替代傳統(tǒng)服務(wù)器用 Worker 替代 systemd 服務(wù)用隊(duì)列替代消息中間件。第三層則是一些誤讀和以訛傳訛?？倳?huì)有人把 Cloudflare 內(nèi)部某個(gè)項(xiàng)目代號(hào)、某次技術(shù)分享里提到的內(nèi)部操作系統(tǒng)名字或者是某個(gè)開源鏡像項(xiàng)目的名字直接安在“cloudflare-os”頭上。這種東西傳得廣但和我們要聊的工程實(shí)踐關(guān)系不大。1.2 為什么它不是傳統(tǒng)操作系統(tǒng)要理解 cloudflare-os得先回答一個(gè)問題傳統(tǒng)操作系統(tǒng)到底是干什么的簡單說一個(gè)操作系統(tǒng)要管理進(jìn)程、內(nèi)存、文件系統(tǒng)、設(shè)備驅(qū)動(dòng)、網(wǎng)絡(luò)協(xié)議棧還得負(fù)責(zé) CPU 調(diào)度、權(quán)限隔離、崩潰恢復(fù)。你寫一個(gè) C 程序跑在 Linux 上程序通過系統(tǒng)調(diào)用向內(nèi)核申請(qǐng)資源你在上面部署 MySQLMySQL 按它的方式管理內(nèi)存和磁盤。Cloudflare 的邊緣不一定給你一個(gè)完整的 Linux 內(nèi)核讓你隨便操作。你在邊緣上接觸到的是事件回調(diào)接口。Worker 的代碼收到一個(gè) fetch 請(qǐng)求返回一個(gè) Response平臺(tái)會(huì)自動(dòng)處理底層的網(wǎng)絡(luò)棧、隔離、擴(kuò)縮容、故障遷移。打個(gè)比方傳統(tǒng)服務(wù)器相當(dāng)于給你一把后廚鑰匙你可以自己開火、切菜、擺盤自由度極高但很累。Cloudflare 給的是一個(gè)點(diǎn)餐窗口加一套固定菜單你把菜名寫好遞進(jìn)去后廚自己安排如果你想在后廚里自己發(fā)明一種做法那對(duì)不起得先看平臺(tái)支不支持這種“做法”。這個(gè)差異決定了 cloudflare-os 是完全不同于 Windows、Linux 的新物種。它不是給你一個(gè)長的像桌面的界面也不是讓你能 SSH 進(jìn)去敲命令的環(huán)境而是一套建立在 HTTP 語義和 JavaScript 運(yùn)行時(shí)之上的分布式調(diào)度體系。1.3 這套“操作系統(tǒng)”解決了什么問題傳統(tǒng)服務(wù)器時(shí)代的研發(fā)流程大概是這樣買機(jī)器、裝系統(tǒng)、裝運(yùn)行時(shí)、部署代碼、配監(jiān)控、設(shè)告警、擴(kuò)容縮容、處理宕機(jī)遷移。光是“處理宕機(jī)遷移”這一項(xiàng)就夠一個(gè)小團(tuán)隊(duì)折騰好幾個(gè)通宵。而 cloudflare-os 這一類邊緣平臺(tái)把這些問題抽象成了平臺(tái)自身的職責(zé)。對(duì)個(gè)人開發(fā)者來說它最大的價(jià)值是成本極低、上線極快。你不用再為一個(gè)小博客、一個(gè) RSS 聚合器、一個(gè)定時(shí)任務(wù)去租一臺(tái)云服務(wù)器并維護(hù)系統(tǒng)補(bǔ)丁寫一個(gè) Worker部署上去得到一個(gè) URL全程不超過十分鐘。對(duì)團(tuán)隊(duì)來說它可以承擔(dān) API 網(wǎng)關(guān)、邊緣鑒權(quán)、圖片處理、AB 測(cè)試、灰度發(fā)布這些任務(wù)好處是請(qǐng)求在全球任何地方到達(dá)都由離用戶最近的邊緣節(jié)點(diǎn)處理延遲天然低。但也要說清楚它的局限性。這套“操作系統(tǒng)”并不是全能的它不擅長跑那些依賴完整 Linux 環(huán)境的二進(jìn)制程序也不適合需要長時(shí)間占用內(nèi)存的有狀態(tài)服務(wù)。當(dāng)你決定踩進(jìn) cloudflare-os 這條路線時(shí)首先得接受一個(gè)事實(shí)你進(jìn)入的是一個(gè)“平臺(tái)托管”的世界自由度和傳統(tǒng)服務(wù)器不是一個(gè)維度。2. 整體設(shè)計(jì)與方案選型一個(gè)“邊緣最小 OS”該怎么做2.1 設(shè)計(jì)目標(biāo)與性能約束如果真要把 cloudflare-os 當(dāng)成一個(gè)項(xiàng)目來做最合理的定位是構(gòu)建一套跑在 Cloudflare 邊緣網(wǎng)絡(luò)上的最小可用運(yùn)行時(shí)系統(tǒng)。我給自己定的目標(biāo)只有四個(gè)毫秒級(jí)冷啟動(dòng)、租戶隔離、全球調(diào)度、有限狀態(tài)持久化。這幾個(gè)目標(biāo)不是拍腦袋定的而是邊緣計(jì)算場景的硬約束。毫秒級(jí)冷啟動(dòng)意味著用戶請(qǐng)求到達(dá)時(shí)代碼必須立刻被執(zhí)行不能出現(xiàn)傳統(tǒng)容器那種“先拉鏡像再啟動(dòng)進(jìn)程”的幾百毫秒延遲。租戶隔離要求不同業(yè)務(wù)、不同用戶的數(shù)據(jù)和代碼不會(huì)被互相干擾。全球調(diào)度要求同一份代碼在東京、法蘭克福、圣保羅、悉尼這些節(jié)點(diǎn)上都能快速跑起來。狀態(tài)持久化則是對(duì)“操作系統(tǒng)”的基本訴求至少得能記住一些東西不能重啟一次就全丟。但 Cloudflare 的免費(fèi)額度相當(dāng)有限這是個(gè)很現(xiàn)實(shí)的問題。每個(gè)請(qǐng)求的 CPU 時(shí)間在免費(fèi)檔可能只有 10ms 左右墻鐘時(shí)間有 30 秒上限單請(qǐng)求能發(fā)起的子請(qǐng)求數(shù)量也有限。這種約束倒逼你設(shè)計(jì)代碼時(shí)必須保持“邏輯輕、狀態(tài)外置、調(diào)用分散”的風(fēng)格。換句話說Cloudflare 不適合你把一段很重的計(jì)算塞進(jìn)一個(gè)請(qǐng)求里它更希望你把它拆成多個(gè)小任務(wù)、異步處理。我在實(shí)際搭建的時(shí)候設(shè)計(jì)原則記在備忘里就一句話能異步的別同步能緩存的別直讀能拆小的別做大。這套原則幫我避掉了后面不少資源超限的坑。2.2 兩條技術(shù)路線Wasm 運(yùn)行時(shí)還是微虛擬機(jī)Cloudflare 邊緣計(jì)算底層其實(shí)同時(shí)存在兩種隔離形態(tài)一種是 V8 引擎的 JavaScript/Wasm 運(yùn)行時(shí)另一種是以 Firecracker 為代表的輕量級(jí)虛擬機(jī)。很多人在討論 cloudflare-os 時(shí)會(huì)糾結(jié)“到底哪條路線才算真正的操作系統(tǒng)”。兩條路線各有各的適用場景。Wasm/V8 路線的優(yōu)點(diǎn)是冷啟動(dòng)極快、內(nèi)存占用小、開發(fā)者上手成本低但它只能運(yùn)行平臺(tái)支持的運(yùn)行時(shí)語言而且不能直接執(zhí)行任意 Linux 二進(jìn)制。微虛擬機(jī)路線的優(yōu)點(diǎn)是隔離性強(qiáng)可以跑更通用的 Linux 程序但它啟動(dòng)更慢、差旅開銷更大調(diào)度成本也更高。維度V8/Wasm Worker微虛擬機(jī)Firecracker 風(fēng)格冷啟動(dòng)速度毫秒級(jí)百毫秒級(jí)內(nèi)存占用低中高隔離強(qiáng)度進(jìn)程級(jí)沙箱硬件虛擬化隔離可運(yùn)行程序僅平臺(tái)支持的語言/字節(jié)碼更通用的 Linux 程序部署產(chǎn)物代碼 bundle磁盤鏡像運(yùn)維體驗(yàn)只管代碼可能要關(guān)心鏡像和啟動(dòng)參數(shù)典型云產(chǎn)品Cloudflare WorkersAWS Lambda 的部分底層方案從產(chǎn)品線上看Cloudflare 顯然把大部分資源投入了 V8/Wasm 這一側(cè)因?yàn)樗罘稀斑吘壵?qǐng)求量巨大、資源被切得很碎”的場景。我自己做實(shí)驗(yàn)時(shí)也從沒考慮過微虛擬機(jī)路線原因很簡單現(xiàn)階段在 Cloudflare 上跑微虛擬機(jī)的入口并不像 Workers 那樣順手社區(qū)資料少調(diào)試成本高。用生活化的比喻來說如果傳統(tǒng)虛擬機(jī)是“請(qǐng)一個(gè)大廚到家里做菜”那 Worker 就是“一個(gè)隨叫隨到的預(yù)制菜師傅”。你不需要關(guān)心他有沒有自己的廚房、需要多久才能到你家他收到你的菜單后會(huì)在最近的廚房里做做完就走。代價(jià)是你不能要求他做菜單之外的菜。2.3 無服務(wù)器不等于無系統(tǒng)最容易踩的一個(gè)認(rèn)知陷阱是把“無服務(wù)器”理解成“無系統(tǒng)”。我在不少項(xiàng)目的評(píng)審會(huì)上見過這種情況代碼寫得很歡覺得自己不需要管服務(wù)器了結(jié)果一上線就開始出問題查了半天才發(fā)現(xiàn)是并發(fā)寫沖突、狀態(tài)丟失、超時(shí)重試沒處理好。無服務(wù)器的意思是服務(wù)器由平臺(tái)托管、你不用去買不用去修但系統(tǒng)設(shè)計(jì)里的“狀態(tài)管理、并發(fā)控制、失敗恢復(fù)”這些核心問題一個(gè)都不會(huì)消失只是換了一種存在形態(tài)。你說你不關(guān)心服務(wù)器了但你仍需要關(guān)心這個(gè) Worker 是否以全局變量的形式在內(nèi)存里保留狀態(tài)如果下次請(qǐng)求被調(diào)度到另一個(gè)城市、另一個(gè)進(jìn)程里這個(gè)狀態(tài)還在嗎答案通常是不在。所以構(gòu)建 cloudflare-os 的時(shí)候我要求自己一開始就按“無狀態(tài)邏輯 外置存儲(chǔ)”的架構(gòu)來設(shè)計(jì)。Worker 只做輸入輸出、路由、簡單的計(jì)算真正的持久化數(shù)據(jù)全部放在 KV、D1、R2 這類平臺(tái)托管存儲(chǔ)里需要長期運(yùn)行編排的任務(wù)丟給 Workflows需要跨服務(wù)傳遞消息的時(shí)候用 Queues。這樣設(shè)計(jì)出來的系統(tǒng)無論被調(diào)度到哪個(gè)節(jié)點(diǎn)都能保持行為一致。3. 實(shí)操過程從零搭一個(gè)“邊緣 OS 雛形”3.1 準(zhǔn)備環(huán)境我自己用的是 macOS 終端Windows 用戶用 PowerShell 也沒問題。第一步是安裝 Wrangler CLI這是操作 Cloudflare 邊緣資源的官方命令行工具有點(diǎn)類似你平時(shí)用 kubectl 操作 Kubernetes 集群。安裝命令如下npm install -g wrangler wrangler loginwrangler login會(huì)在瀏覽器里彈出授權(quán)頁你登錄 Cloudflare 賬號(hào)并授權(quán)后本地環(huán)境就拿到了操作權(quán)限。我建議用這種方式而不是手動(dòng)配置 API Token因?yàn)榍罢甙踩?、簡單且可以隨時(shí)在賬號(hào)設(shè)置里吊銷適合日常開發(fā)。如果你還沒有賬號(hào)先去 Cloudflare 官網(wǎng)注冊(cè)一個(gè)免費(fèi)賬號(hào)。免費(fèi)賬號(hào)能做的事情已經(jīng)很多了完全可以完成這份教程里的全部實(shí)驗(yàn)。3.2 創(chuàng)建一個(gè)“系統(tǒng)進(jìn)程”基礎(chǔ) Worker我創(chuàng)建的項(xiàng)目名叫edge-os-lab創(chuàng)建命令直接用了官方腳手架npm create cloudflarelatest edge-os-lab -- --template hello-world選擇 TypeScript 模板項(xiàng)目結(jié)構(gòu)大概是這樣的wrangler.toml是項(xiàng)目配置src/index.ts是 Worker 入口代碼。打開wrangler.toml加上自己的配置name edge-os-lab main src/index.ts compatibility_date 2024-09-23 [observability] enabled true然后我來寫一個(gè)能“假裝自己是系統(tǒng)”的 Worker。第一個(gè)接口是系統(tǒng)信息查詢用來返回當(dāng)前處理請(qǐng)求的邊緣機(jī)房、國家、時(shí)間戳等信息export default { async fetch(request: Request): PromiseResponse { const url new URL(request.url); if (url.pathname /api/sysinfo) { return Response.json({ system: edge-os-lab, version: 0.1.0, colo: request.cf?.colo ?? unknown, country: request.cf?.country ?? unknown, timestamp: new Date().toISOString(), }); } return new Response(Welcome to edge-os-lab, { headers: { content-type: text/plain; charsetutf-8 }, }); }, };部署很簡單npx wrangler deploy部署完成后Cloudflare 會(huì)給你一個(gè)*.workers.dev的地址。拿瀏覽器訪問/api/sysinfo會(huì)看到一個(gè) JSON 響應(yīng)里面包含了處理請(qǐng)求的機(jī)房三字碼比如HKG、NRT、SJC。我第一次看到響應(yīng)里colo字段在不同地區(qū)訪問時(shí)返回不同代碼時(shí)才真正意識(shí)到這套“系統(tǒng)”真的是按地理位置全球分布的。這里有一個(gè)小小的知識(shí)點(diǎn)Worker 里的fetch(request)本質(zhì)上就是一個(gè)“系統(tǒng)調(diào)用”入口平臺(tái)收到 HTTP 請(qǐng)求后調(diào)用你的代碼你返回響應(yīng)底層一切網(wǎng)絡(luò)收發(fā)包都由平臺(tái)代勞。你可以把它理解為 syscall 的語義化版本。3.3 用 KV“虛擬文件系統(tǒng)”保存配置一個(gè)操作系統(tǒng)必須有文件系統(tǒng)我選擇拿 Cloudflare KV 來模擬“虛擬文件系統(tǒng)”這一層。KV 的語義是鍵值存儲(chǔ)讀多寫少適合存放配置、元數(shù)據(jù)、開關(guān)標(biāo)志這類數(shù)據(jù)。先創(chuàng)建一個(gè) KV namespacenpx wrangler kv namespace create EDGE_KV命令會(huì)輸出一個(gè)id這個(gè) id 要填進(jìn)wrangler.toml。然后往 KV 里寫入兩條虛擬文件路徑作為測(cè)試數(shù)據(jù)npx wrangler kv key put --bindingEDGE_KV proc/version edge-os-lab 0.1.0 (worker) npx wrangler kv key put --bindingEDGE_KV etc/hostname edge-node-hkg-1修改wrangler.toml給 Worker 綁定這個(gè) KVname edge-os-lab main src/index.ts compatibility_date 2024-09-23 kv_namespaces [ { binding EDGE_KV, id 你的命名空間ID } ] [observability] enabled true再更新src/index.ts增加一個(gè)讀取“虛擬文件”的接口interface Env { EDGE_KV: KVNamespace; } export default { async fetch(request: Request, env: Env): PromiseResponse { const url new URL(request.url); if (url.pathname.startsWith(/api/cat)) { const key url.pathname.replace(/api/cat/, ); const value await env.EDGE_KV.get(key); if (value null) { return new Response(not found, { status: 404 }); } return new Response(value, { headers: { content-type: text/plain; charsetutf-8 }, }); } if (url.pathname /api/sysinfo) { return Response.json({ system: edge-os-lab, version: 0.1.0, colo: request.cf?.colo ?? unknown, country: request.cf?.country ?? unknown, timestamp: new Date().toISOString(), }); } return new Response(Welcome to edge-os-lab, { headers: { content-type: text/plain; charsetutf-8 }, }); }, };部署后再訪問/api/cat/proc/version就能讀到剛才寫入的值。用這套機(jī)制你完全可以把業(yè)務(wù)配置外置到 KV 里改配置時(shí)不用重新發(fā)布代碼直接wrangler kv key put更新即可這個(gè)體驗(yàn)很像在 Linux 里直接覆寫/proc和/etc下的文件。注意一點(diǎn)KV 的寫入是全局最終一致的極端情況下剛寫入的數(shù)據(jù)在其他區(qū)域可能不能立刻讀到。所以 KV 適合放不敏感、允許短暫不一致的數(shù)據(jù)不要拿它做數(shù)據(jù)庫。真正需要強(qiáng)一致的時(shí)候該用 D1 或 Durable Objects 就老實(shí)換。3.4 用 Workflows 管理“守護(hù)進(jìn)程”如果 Worker 解決的是“系統(tǒng)里跑一個(gè)進(jìn)程”那 Workflows 解決的是“系統(tǒng)里跑一個(gè)可以被暫停、恢復(fù)、重試的長期任務(wù)”。Cloudflare Workflows 允許你把任務(wù)拆成多個(gè)步驟每一步都可以休眠、可以單獨(dú)失敗重試平臺(tái)會(huì)把執(zhí)行狀態(tài)持久化下來。我實(shí)現(xiàn)了一個(gè)簡單的心跳任務(wù)模擬那種每隔一段時(shí)間匯報(bào)一次運(yùn)行狀態(tài)的守護(hù)進(jìn)程import { WorkflowEntrypoint, WorkflowEvent, WorkflowStep } from cloudflare:workers; export class HeartbeatWorkflow extends WorkflowEntrypointEnv, unknown { async run(event: WorkflowEventunknown, step: WorkflowStep) { await step.sleep(wait, 10 seconds); await step.do(report, async () { console.log(heartbeat at, new Date().toISOString()); return { ok: true }; }); } }把 Workflows 類比成 systemd其實(shí)比想象中更貼切傳統(tǒng)服務(wù)器上你用 systemd 管理服務(wù)的開機(jī)自啟、重啟、定時(shí)執(zhí)行Workflows 則在邊緣側(cè)管理長時(shí)運(yùn)行任務(wù)的步驟編排、重試、狀態(tài)存儲(chǔ)。這種設(shè)計(jì)非常適合做訂單超時(shí)關(guān)閉、定期拉取數(shù)據(jù)、多階段批處理這類任務(wù)。順便提一下 Cron Triggers。如果只是想要一個(gè)定時(shí)任務(wù)也可以在wrangler.toml里加[triggers] crons [*/5 * * * *]每 5 分鐘Cloudflare 會(huì)主動(dòng)向你的 Worker 發(fā)一個(gè)定時(shí)事件你的代碼可以在scheduled處理器里干活。這個(gè)功能相當(dāng)于操作系統(tǒng)的 cron 服務(wù)對(duì)于“定時(shí)抓個(gè)網(wǎng)頁存到 KV”“定時(shí)發(fā)個(gè)郵件通知”這類需求非常夠用。3.5 用 Secret 管理“系統(tǒng)密鑰”操作系統(tǒng)里不能把密碼明文寫在配置里邊緣平臺(tái)也一樣。Wrangler 提供了 Secret 管理npx wrangler secret put SYSTEM_TOKEN執(zhí)行后終端會(huì)提示你輸入值輸入完后這個(gè)值會(huì)以加密方式綁定到你的 Worker 環(huán)境變量上。在代碼里拿到它的方式是export default { async fetch(request: Request, env: Env): PromiseResponse { return new Response(env.SYSTEM_TOKEN ? token present : no token); }, };Secret 不會(huì)出現(xiàn)在wrangler.toml里也不會(huì)被提交到 Git。這是我把所有第三方 API Key、內(nèi)部認(rèn)證令牌都放在這里的根本原因。之前見過有人把密鑰直接寫死在 Worker 代碼里并推送到 GitHub 倉庫幾分鐘內(nèi)就被爬蟲掃到那真叫一個(gè)慘。4. 核心細(xì)節(jié)與常見問題排查實(shí)錄4.1 冷啟動(dòng)被什么東西拖慢冷啟動(dòng)的時(shí)間是邊緣系統(tǒng)最敏感的指標(biāo)之一。我第一次上線比較重的 Worker 時(shí)明顯能感覺到請(qǐng)求變慢排查之后發(fā)現(xiàn)主要瓶頸有幾個(gè)。第一個(gè)是代碼包體積。Worker 雖然部署的是代碼但平臺(tái)需要把 bundle 下發(fā)到執(zhí)行節(jié)點(diǎn)包越大啟動(dòng)越慢。我試過在 Worker 里引入一個(gè)體積不小的圖像處理庫冷啟動(dòng)延遲直接從幾十毫秒飆到幾百毫秒。后來我把不需要的依賴全部移除能用原生 API 解決的絕不上庫延遲立刻回落到正常水平。第二個(gè)是模塊頂層的初始化邏輯。如果你在模塊頂層做大量計(jì)算、讀配置、初始化第三方 SDK那么 Worker 每次冷啟動(dòng)都要執(zhí)行一遍。正確做法是懶加載在真正需要的時(shí)候再初始化或者把初始化結(jié)果緩存到模塊級(jí)變量里反復(fù)用。第三個(gè)是代碼格式。Cloudflare 支持 Service Worker syntax 和 ES Modules syntax 兩種寫法ES Modules 格式的優(yōu)化空間更大冷啟動(dòng)通常更好官方未來也會(huì)更側(cè)重這個(gè)方向。我建議新項(xiàng)目從一開始就只用 ES Modules。調(diào)優(yōu)時(shí)可以直接用wrangler tail觀察日志并且在 Cloudflare 面板的 Metrics 頁面查看wall time和CPU time。如果墻鐘時(shí)間遠(yuǎn)大于 CPU 時(shí)間說明你的請(qǐng)求大量時(shí)間花在等待外部調(diào)用上如果 CPU 時(shí)間超了那才是代碼本身重。4.2 狀態(tài)為什么總是丟很多剛接觸 Worker 的人會(huì)踩這個(gè)坑在 Worker 里定義了一個(gè)全局變量發(fā)現(xiàn)下一次請(qǐng)求時(shí)值還在過了一陣子又變成初始狀態(tài)了。這個(gè)現(xiàn)象完全正常。Cloudflare 的運(yùn)行時(shí)并不保證每次請(qǐng)求都復(fù)用同一個(gè)進(jìn)程底層隔離環(huán)境可能被回收、重新創(chuàng)建甚至請(qǐng)求會(huì)被調(diào)度到另外一個(gè)機(jī)房執(zhí)行。想存儲(chǔ)“狀態(tài)”有幾個(gè)不同層級(jí)的方案KV分布式鍵值存儲(chǔ)適合配置、開關(guān)、計(jì)數(shù)器等但最終一致。D1基于 SQLite 的關(guān)系型數(shù)據(jù)庫適合需要 SQL、需要事務(wù)的輕度數(shù)據(jù)。Durable Objects提供單點(diǎn)強(qiáng)一致的有狀態(tài)對(duì)象適合做 WebSocket 狀態(tài)、協(xié)同編輯、分布式鎖。R2對(duì)象存儲(chǔ)適合文件、圖片這類大體積數(shù)據(jù)。我實(shí)際搭建自己的個(gè)人系統(tǒng)時(shí)最常用的是 KV 存配置用 D1 存業(yè)務(wù)數(shù)據(jù)用 Durable Objects 做在線狀態(tài)同步。有一陣子我只用 KV 存所有數(shù)據(jù)結(jié)果在并發(fā)寫入場景下出現(xiàn)了讀到舊值的情況換成 D1 后事務(wù)問題基本解決?？傊畡e把 Worker 的內(nèi)存變量當(dāng)作持久化存儲(chǔ)一定要分清楚“緩存”和“存儲(chǔ)”的邊界。4.3 系統(tǒng)資源限制沒看清坑才剛剛開始Cloudflare 對(duì)單個(gè) Worker 的資源限制是真實(shí)存在且需要認(rèn)真對(duì)待的。不同套餐、不同時(shí)期的具體數(shù)值可能會(huì)變我給一個(gè)基于實(shí)踐的經(jīng)驗(yàn)值供參考免費(fèi)檔單個(gè)請(qǐng)求的 CPU 時(shí)間大約只有 10ms付費(fèi)檔會(huì)高不少單請(qǐng)求處理的總墻鐘時(shí)間上限約 30 秒單請(qǐng)求最多發(fā)起約 50 個(gè)子請(qǐng)求單個(gè) Worker 的代碼包體積控制在 3MB 以下比較穩(wěn)妥。這些數(shù)字最終要以你賬號(hào)內(nèi)面板展示和官方文檔為準(zhǔn)。CPU 時(shí)間限制是最容易被忽略的。很多人只盯著墻鐘時(shí)間發(fā)現(xiàn)自己的接口 500ms 就返回了覺得沒問題結(jié)果還是不斷報(bào) 1102 錯(cuò)誤。原因就是雖然總耗時(shí)不高但 CPU 密集操作占了太多“執(zhí)行時(shí)間”。解決方案通常是把重計(jì)算放到隊(duì)列或 Workflows 里異步執(zhí)行或者干脆把計(jì)算放到客戶端去做。墻鐘時(shí)間的 30 秒上限同樣需要注意。如果一個(gè)請(qǐng)求需要同步等待多個(gè)外部 API 響應(yīng)30 秒很容易被耗盡。遇到這種情況不要試圖在一個(gè)請(qǐng)求里串行處理太多任務(wù)改成異步模式加回調(diào)或者用 Workflows 編排更穩(wěn)妥。4.4 常見問題速查表我把自己踩過和朋友們常問的問題整理成了一個(gè)表格排查的時(shí)候照著看就行癥狀/報(bào)錯(cuò)可能原因解決方案429 Too Many Requests觸發(fā)頻率限制降低請(qǐng)求頻率或升級(jí)套餐提高額度1102 CPU 限流單請(qǐng)求 CPU 時(shí)間超限優(yōu)化循環(huán)、減少大計(jì)算拆成異步任務(wù)1101 JavaScript 異常Worker 代碼運(yùn)行時(shí)拋錯(cuò)查看實(shí)時(shí)日志定位具體報(bào)錯(cuò)行狀態(tài)時(shí)有時(shí)無錯(cuò)誤使用全局變量或 KV改用 D1/Durable Objects 管理持久狀態(tài)冷啟動(dòng)變慢bundle 過大或頂層初始化重移除大依賴懶加載改用 ES Modules自定義域名不生效DNS 記錄或路由未正確綁定檢查 Workers Routes 和 DNS 記錄狀態(tài)KV 讀到舊數(shù)據(jù)KV 最終一致性改用 D1 或在業(yè)務(wù)上接受短暫不一致這個(gè)表格不是完整的官方錯(cuò)誤碼文檔但覆蓋了個(gè)人開發(fā)者在邊緣平臺(tái)起步階段絕大部分會(huì)碰到的問題。真遇到了還沒見過的錯(cuò)第一時(shí)間不是去搜索引擎亂猜而是打開 Workers Logs 看原始報(bào)錯(cuò)日志通常能直接看到堆棧。5. 向“真系統(tǒng)”再走兩步域名、認(rèn)證與可觀測(cè)5.1 把自定義域名掛到“系統(tǒng)”上每個(gè) Worker 默認(rèn)分配的*.workers.dev域名在調(diào)試階段足夠用了但真要放到生產(chǎn)環(huán)境掛一個(gè)自有域名是必須的。Cloudflare 的自定義域名綁定很簡單在 Worker 詳情頁的 Settings 里找到 Domains 和 Routes添加system.example.com這類子域即可。域名解析之后HTTPS 證書是 Cloudflare 自動(dòng)簽發(fā)和續(xù)期的你只需要保證域名本身的 DNS 記錄已經(jīng)托管到 Cloudflare。這一步做完你的“系統(tǒng)”才真正像一個(gè)對(duì)外服務(wù)的產(chǎn)品而不是一個(gè)臨時(shí)實(shí)驗(yàn)項(xiàng)目。我自己的習(xí)慣是給不同的服務(wù)分配不同的子域比如api.example.com走 API Workerblog.example.com走 Pages這樣后續(xù)維護(hù)和灰度發(fā)布都更清晰。5.2 用 Access 給“系統(tǒng)”加一道登錄入口傳統(tǒng)系統(tǒng)里做登錄認(rèn)證要么自己搭一套用戶體系要么引入 OAuth 服務(wù)。Cloudflare 的做法是在網(wǎng)絡(luò)層就把這道門裝上它提供的 Access 產(chǎn)品可以充當(dāng)應(yīng)用入口的認(rèn)證網(wǎng)關(guān)。在 Zero Trust 面板里創(chuàng)建一個(gè) Access Application類型選 Self-hosted填上你的 Worker 域名然后配置訪問策略。比如我可以只允許自己的郵箱登錄或者只允許某個(gè)郵箱域名下的用戶訪問。配置完成后任何人打開這個(gè)域名時(shí)Cloudflare 會(huì)先要求身份驗(yàn)證驗(yàn)證通過后才把請(qǐng)求轉(zhuǎn)發(fā)給 Worker。這條路徑對(duì)個(gè)人開發(fā)者特別有價(jià)值你不需要在自己代碼里維護(hù)登錄態(tài)、Session、密碼哈希只需要專注于業(yè)務(wù)邏輯。如果哪天不想要這個(gè)域名對(duì)外暴露了直接在 Access 策略里把所有訪問都拒絕掉即可不用改一行代碼。5.3 可觀測(cè)性沒有日志和指標(biāo)的系統(tǒng)不值得上線任何操作系統(tǒng)最怕的就是“黑盒”。Cloudflare 提供了幾層可觀測(cè)能力我全部開著。實(shí)時(shí)日志最簡單的方式是npx wrangler tail edge-os-lab終端會(huì)實(shí)時(shí)滾動(dòng)當(dāng)前 Worker 收到的請(qǐng)求和打印的日志。開發(fā)調(diào)試階段用這一個(gè)命令就能解決大多數(shù)問題。但注意tail 只能看實(shí)時(shí)的沒法回溯太久遠(yuǎn)的歷史數(shù)據(jù)所以生產(chǎn)環(huán)境我建議開 Logpush 功能把請(qǐng)求日志推到 R2 存儲(chǔ)里方便事后分析和統(tǒng)計(jì)。指標(biāo)方面Cloudflare 面板的 Metrics 頁面能看到請(qǐng)求數(shù)、錯(cuò)誤率、CPU 時(shí)間、墻鐘時(shí)間這些核心數(shù)據(jù)。我平時(shí)定位性能問題時(shí)的步驟很固定先看調(diào)用量有沒有異常再看錯(cuò)誤率有沒有上升然后對(duì)比 CPU 時(shí)間和墻鐘時(shí)間的比例最后再去翻日志。這套流程幫我快速定位過好幾起由第三方 API 變慢引發(fā)的連鎖問題。如果你打算長期把業(yè)務(wù)跑在邊緣平臺(tái)上千萬別省可觀測(cè)性這一環(huán)。省下的五分鐘配置時(shí)間將來可能在排查事故時(shí)變成好幾個(gè)小時(shí)。最后補(bǔ)一個(gè)我自己的使用體會(huì)cloudflare-os 到底算不算操作系統(tǒng)嚴(yán)格意義上當(dāng)然不算但誰在乎呢我更愿意把它看成一臺(tái)很怪但很好用的“全球共享主機(jī)”內(nèi)存不保你長期占用線程按請(qǐng)求計(jì)費(fèi)磁盤用量按量付費(fèi)進(jìn)程可以隨時(shí)暫?；謴?fù)。你真正學(xué)會(huì)的是放棄控制物理資源的執(zhí)念轉(zhuǎn)而用平臺(tái)的抽象能力拼出自己的業(yè)務(wù)系統(tǒng)。動(dòng)手建一個(gè)最小閉環(huán)跑上一個(gè)月你就能感受到這種模式給人的自由度——它和傳統(tǒng)服務(wù)器是完全不同的兩種樂趣。