Cloud Run functions 三種實作
課程概述
有人打 API、檔案上傳完成、訊息送進 Pub/Sub:這三件事都能觸發一段程式,但程式收到的資料不一樣。這堂課用 Cloud Run functions(原 Cloud 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"] 
事件型函式收到的是 CloudEvent,除了資料本身,還有來源、類型、時間和事件 ID。先確認這是哪種事件,再處理資料;如果同一個 ID 又出現,就要避免把同一件事做第二次。
第一代 vs 第二代
| 特性 | 第一代 | 第二代(建議使用) |
|---|---|---|
| 底層 | Google 內部基礎設施 | Cloud Run |
| 並發 | 1 請求/實例 | 最高 1000 請求/實例 |
| 最長執行 | 9 分鐘 | 60 分鐘(HTTP 觸發)/9 分鐘(以 Cloud Functions v2 API 建立的事件驅動函式) |
| 記憶體上限 | 8 GB | 32 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 查證)。

只有沒有可用暖容量時才需要 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
延伸學習
- 進階:Cloud Run 無伺服器開發
- GenAI 應用:建構 GenAI 應用
讀完後,留一個學習紀錄
試著用自己的話說出一個重點,以及你會如何運用。實作文章請先核對結果與清理資源,再標記為讀完。
文章進度以你確認讀完的標記為準,可隨時取消。舊版造訪紀錄保留,但不計入讀完;這份自評不代表已掌握內容。