【Cloudflare Workers 全端架構師之路 01】觀念篇：打破雲端的物理限制

01. 前言：Serverless 的第四次革命

在軟體架構的演進史上，我們一直在追求「更小的部署單位」與「更少的維運負擔」：

Bare Metal: 自己買伺服器，自己裝 OS。
Virtual Machines (EC2): 雲端時代，彈性調整硬體資源。
Containers (Docker/K8s): 應用程式標準化，環境一致性。
Serverless (Lambda): 只需關注程式碼，但仍受限於「區域 (Region)」。

現在，我們正處於第四次轉移的風口：Edge Computing (邊緣運算)。 Cloudflare Workers 不僅僅是「另一個 Serverless 選項」，它是架構思維的根本改變。它試圖回答一個問題：「為什麼你的程式碼必須在維吉尼亞州執行，而不是在使用者的家門口？」

02. 打破「區域 (Region)」的物理限制

在 AWS 或 GCP 的世界裡，架構師的第一個決策通常是：「我要選哪個 Region？」選了 us-east-1 (美東)，台灣的使用者延遲就高；選了 ap-northeast-1 (東京)，美國的使用者就慢。你可能需要設定複雜的 Multi-Region 部署與 Route53 路由來解決這個問題。

Cloudflare Workers 是 "Region-less" 的。

當你執行 wrangler deploy，你的程式碼不是被送到某一台伺服器，而是透過 Anycast 技術，同步分發到 Cloudflare 全球 330+ 個城市的資料中心。

傳統架構: 使用者 -> 跨越海底電纜 -> 源站伺服器 (Origin) -> 回傳。
Edge 架構: 使用者 -> 巷口的 ISP 機房 (Worker) -> 回傳。

這不僅降低了延遲 (Latency)，更消除了單點故障 (SPOF) 的風險——因為「整個地球」都是你的伺服器。

03. 深度解析：Isolates vs. Containers

這是資深後端工程師最需要理解的技術差異。為什麼 Cloudflare Workers 敢號稱 0ms 冷啟動 (Cold Start)，而 AWS Lambda 即使經過多年優化，仍深受冷啟動之苦？

這源於底層虛擬化技術的不同：

🔴 傳統 Serverless (AWS Lambda, GCP Cloud Functions)

技術基礎: MicroVMs (如 Firecracker) 或 Containers。
啟動流程: 分配虛擬機 -> 啟動 Linux Kernel -> 啟動 Node.js Runtime -> 載入程式碼 -> 執行。
冷啟動: 視語言與套件大小而定，通常在 200ms ~ 1s 之間。這對即時 API 來說是顯著的延遲。
記憶體開銷: 每個執行個體都需要獨立的 OS 與 Runtime 記憶體。

🟢 Cloudflare Workers (V8 Isolates)

技術基礎: V8 JavaScript Engine (Isolates)。這是 Chrome 瀏覽器用來隔離不同分頁的技術。
啟動流程: 在已運行的 V8 Process 中，建立一個新的 Context (Isolate)。
冷啟動: < 5ms。這在人類感知範圍內等同於「無冷啟動」。
記憶體開銷: 極低。數千個 Isolates 可以共享同一個 V8 Runtime 的底層資源。

架構師筆記: 如果你的應用場景是 「高併發、低延遲 API」 (例如廣告競價、個人化路由、API Gateway)，Isolates 架構具有絕對優勢。

04. 成本模型分析：省錢的藝術

除了效能，成本結構也是一大亮點。

AWS Lambda: 主要依照 「GB-seconds (執行時間 x 記憶體大小)」 計費。如果你的 API 需要等待外部 API 回應 (IO Wait)，你在等待的時間仍需付費（雖然現在 Lambda 有改進，但基本邏輯不變）。
Cloudflare Workers (Standard): 主要依照 「請求數量 (Requests)」 與 「CPU 時間 (CPU Time)」 計費。
- 關鍵差異: Workers 算的是 CPU 活躍時間，而不是掛鐘時間 (Wall-clock time)。如果你的 Worker 發出一個 Fetch 請求並等待 3 秒，這 3 秒的等待時間是免費的。

情境比較：一個 Proxy API (處理請求 -> 呼叫第三方 -> 回傳)

項目	AWS Lambda	Cloudflare Workers
計費基礎	總執行時間 (含等待時間)	僅計算 CPU 運算時間 (不含等待 IO)
IO 密集型任務	較貴 (等待時仍在燒錢)	極省 (等待時間免費)
CPU 密集型任務	較適合 (無硬性 CPU 限制)	不適合 (有嚴格 CPU 時間限制)

05. 生態系總覽：The Supercloud

Workers 只是運算 (Compute)。要構建完整的全端應用，我們需要完整的後端拼圖。這也是本系列文後續章節的重點：

服務名稱	角色	實作重點	對標 AWS 服務
Workers KV	快取/設定	Part 3	Elasticache (Redis), Parameter Store
D1 Database	關聯資料庫	Part 4	RDS, Aurora
R2 Storage	檔案儲存	Part 5	S3 (但在 R2 無出口流量費)
Durable Objects	狀態/一致性	Part 7	無直接對應 (類似 Actor Model)
Queues	非同步佇列	Part 8	SQS
Workers AI	AI 推論	Part 9	Bedrock, SageMaker

06. 誠實的缺點：什麼時候「不該」用？

為了保持客觀，我們必須談談 Workers 的限制。如果你的需求符合以下情況，請留在 AWS/GCP：

重度運算任務：影片轉檔、大數據壓縮。Workers 的 CPU 時間限制（免費版 10ms / 付費版 30s）不允許長時間佔用 CPU。
依賴原生二進位檔 (Native Binaries)：你不能隨意 apt-get install 或執行 Python/Go 的編譯執行檔 (除非編譯成 WebAssembly)。
極度複雜的內網架構：雖然有 Cloudflare Tunnel 和 Service Bindings，但如果你需要傳統 VPC 的那種完全隔離與固定 IP 管控，Workers 的網路模型會讓你很不習慣。

07. 小結：準備好你的 IDE

Cloudflare Workers 透過 V8 Isolates 解決了 Serverless 最大的痛點——冷啟動與成本，並利用全球網路解決了延遲問題。它不再只是一個 CDN 腳本工具，而是一個現代化的全端開發平台。

在下一篇 Part 2: 入門篇 中，我們將正式動手：

安裝 Wrangler 工具鏈。
對比 Hono 與 Express 的開發體驗。
部署你的第一個全球 API，並在 .dev.vars 中管理環境變數。

請準備好你的 VS Code，我們要開始寫 code 了！