標籤: Cloudflare Workers

📌 本文重點

• Cloudflare 邊緣現支援原生入站 TCP/gRPC
• 可在邊緣直接跑 gRPC 推理、RAG 與微服務
• 相較 K8s，全球互動式 AI 延遲與成本更優
• 可作為既有 gRPC/K8s 架構的前置 Edge layer

Cloudflare 開放 Workers/Containers 入站 TCP + gRPC，直接解掉幾個很實際的痛點：AI 推理只能走 HTTP/JSON、無法沿用現有 gRPC 微服務、邊緣節點難以做長連線與串流推理。現在你可以在 Cloudflare 邊緣跑 原生 gRPC 推理服務、RAG 檢索節點與微服務 Mesh，延遲更低、成本更像 CDN，而不是像傳統 K8s 叢集那樣重。

重點說明

1. 邊緣執行模型：Workers vs Containers

Cloudflare 現在有兩種主要邊緣運行模式：

• Workers：類似 serverless JavaScript/TypeScript 執行環境
• 適合：輕量 API 轉接、認證、路由、簡單推理管線
• 過去：只支援 HTTP/S，你必須把 gRPC 轉成 HTTP JSON，再打到後端

• 現在：支援 入站 TCP/gRPC，可直接在邊緣 terminate gRPC

• Containers（Cloudflare Workers AI / Cloudflare Containers）：執行打包好的映像

• 適合：完整推理服務、向量檢索、Python/Go gRPC server
• 行為更接近傳統 Pod，但由 Cloudflare 在全球 PoP 管理

這次更新的核心是：兩者都能收 TCP/gRPC 流量，你可以在邊緣直接跑 grpc-go 或 grpc-python 的 server，不必再把邊緣當純 HTTP 反向代理。

💡 關鍵： Workers 與 Containers 現在都能直接處理入站 TCP/gRPC，等於在 Cloudflare 邊緣即可部署完整 gRPC 微服務與 AI 推理節點。

2. 入站 TCP/gRPC 開放後能做什麼？

從開發者視角，幾個立刻有用的場景：

• AI 推理服務在邊緣：
• 在每個區域部署輕量 gRPC 推理節點，靠 Anycast + 邊緣路由 讓使用者打到最近 PoP

• 使用串流 gRPC (Server streaming) 傳回 token，體感延遲大幅下降

• RAG 檢索節點：

• 在邊緣跑向量查詢服務（Faiss/pgvector/自家引擎），gRPC 介面

• 利用 Cloudflare 的 colo 分布，把索引按地理或租戶分片

• 沿用既有 gRPC 微服務：

• 以前你要在前面加 API Gateway/Ingress，把 gRPC 轉 HTTP 或 terminate TLS
• 現在可以在邊緣直接 terminate gRPC，後面用 TCP/gRPC 轉發到 origin 或在邊緣直接處理

實際好處：

• 延遲：請求在使用者附近的 PoP 就完成認證、路由，甚至整個推理
• 成本模型：按使用計費、無需維護多個 K8s cluster，只維護映像與 Workers code
• 協議相容性：不用再為「Cloudflare 只懂 HTTP」寫一層轉換邏輯

💡 關鍵： 對互動式 AI 與全球用戶服務，邊緣 gRPC 推理能在不改協議的前提下顯著降低體感延遲與基礎設施維運成本。

3. 與 Kubernetes + Ingress 的比較

假設你現在有一套標準架構：Cloud LB → Ingress (Envoy/NGINX) → gRPC microservices / AI inference pods。

用 Cloudflare 邊緣替代部分角色時，可以這樣看：

• 延遲：
• K8s：流量通常集中在幾個 region（us-east, ap-southeast），跨區通訊不可避免

• Cloudflare：請求先到最近 PoP，如果推理在邊緣完成，RTT 直接以「使用者到 PoP」為主

• 成本：

• K8s：你要付 cluster 固定成本（control plane + node），再加 LB、egress 等

• Cloudflare：付 Workers/Containers 執行 + 帶寬，沒有 cluster idle 成本，對 burst 型推理更友善

• 可觀測性：

• K8s：你掌握 Pod metric、sidecar tracing，能非常細緻
• Cloudflare：以 request-level logs/metrics 為主，容器內的應用層 metric 要自己上報（例如推到 Prometheus/Grafana Cloud）

結論：

• 對 全球服務、互動式 AI（chat、copilot），邊緣方案延遲優勢很明顯
• 對 重度內網 microservices mesh，K8s 還是比較好管理細粒度通訊與觀測

💡 關鍵： 邊緣 gRPC 更適合面向外部用戶的全球互動式 AI；內部複雜微服務 Mesh 則仍以 K8s 為主，再用 Cloudflare 當前置入口。

實作範例

以下用簡化的範例示意：在 Cloudflare 邊緣部署一個 gRPC AI 推理 API，前面 Workers 做零信任與路由，後面 Container 跑真正的 gRPC server。

1. Terraform：宣告 TCP/gRPC 入口與 Workers Route

# cloudflare.tf
provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

resource "cloudflare_account" "this" {
  name = "my-ai-edge-account"
}

# 建立域名與 gRPC 入口
resource "cloudflare_zone" "ai_api" {
  name = "ai.example.com"
}

# 開啟 gRPC（HTTP/2 + TCP）入口
resource "cloudflare_worker_route" "grpc_route" {
  zone_id     = cloudflare_zone.ai_api.id
  pattern     = "ai.example.com/*"
  script      = cloudflare_worker_script.grpc_edge.name
}

resource "cloudflare_worker_script" "grpc_edge" {
  name    = "grpc-edge-worker"
  content = file("./dist/grpc-edge-worker.js")
}

這裡的關鍵是 route 指到 Workers script，Cloudflare 會依協議分流；當客戶端用 gRPC over TLS 打 ai.example.com，會由對應的 PoP 進入 Worker。

2. Workers：在邊緣處理 TCP/gRPC 連線與零信任

Cloudflare 新增了類似 TCP sockets API 的能力（以下為概念化程式碼，實際 API 名稱以官方為準）：

// grpc-edge-worker.js
export default {
  async fetch(request, env, ctx) {
    // HTTP 入口：可用來做健康檢查、簡單 REST 包裝
    return new Response("OK", { status: 200 });
  },

  async tcp(conn, env, ctx) {
    // conn: 表示入站 TCP 連線（含 TLS 已由 Cloudflare terminate）

    // 1. 零信任：檢查 mTLS 或 JWT（假設從 Cloudflare Access 傳入 header）
    const identity = await verifyZeroTrust(conn, env);
    if (!identity.valid) {
      await conn.close();
      return;
    }

    // 2. 將 TCP 流量轉發到邊緣 Container 中的 gRPC server
    const backendConn = await env.AI_GRPC_ORIGIN.connect({
      host: "ai-grpc.internal", // 邊緣 Container 的內部 host
      port: 50051,
    });

    // 3. 做簡單的連線鏡射（pipe）
    conn.pipeTo(backendConn.writable, { preventClose: false });
    backendConn.readable.pipeTo(conn.writable, { preventClose: false });
  },
};

async function verifyZeroTrust(conn, env) {
  // 範例：檢查 Cloudflare Access JWT 或 mTLS client cert
  // 回傳 { valid: true/false }
  return { valid: true };
}

重點：

• tcp(conn, env, ctx) 代表邊緣上對入站 TCP 的 handler
• 你可以在這裡做 零信任驗證、租戶路由、限流，再把流量交給後面的 gRPC server
• 後面的 server 可以跑在 Cloudflare Containers，也可以指到你自己的 origin（例如 GCP/K8s）

3. Container：gRPC AI 推理服務

假設你在 Cloudflare Container 裡跑一個簡化的 Python gRPC server：

# inference_server.py
import grpc
from concurrent import futures
from proto import inference_pb2, inference_pb2_grpc

class InferenceServicer(inference_pb2_grpc.InferenceServiceServicer):
    def StreamChat(self, request, context):
        # request.prompt, request.user_id
        for token in run_llm_stream(request.prompt):
            yield inference_pb2.ChatToken(token=token)

    def Embed(self, request, context):
        vec = embed_text(request.text)
        return inference_pb2.Embedding(vector=vec)

def serve():
    server = grpc.server(futures.ThreadPoolExecutor(max_workers=8))
    inference_pb2_grpc.add_InferenceServiceServicer_to_server(
        InferenceServicer(), server
    )
    server.add_insecure_port("[::]:50051")
    server.start()
    server.wait_for_termination()

if __name__ == "__main__":
    serve()

你只需要把這個映像部署在 Cloudflare Containers，並與前面的 Worker 透過內部 TCP 相接。

建議與注意事項

1. TLS / 零信任設計

• 對外：讓 Cloudflare 統一做 TLS 終結（TLS termination），使用 Cloudflare Access/ZT 控制身份
• 對內：邊緣 Worker 與 Container/Origin 之間建議使用 mTLS，防止橫向移動
• 若你已有 API Gateway（Kong/Envoy），可把 Cloudflare 當 前置 Edge layer，只保留 Gateway 在核心 region 接收來自邊緣的 gRPC

2. 連線壽命與狀態管理

• gRPC streaming 本質是長連線，要注意：
• Worker 執行時間限制：確保 Cloudflare 的執行模型允許長時間 pipe，必要時把邏輯放到 Container

• 斷線重試：在客戶端設計 token-based resume（例如 cursor 或 offset），避免整個對話因 PoP 切換中斷

• 状態建議：

• 把 對話狀態 / session 放在外部儲存（KV、Durable Objects、Redis），不要綁在單一 PoP

3. Origin 的擴展策略

• 若推理服務仍在自家 K8s：
• 用 Cloudflare 邊緣做 全局入口與零信任，後面依租戶或地域分流到不同 cluster

• 注意 跨 region 帶寬成本：邊緣到 origin 的流量可能集中在幾個 region

• 若全面搬到 Cloudflare Containers：

• 建議 按地區部署多個副本，配合 Workers 做地理路由
• 用外部 observability stack（例如 OpenTelemetry + Tempo/Loki）把邊緣 metric 拉回統一平台

4. 常見坑與避雷

• 連線數上限：
• 高併發 gRPC streaming 會吃 connection slot，要確認 Cloudflare 帳號/方案的限制

• 建議在 Workers 做 client-side throttling 或 queue，避免瞬間打爆 Container

• 冷啟動：

• Workers 冷啟動通常比 Lambda 類服務快，但 Container 啟動仍有延遲

• 對延遲敏感的推理 API：

  • 預熱核心路由（例如每 PoP 保留最常用模型的 warm instance）
  • 使用簡單的 health probe 定期打模型，維持容器活躍

• 與現有 API Gateway 串接：

• 遷移策略：先把 外部客戶端改打 Cloudflare 邊緣 gRPC 入口，由 Workers 轉發到原 API Gateway
• 等確定運作穩定，再逐步把認證、限流移到邊緣

5. 一個可落地的「邊緣 AI API」樣板

總結一個可直接採用的樣板架構：

1. Domain & TLS：ai.example.com 由 Cloudflare 管理，開啟 TLS、gRPC 支援
2. Edge Worker：
3. 實作 tcp() handler
4. 做零信任／租戶識別／流量路由（ex: enterprise vs free）
5. Edge Containers：
6. 多區部署 AI 推理 gRPC server + RAG 檢索
7. 共享外部向量庫或依地區分片
8. Observability：
9. 邊緣 logs/metrics 推到集中式平台
10. gRPC tracing 使用 OpenTelemetry，將 trace context 從 Worker 轉接到 Container
11. 漸進式遷移：
12. 先讓 5–10% 流量經邊緣 gRPC 入口，觀察延遲與錯誤率
13. 穩定後再逐步將 region LB 退場，讓 Cloudflare 成為主要入口

關鍵結論：

如果你的 AI 產品面向全球使用者、有既有 gRPC 微服務、又不想維護多套 K8s 邊緣集群，Cloudflare 邊緣 入站 TCP/gRPC 是一個能在短期內帶來 延遲優化 + 架構簡化 的實際選項，值得在下一版推理網路設計中優先評估。

🚀 你現在可以做的事

• 到 Cloudflare Docs 搜尋「Workers TCP gRPC」了解最新 API 與限制
• 把現有一個 gRPC 推理服務包成 Container，嘗試部署到 Cloudflare Containers 並透過 Worker 轉發
• 在現有架構前加一個試驗性 ai-edge.example.com 網域，先導入 5–10% gRPC 流量觀察延遲與穩定性