跳至主要內容
Study Jam:雲端基礎實作 — 第 6/10 篇

Cloud Run functions 三種實作

內文字級

Cloud Run functions 三種實作
更新:2026-10-12

課程概述

有人打 API、檔案上傳完成、訊息送進 Pub/Sub:這三件事都能觸發一段程式,但程式收到的資料不一樣。這堂課用 Cloud Run functions(原 Cloud Functions)各做一次,看看 HTTP、Cloud Storage 事件和 Pub/Sub 訊息該怎麼接。

Cloud Run functions 三種觸發模式:HTTP 請求經身分驗證後回應、Cloud Storage 物件事件觸發檔案處理、Pub/Sub 訊息經訂閱觸發並在失敗時重試或送往死信路徑

HTTP 函式收到請求後要回應呼叫者;Cloud Storage 事件帶來物件變動資訊;Pub/Sub 則帶來訊息,失敗時還可能重送。三種觸發方式都需要設定權限、逾時與日誌,事件型函式還要處理重複投遞。

你將學到

  • 建立 HTTP 觸發的 Cloud Run function
  • 建立 Cloud Storage 事件觸發的函式
  • 建立 Pub/Sub 訊息觸發的函式
  • 理解 Cloud Run functions (1st gen) 與 Cloud Run functions(原第 1 代與第 2 代)的差異

核心概念

三種觸發模式

1. HTTP 觸發 — 透過 HTTP 請求呼叫

import functions_framework

@functions_framework.http
def hello(request):
    name = request.args.get('name', 'World')
    return f'Hello, {name}!'

2. Cloud Storage 觸發 — 檔案上傳/刪除時執行

import functions_framework

@functions_framework.cloud_event
def process_file(cloud_event):
    data = cloud_event.data
    bucket = data["bucket"]
    name = data["name"]
    print(f"Processing file: gs://{bucket}/{name}")

3. Pub/Sub 觸發 — 收到訊息時執行

import base64

import functions_framework

@functions_framework.cloud_event
def process_message(cloud_event):
    data = base64.b64decode(cloud_event.data["message"]["data"]).decode()
    print(f"Received message: {data}")
查看流程與節點文字

箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 24, "rankSpacing": 32}}}%%
flowchart TD
  SOURCE["定義事件來源、回應契約<br/>與失敗後的處理方式"] --> SYNC{"呼叫端需要<br/>同步取得回應?"}
  SYNC -->|"是"| HTTP["HTTP Trigger<br/>先驗證身分與輸入"]
  SYNC -->|"否"| OBJECT{"事件來自 Cloud Storage<br/>物件新增、更新或刪除?"}
  OBJECT -->|"是"| STORAGE["Storage Event<br/>讀取 CloudEvent metadata 與 data"]
  OBJECT -->|"否"| ASYNC{"需要緩衝流量、重試<br/>或讓多個訂閱者解耦?"}
  ASYNC -->|"是"| PUBSUB["Pub/Sub Event<br/>設計冪等、Retry 與 Dead-letter"]
  ASYNC -->|"否"| REVIEW["重新確認事件來源<br/>或改用 Cloud Run Service/Job"]
先看呼叫者是否等待同步回應,再判斷事件來源與解耦需求。選好觸發模式後,仍要明確設定 Runtime、Entry Point、Service Account、重試與觀測方式。
Cloud Storage 與 Pub/Sub 事件經 Eventarc 路由並封裝成 CloudEvent,Functions Framework 解開 id、source、type、time 等 metadata 與 data 後交給 Handler

事件型函式收到的是 CloudEvent,除了資料本身,還有來源、類型、時間和事件 ID。先確認這是哪種事件,再處理資料;如果同一個 ID 又出現,就要避免把同一件事做第二次。

第一代 vs 第二代

特性第一代第二代(建議使用)
底層Google 內部基礎設施Cloud Run
並發1 請求/實例最高 1000 請求/實例
最長執行9 分鐘60 分鐘(HTTP 觸發)/9 分鐘(以 Cloud Functions v2 API 建立的事件驅動函式)
記憶體上限8 GB32 GB
流量分配不支援支援

表格超出欄寬時,可左右捲動;鍵盤可聚焦表格後用左右方向鍵查看。

記憶體上限這一列:函式配額頁列的函式記憶體上限是第 1 代 8GiB、現行版 32GiB,Cloud Run 的記憶體設定頁也寫最高 32 GiB(要搭配 8 vCPU;4 vCPU 最多 16 GiB)。版本比較頁的 Instance size 則寫現行版「Up to 16 GiB RAM with 4 vCPU」。兩頁官方寫法不同,要用到 16 GiB 以上時,部署前先在主控台確認(2026-10-12 查證)。

第二代 Function 執行個體生命週期:零實例時事件觸發 Cold Start,載入 Runtime 後以 Concurrency 處理請求並重用暖實例,閒置後縮至零;Min Instances 可保留暖容量

只有沒有可用暖容量時才需要 Cold Start;已載入程式的 Warm Instance 可用 Concurrency 同時處理多個請求。Min Instances 用持續成本換低延遲,若允許縮到零則要接受下一波流量可能重新初始化。

實作重點

  • 第二代 Functions 建立在 Cloud Run 上;部署前仍要確認並發、逾時等設定是否符合工作負載
  • 用 gcloud functions deploy 部署時記得指定 --runtime 和 --entry-point;改用官方部署文件的 gcloud run deploy 時,對應的是 --base-image 和 --function
  • 使用 --allow-unauthenticated 才能公開 HTTP 端點
  • 本地測試可用 Functions Framework:functions-framework --target=hello

Skill Badge 指引

Lab 連結:Build Serverless Applications with Cloud Run Functions(原名 Cloud Run Functions: 3 Ways)— 完成此 lab 可獲得 Skill Badge

延伸學習

Study Jam:雲端基礎實作 — 第 6 篇/共 10 篇 查看系列全覽 →

讀完後,留一個學習紀錄

試著用自己的話說出一個重點,以及你會如何運用。實作文章請先核對結果與清理資源,再標記為讀完。

文章進度以你確認讀完的標記為準,可隨時取消。舊版造訪紀錄保留,但不計入讀完;這份自評不代表已掌握內容。

留言討論

文章目錄與系列

徽章解鎖!