Gambaran Menyeluruh Platform Workers
Cloudflare Workers adalah FaaS berasaskan V8 Isolate yang, sehingga April 2026, membolehkan kod yang sama digunakan serta-merta ke lebih 330 PoP di seluruh bandar. Cold start hampir sifar (di bawah 5ms untuk kebanyakan permintaan), tetapi berbeza daripada AWS Lambda yang menggunakan permulaan kontena, penggunaan Isolate membawa had di mana modul asli Node.js dan I/O menyekat jangka panjang tidak serasi secara asasnya. Walaupun nodejs_compat_v2 yang mencapai GA pada separuh kedua 2025 telah meningkatkan keserasian fs/crypto/stream dengan ketara, menulis tanpa memahami "cara Isolate" masih boleh menyebabkan pelanggaran had subruquest (1,000) atau had masa CPU (5 minit untuk pelan berbayar).
Workers benar-benar bersinar apabila logik stateful digabungkan dengan Durable Objects. Durable Object (selepas ini DO) adalah "pelakon (actor) dengan ID unik global, satu-urutan, dan konsistensi kukuh" di mana permintaan untuk DO yang sama sentiasa disirialisasikan. Model ini direka bentuk sebagai "pengganti mutex di edge" — ia membolehkan "had kadar setiap pengguna", "isyarat per bilik mesyuarat", dan "penguntukan inventori per ID transaksi" yang sebelumnya dilaksanakan menggunakan kunci nasihat Redis atau Postgres diselesaikan secara tempatan tanpa merentasi RTT.
Model Transaksi Durable Objects
Storan berterusan DO menyediakan API storan berasaskan SQLite secara dalaman. Selepas SQLite-backed DO dibuka kepada semua pelan pada 2025, sehingga 10GB data berkaitan boleh disimpan setiap DO, dan put/delete berbilang boleh dilaksanakan secara atom dalam panggilan balik transaction(). Penting untuk difahami bahawa DO mengandungi "get masukan" dan "get keluaran". Get masukan menyekat permintaan baharu semasa menunggu penulisan storan semasa pemprosesan permintaan, manakala get keluaran menangguhkan respons fetch sehingga penulisan storan menjadi kekal. Dengan dua lapisan ini, konsistensi tidak akan rosak walaupun kod aplikasi menggunakan async/await dengan bebas.
```typescript export class InventoryDO { state: DurableObjectState; constructor(state: DurableObjectState) { this.state = state; } async fetch(req: Request) { const { sku, qty } = await req.json<{ sku: string; qty: number }>(); return await this.state.storage.transaction(async (tx) => { const current = (await tx.get<number>(sku)) ?? 0; if (current < qty) return new Response("oos", { status: 409 }); await tx.put(sku, current - qty); return new Response(JSON.stringify({ remain: current - qty })); }); } } ```
Kesalahan penggunaan yang biasa apabila menggunakan DO secara berasaskan pelakon adalah reka bentuk "memproses semua penyewa dalam satu DO". Apabila DO menjadi titik panas, PoP menjadi tetap dan mengenakan RTT tinggi kepada pengguna yang jauh secara geografi. Penyelesaian yang betul adalah menggunakan idFromName() untuk menyambungkan "ID penyewa + ID sumber" untuk pembahagian, supaya penulisan mempunyai lokaliti geografi. Pembacaan boleh dikembalikan secara O(1) daripada replika asinkron menggunakan replika DO (GA pada 2025).
Penggunaan Workers KV, Hyperdrive, dan D1
Ketiga-tiga lapisan data mempunyai tujuan yang jelas. Workers KV adalah storan yang dioptimumkan untuk pembacaan dengan konsistensi akhir, sesuai untuk nilai konfigurasi dan metadata yang boleh menerima perambatan dalam masa 60 saat. Kelewatan perambatan PUT adalah beberapa saat hingga 60 saat, manakala pembacaan dikembalikan dalam 1ms daripada cache tempatan PoP. Hyperdrive adalah penyatuan sambungan ke Postgres/MySQL luaran yang menggunakan semula sambungan TCP ke asal sambil menyimpan cache hasil pertanyaan di PoP. Ini adalah langkah pertama yang paling praktikal bagi organisasi yang mempunyai aset RDB sedia ada yang ingin berpindah ke edge. D1 adalah RDB berasaskan SQLite milik Cloudflare sendiri, di mana replika baca mencapai GA pada 2025 membolehkan topologi gaya PostgreSQL di mana penulisan ke primer dan pembacaan daripada replika terdekat.
Kriteria pemilihan dipecahkan berdasarkan "frekuensi penulisan" dan "keperluan konsistensi". Lebih 1,000 penulisan sesaat boleh diasingkan mengikut penyewa: DO. Penulisan global sedikit + pembacaan teragih secara geografi: D1. Pangkalan data luaran sudah ada: Hyperdrive. Pengedaran konfigurasi berasaskan TTL: KV. R2 (storan objek serasi S3) adalah ortogon kepada ini semua, digunakan untuk penghantaran video, sandaran, dan tasik data memanfaatkan sifat egress percuma.
Workers AI dan Penghalaan Inferens
Sejak Workers AI mencapai GA pada 2024, model OSS utama seperti Llama 3.3 70B, Mistral Large 2, GPT-OSS-120B, dan siri Qwen 3 boleh dipanggil menggunakan pengiraan berdasarkan penggunaan. Pada 2026, keupayaan untuk menghalakan OpenAI/Anthropic/Google melalui API yang sama (AI Gateway) menggunakan BYOK, dengan cache respons, cuba semula, dan had kadar yang diuruskan secara bersatu di bahagian Workers, menjadi kelebihan. Log AI Gateway mengalir ke Analytics Engine, membolehkan kos token setiap gesaan (prompt) ditanya menggunakan SQL.
Amalan terbaik pengoptimuman latensi adalah hibrid "inferens tempatan Workers AI untuk keputusan kecil, LLM luaran untuk inferens kompleks". Sebagai contoh, pengesanan bot, pengelasan NSFW, dan pengesanan berbilang bahasa diselesaikan menggunakan Llama Guard/Llama-3 8B Workers AI, dan hanya apabila hasilnya "tidak pasti" dinaikkan taraf ke Claude atau GPT. KGA telah mengesahkan beberapa kes di mana penghalaan dua peringkat ini berjaya mengurangkan kos sebanyak 70%.
Pengoptimuman Laluan Panas dengan Binding Rust + WASM
TypeScript: 5ms, Rust + WASM: 0.8ms. Perbezaan ini menjadi penting pada 100,000 permintaan sesaat dan memberi kesan langsung kepada bajet masa CPU. workers-rs (Rust crate) boleh dikompil ke runtime Workers menggunakan makro #[event(fetch)], dengan akses kepada API JS (fetch/crypto/R2) melalui wasm-bindgen. Penulisan semula penghurai JSON yang berat, pengesahan HMAC, pengesahan JWT, dan pengubahan saiz imej dalam Rust menghasilkan kesan penjimatan kos yang besar.
```rust use worker::*; #[event(fetch)] async fn main(req: Request, env: Env, _ctx: Context) -> Result<Response> { let body: serde_json::Value = req.json().await?; let signature = req.headers().get("x-signature")?.unwrap_or_default(); if !verify_hmac(&body, &signature, &env.secret("HMAC_KEY")?.to_string()) { return Response::error("invalid signature", 401); } Response::ok("ok") } ```
Sebagai amaran, saiz modul WASM perlu dihadkan kepada di bawah 10MB, dan saiz efektif boleh dikurangkan separuh menggunakan gabungan wasm-opt -Oz dan wee_alloc. Kos permulaan boleh diabaikan hampir sepenuhnya melalui penggunaan semula Isolate, tetapi kompilasi pertama mengambil masa 20 hingga 50ms, jadi di PoP dengan trafik yang sangat rendah, fenomena terbalik di mana TypeScript lebih pantas boleh berlaku. Penanda aras mesti diambil di PoP pengeluaran sebenar.
Corak Pembinaan Mesin Keadaan Global
Gabungan WebSocket Hibernation + Durable Objects telah menjadi standard untuk penyuntingan kolaboratif masa nyata, isyarat penstriman langsung, dan orkestra peranti IoT. API Hibernation membolehkan sambungan WebSocket kekal terbuka sambil membebaskan memori, dan bil DO hanya untuk "masa aktif". Struktur kos di mana 1 juta sambungan boleh dikekalkan dengan kos beberapa ribu dolar sebulan telah mendorong motivasi untuk membina semula perkhidmatan gaya Ably atau Pusher sendiri.
Kunci reka bentuk adalah untuk merawat DO sebagai "nod tunggal mesin keadaan". Peralihan keadaan menggunakan kemas kini CAS versi keadaan dalam storage.transaction, dan peristiwa luaran dinyalakan melalui Queues. Transaksi pampasan untuk kegagalan boleh dilaksanakan menggunakan pelaksanaan tertunda melalui API alarm(). Ini membolehkan corak saga yang "bermula di edge dan berakhir di edge" disusun dengan latensi rendah. Seni bina yang tidak kembali ke asal adalah arena utama reka bentuk sistem teragih 2026.