10.3 Cloudflare 之外：對比其他邊緣平台與未來展望#

本節目標#

本書停在 Cloudflare 不是因為它是唯一解，而是它能完整演示「邊緣優先」的每一層。真正成熟的工程判斷力，來自知道還有哪些選項與各自的權衡。本節把 Cloudflare 與 Vercel/Netlify、AWS CloudFront+Lambda@Edge、Deno Deploy 放在同一張桌上比較，最後掃描邊緣平台的下一站：Workers AI、R2 Data Catalog 與向量資料庫。

四個平台的哲學差異#

每一個平台的差異，源頭都是哲學架構；認清架構，缺點就顯而易見：

Cloudflare  : 全棧式邊緣雲   — 從 CDN 到資料庫都「住在邊緣」
Vercel      : 前端體驗雲     — 為 Next.js 等框架一級公民而生
Netlify     : Jamstack 先驅  — 花費最簡單的佈設流程
Deno Deploy : TypeScript 原生雲 — 一個執行時，一個設計理念

Cloudflare vs 老錢：Vercel 與 Netlify#

兩者的共同血統是 Jamstack（本書 3.1）：Git push → CI 建置 → CDN 分發。

面向	Cloudflare (Workers/Pages)	Vercel	Netlify
一級公民	網站全棧：Worker/D1/R2/KV	Next.js 生態整合最緊	純前端 + Functions
執行模型	V8 Isolates，冷啟動幾乎零	Edge/Node Functions	AWS Lambda 底層
資料面	D1/KV/R2/Vectorize 在同網路	無自有 DB（接 Supabase 等）	無自有 DB
免費額度	非常寬鬆	個人夠用，團隊偏貴	個人夠用
彈性天花板	高（能扛大量動態）	中（重度互動尚可，但超額收費快）	中低（增量建置易踩額度線）
鎖定程度	中（Web 標準 API 為主，可遷移）	高（Next.js 部署深度耦合）	中

計算一個簡單對比公式：

\[ \text{總成本} = \text{建置時間計費} + \text{動態請求計費} + \text{帶寬計費} + \text{工程整合成本} \]

靜態網站 + 偶爾一個表單 API：三者都勝任，Vercel/Netlify 的「體驗糖」更甜（PR 預覽、框架自動配置），Cloudflare 勝在額度。
動態密集的應用（大量 Worker 運算、DB 查詢）：Cloudflare 的結構優勢顯現——資料與計算就在同一個 PoP，不必回源到 us-east-1。

\[ T_{\text{Cloudflare}} = T_{\text{PoP 運算}} \quad\text{vs}\quad T_{\text{Lambda 回源}} = 2\cdot RTT + T_{\text{Region 運算}} \]

Cloudflare Workers 冷啟動近乎為零的理論基礎在於 V8 Isolate：不 fork 進程、不開執行緒，排程單位是輕量隔離物件，啟動開銷以毫秒計。

對比 AWS：繞不繞得開的巨人#

AWS CloudFront + Lambda@Edge 是「企業級預設」，彈性天花板極高。但有四個真正的差異成本：

部署模型：Lambda@Edge 的修改要經由較繁瑣的發布流程、且各 region 生效有延遲；Cloudflare 是全球瞬間部署——wrangler deploy 寫一次，全網生效。
執行限制：Lambda@Edge 依請求/回應事件有較緊的執行時間限制；Workers 的 CPU time 有上限但無閒置計費。
資料層：AWS 需要自搭一套 ECS/EC2 + RDS/DynamoDB；Cloudflare 自帶 D1/R2/KV 的組合。
帳單複雜度：AWS 帳單是工程問題；Cloudflare 一頁看完。

企業選 AWS 很少是因為它最適合前端，而是既有的組織慣性與 IAM/合規需求——這是治理面的答案，不是技術性能面。誠實的評斷：小團隊與新專案優先 Cloudflare，大型既有組織按現實走。

對比 Deno Deploy：一個執行時的信念#

Deno Deploy 把兩件事做到了極致：

JS/TS 原生：不需要打包流程、不需要 node_modules 的重量，URL imports 直接可跑
Edge 的定義單純：就是 HTTP 處理器（Deno.serve），以 Web 標準 API 為界

這是一堂規模更小的邊緣課——它的優點（極簡、冷啟動極低）與限制（生態比 Cloudflare 小很多：無 D1/R2 對等物、無 WAF/DDoS 全家桶）恰好構成對比教材。實務態度：把定位留在玩具或輕量 side project，不當主陣地。

選型決策表#

如果你的需求是…	頭號選擇	理由
純前端 + 框架（Next.js）糖衣	Vercel	框架一級整合
全棧邊緣應用 + 控管成本	Cloudflare	資料與運算同 PoP，額度寬鬆
Netlify 特有的表單/身份/分流功能	Netlify	功能原生
企業既有 AWS 治理	CloudFront+Lambda	組織慣性

未來展望：三個正在發生的演進#

不光是「每次請求多快」：邊緣平台的下一站是從 CDN 進化為分散式雲的資料庫與計算平台。

Workers AI：模型推論下放到邊緣#

Cloudflare 把開源模型（Llama、Mistral、Embedding、文生圖）跑進全球網路，Worker 中一個 binding 呼叫：

export default {
  async fetch(req, env) {
    const data = await env.AI.run("@cf/meta/llama-3.1-8b-instruct", {
      messages: [{ role: "user", content: "hello" }],
    });
    return Response.json(data);
  },
};

架構上的意義：AI 推論變成 CDN 的一項功能。不必調度一個 GPU 叢集、不必簽供應商合約，部署就是寫一個 binding；代價兩面——可用模型偏中小型，且推論成本仍比自建高於規模化的場景。對多數網站而言，「偶爾跑一次摘要/分類」的情境，邊緣推論剛剛好。

R2 Data Catalog：把物件儲存升級為可查詢的表格#

R2 推出 Data Catalog（建立在 Apache Iceberg 開放表格式之上）：照舊把 Parquet 檔放進 R2，就能經由 catalog 用 SQL 直接查它。這是「物件儲存 → 資料湖倉」一步到位的整合：

-- R2 Data Catalog 的抽象觀念：Iceberg 表格直查
SELECT count(*) FROM events WHERE date = '2026-11-05';

不必架 Spark 叢集、不必另外採購數據倉儲，例行上傳把 datalake/ 寫進 R2 就落成表格。對照傳統方案的定位：Snowflake 把 DB 賣得貴、Databricks 把 Lake 賣得貴，R2 的策略是把儲存與查詢的基礎成本壓到近乎零。

Vector Database：語意檢索入門#

搜尋的下一步不是 keyword match，是意義相近。向量資料庫把文字存成高維向量：

\[ \text{similarity} = \cos(\vec{a}, \vec{b}) = \frac{\vec{a}\cdot\vec{b}}{\lVert\vec{a}\rVert\,\lVert\vec{b}\rVert} \]

典型應用是 RAG（Retrieval-Augmented Generation）：把文件切成 chunk → embedding 進 Vectorize → 使用者問題 embedding 後找 top-k 相似片段 → 餵給 LLM。在 Cloudflare 佈局裡，這全部在一個 Worker 中完成：

環節	Cloudflare 服務
文件儲存	R2
切塊 + Embedding	Workers AI
相似檢索	Vectorize
生成回答	Workers AI (LLM)
業務資料	D1

趨勢總結：一條主線#

回顧本書與本節，邊緣平台的演化只有一條主線：

\[ \text{把所有東西推到離使用者最近的地方}： \text{HTML} \to \text{運算} \to \text{資料} \to \text{AI} \]

每一代技術都重複同一個故事：先出現「離使用者很遠的中心」（mainframe → 主機房 → 雲端），再有人證明廉價而分佈的邊緣可以更好（瀏覽器 → CDN → Jamstack → 邊緣全棧）。接下來幾年的關鍵問題是資料層（資料庫、AI 推論）能否在邊緣無感地落地——Cloudflare 已經開打這場仗，勝負未定。

工程層面的忠告：平台會過時，「把延遲、成本與攻擊面推近使用者」的設計哲學不會。換平台時問同樣的問題：資料在哪運算？冷啟動誰付？鎖定的退場路徑是什麼？

小結與練習#

回顧#

四大平台的定位差異：Cloudflare 是全棧邊緣雲，Vercel/Netlify 是前端體驗雲，Deno Deploy 是純執行時，AWS 是組織慣性的重型選項。
動態密集應用的關鍵是「計算與資料同 PoP」；成本的一半以上不在建置而在架構。
未來三站：Workers AI（推論即功能）、R2 Data Catalog（物件儲存 → 可查詢湖倉）、向量 DB（語意檢索）。
RAG 已能在單一 Worker 內閉環：R2 + Workers AI + Vectorize + D1。
技術選型的判斷力不在背品牌，而在延遲、成本、鎖定的天平。

練習#

三個平台各自用 30 分鐘 deploy 同一個靜態網站，記錄：步驟數、冷啟動延遲、免費額度的耗用速度，寫一份一頁選型筆記。
在你的 Worker 加一個 /ai/summarize 端點，用 Workers AI 對 D1 裡的文章做摘要，量測 P95。
為你的部落格文章建 Vectorize index，實作簡單語意搜尋（類似第 9 章），比較與 LIKE 搜尋的結果差別。
寫 300 字：如果三年後必須從 Cloudflare 遷出，你的退場路徑是什麼？哪些 binding（D1、KV、Vectorize）最耗費遷移？