Cloudflare Workers 邊緣運算完整教學:用 Serverless 打造全球低延遲後端 API
如果你跟我一樣,受夠了每次部署後端 API 都要煩惱伺服器地區、冷啟動延遲、還有那個永遠搞不定的 auto-scaling 設定,那 Cloudflare Workers 可能會讓你眼睛一亮。這東西的概念很簡單:把你的程式碼丟到全球超過 300 個邊緣節點上跑,使用者從哪裡發 request,就從最近的節點回應。聽起來很美好對吧?實際用起來,我覺得確實解決了不少痛點。
什麼是 Cloudflare Workers?
Cloudflare Workers 是建構在 V8 引擎上的 Serverless 運算平台。跟 AWS Lambda 或 Google Cloud Functions 不一樣的地方在於,它不是跑在某個特定區域的資料中心,而是分散在 Cloudflare 的全球邊緣網路。每次請求進來,會由離使用者最近的節點處理,延遲通常可以壓到個位數毫秒。
你可以把它想成:傳統 Serverless 是「選一個機房幫你跑」,Workers 是「全世界的機房同時幫你跑」。這個架構特別適合需要低延遲的 API 服務、A/B 測試分流、或是做全球性的內容個人化。如果你之前有碰過 Bun Runtime 後端開發,你會發現 Workers 的 JavaScript 執行環境有些類似的味道,但多了邊緣部署的天然優勢。
為什麼選擇邊緣運算?
老實說,不是每個專案都需要邊緣運算。如果你的使用者全在台灣,一台放在東京的 VM 就夠了。但如果你在做面向全球的 SaaS、API Gateway、或是任何對延遲敏感的服務,邊緣運算的優勢就很明顯:
- 冷啟動極快:Workers 的啟動時間大約在 0-5ms,對比 Lambda 的數百毫秒到數秒,差距很大
- 全球一致的低延遲:不用自己搞多區域部署,Cloudflare 幫你搞定
- 免費額度慰慨:每天 10 萬次請求免費,對 side project 來說很夠用
- 內建 KV、D1、R2:儲存方案齊全,不用另外接第三方服務
搭配 Docker Multi-Stage Build 的容器化部署經驗,你會發現 Workers 把「部署」這件事簡化到了極致——根本不需要 container。
開發環境建置與 Wrangler 設定
Wrangler 是 Cloudflare Workers 的官方 CLI 工具,所有開發、測試、部署都靠它。先裝起來:
# 安裝 Wrangler CLI
npm install -g wrangler
# 登入你的 Cloudflare 帳號
wrangler login
# 建立新專案
wrangler init my-edge-api
cd my-edge-api
初始化後會產生一個 wrangler.toml 設定檔,這是整個專案的核心設定:
name = "my-edge-api"
main = "src/index.ts"
compatibility_date = "2026-03-01"
[vars]
ENVIRONMENT = "production"
[[kv_namespaces]]
binding = "CACHE_KV"
id = "your-kv-namespace-id"
[[d1_databases]]
binding = "DB"
database_name = "my-edge-db"
database_id = "your-d1-database-id"
這邊要注意 compatibility_date 的設定,它決定了你的 Worker 使用哪個版本的 runtime API。建議設成專案開始的日期,之後要升級再改。
第一支 Worker:Hello World 到路由設計
Workers 的進入點很單純,就是一個 fetch event handler。但真正的專案不可能只有一個 endpoint,所以我們需要做路由。這裡示範一個輕量的路由寫法:
// src/index.ts
export default {
async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
const url = new URL(request.url);
const path = url.pathname;
// 簡易路由
if (path === "/api/health") {
return new Response(JSON.stringify({ status: "ok", region: request.cf?.colo }), {
headers: { "Content-Type": "application/json" }
});
}
if (path.startsWith("/api/users") && request.method === "GET") {
return handleGetUsers(env);
}
if (path.startsWith("/api/cache") && request.method === "GET") {
const key = url.searchParams.get("key");
return handleCacheGet(env, key);
}
return new Response("Not Found", { status: 404 });
}
};
注意 request.cf?.colo 會回傳處理這個請求的邊緣節點代碼(像是 TPE 代表台北、NRT 代表東京),拿來做 debug 很方便。如果你的路由邏輯比較複雜,也可以考慮用 itty-router 這個輕量框架。
KV 儲存實戰:打造快取層
Workers KV 是一個全球分散式的 key-value store,讀取延遲極低,適合拿來做快取。如果你之前研究過 Redis 快取策略,會發現 KV 的思維很類似,但不需要自己管理 Redis 叢集。
async function handleCacheGet(env: Env, key: string | null): Promise<Response> {
if (!key) {
return new Response("Missing key parameter", { status: 400 });
}
// 先查 KV 快取
const cached = await env.CACHE_KV.get(key);
if (cached) {
return new Response(cached, {
headers: {
"Content-Type": "application/json",
"X-Cache": "HIT"
}
});
}
// 快取沒有,從 D1 查
const result = await env.DB.prepare(
"SELECT data FROM items WHERE key = ?"
).bind(key).first();
if (!result) {
return new Response("Not Found", { status: 404 });
}
const data = JSON.stringify(result);
// 寫入 KV 快取,設定 TTL 3600 秒
await env.CACHE_KV.put(key, data, { expirationTtl: 3600 });
return new Response(data, {
headers: {
"Content-Type": "application/json",
"X-Cache": "MISS"
}
});
}
KV 有個特性要注意:它是 eventually consistent 的,寫入後全球同步大約需要 60 秒。如果你的場景需要強一致性,應該改用 Durable Objects。
D1 資料庫整合:SQL on the Edge
D1 是 Cloudflare 自家的 SQLite 邊緣資料庫,目前還在持續進化中,但已經堪用了。建立資料表很直覺:
# 建立 D1 資料庫
wrangler d1 create my-edge-db
# 執行 migration
wrangler d1 execute my-edge-db --command "CREATE TABLE IF NOT EXISTS users (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
email TEXT UNIQUE NOT NULL,
created_at TEXT DEFAULT (datetime('now'))
);"
在 Worker 裡操作 D1:
async function handleGetUsers(env: Env): Promise<Response> {
try {
const { results } = await env.DB.prepare(
"SELECT id, name, email, created_at FROM users ORDER BY created_at DESC LIMIT 50"
).all();
return new Response(JSON.stringify({ users: results }), {
headers: { "Content-Type": "application/json" }
});
} catch (err) {
return new Response(JSON.stringify({ error: "Database query failed" }), {
status: 500,
headers: { "Content-Type": "application/json" }
});
}
}
D1 的查詢語法就是標準 SQL,對有 SQLite 或 PostgreSQL 經驗的開發者來說幾乎零學習成本。
部署上線與效能調校建議
部署到全球只需要一行指令:
# 本地開發測試
wrangler dev
# 部署到全球邊緣網路
wrangler deploy
幾個我實際踩過坑的經驗分享:
- Worker 大小限制:壓縮後 5MB(付費方案),免費版 1MB。不要把整個 ORM 塞進去,保持精簡
- CPU 時間限制:免費版每次請求 10ms,付費版 30 秒。重計算任務不適合放在 Workers
- 善用
ctx.waitUntil():非同步任務(例如寫 log、更新快取)放在這裡,不會阻塞回應 - Custom Domains:可以綁定自己的網域,搭配 Kubernetes Gateway API 做更複雜的流量管理
如果你需要處理的不只是 HTTP API,也可以考慮搭配 Deno 2 後端開發來處理比較重的運算任務,Workers 負責邊緣層的路由和快取。
結語:邊緣運算是後端的未來嗎?
我的看法是:邊緣運算不會取代傳統後端,但它正在成為現代架構中不可或缺的一層。Cloudflare Workers 把邊緣部署的門檻降到了幾乎為零——不用管伺服器、不用設定 CDN、不用煩惱 scaling。對於 API Gateway、快取層、認證中間件這類場景,它幾乎是目前最優的選擇。
如果你正在規劃新的後端架構,我強烈建議把 Workers 納入考量。就算不是整個後端都搬上去,光是拿來做邊緣快取和路由分流,就能讓你的使用者體驗提升一個等級。動手試試看吧,從一個簡單的 wrangler init 開始,你會發現邊緣運算比你想像的容易上手得多。
繼續閱讀
微服務架構入門教學:從單體式到微服務的拆分策略與實戰指南
相關文章
你可能也喜歡
探索其他領域的精選好文