Cloud Functions 事件驅動開發

Cloud Functions 簡介

Cloud Functions 是 Google Cloud 的代管 Function-as-a-Service (FaaS) 產品。你只要上傳一個用支援執行環境寫好的函式，Google Cloud 就會處理建置、容器封裝、擴展、TLS 終止與流量路由。計費依照呼叫次數、GB-second 記憶體用量與 GHz-second CPU 用量；閒置時零成本。在 PCD 考試裡，Cloud Functions 與 Cloud Run、App Engine 並列在無伺服器運算三角中，但程式模型刻意設計得更窄：一個原始碼目錄、一個進入點、一個 HTTP 或 CloudEvent 處理函式。

Cloud Functions 有兩個世代，名字相同但實作差距巨大。Cloud Functions 第 1 代跑在 Functions 團隊直接維護的舊架構上，受限於 540 秒逾時與每個 instance 一個並行請求。Cloud Functions 第 2 代在底層其實是一個 Cloud Run 服務，由 buildpack 自動封裝並由 Eventarc 餵入非 HTTP 事件。也就是說 CF2 繼承了 Cloud Run 的擴展模型、網路、IAM 與 revision 機制。考試裡碰到「長時間執行的 HTTP handler」、「請求並行」或「Eventarc 過濾條件」這類場景，正解幾乎都是第 2 代。

第 1 代 vs 第 2 代：架構差異

選對世代是 PCD 考試裡最常見的 Cloud Functions 判斷題。兩個世代都用 gcloud functions deploy 部署，但底層產生的資源完全不同。

底層平台

第 1 代是由舊版 FaaS control plane 管理的不透明「Cloud Function」資源。你看不到底層容器、無法調整並行、也無法在 revision 間做流量分流。第 2 代部署後會建立一個 Cloud Run 服務，外加一個 Eventarc trigger（針對事件驅動函式）。執行 gcloud functions deploy --gen2 後，到 Cloud Run console 就能看到對應服務、revision 與流量分流。同一個函式會同時出現在 gcloud functions list 與 gcloud run services list。

配額與限制

怎麼選世代

第 2 代是任何新工作負載的預設建議。會繼續選第 1 代的合理理由只剩兩個：(a) 你相依於某些第 1 代專屬事件來源，例如 Firebase Realtime Database 直接觸發；(b) 你在擴充既有第 1 代程式碼，搬遷成本不划算。其他情況——更高並行、更長 HTTP 逾時、更多記憶體、流量分流、更豐富的事件過濾——第 2 代都贏。

HTTP vs 事件驅動函式

Cloud Functions 有兩種基本觸發風格，選擇會改變函式 signature、IAM 模型與重試語意。

HTTP 函式

HTTP 函式提供一個 HTTPS endpoint：第 1 代在 *.cloudfunctions.net，第 2 代透過 Cloud Run 在 *.run.app。可接受任何 HTTP method，解析請求、回傳 response，依請求時長計費。第 2 代的 HTTP 函式支援 --allow-unauthenticated 開放公開存取，或透過 Cloud Run IAM (roles/run.invoker) 控管。Node.js 的 signature 是 (req, res) => {...}；Python 則是 Flask 風格的 def handler(request): ...。

事件驅動函式與 CloudEvents v1.0

事件驅動函式吃結構化事件。第 1 代收的是 Google 私有舊版 payload。第 2 代每個事件驅動函式都收到 CloudEvents v1.0 envelope，這是 CNCF 標準化的事件格式，必含 id、source、specversion、type 與型別化的 data payload。你的 handler signature 在 Node.js 變成 (cloudEvent) => {...}，Python 則是 @functions_framework.cloud_event。同一個 handler 可以對應 Pub/Sub、GCS、Firestore 或任何 Eventarc 來源，只要透過 cloudEvent.type 分流。

第 2 代的 Eventarc 整合

Eventarc 是支撐第 2 代 Cloud Functions 所有非 HTTP 觸發器的通用事件路由器。理解 Eventarc 模型對 PCD 考試是必要的，因為同樣模式也會在 Cloud Run 與 Workflows 題目裡出現。

Eventarc 如何嵌入

當你執行 gcloud functions deploy my-fn --gen2 --trigger-event-filters="type=google.cloud.storage.object.v1.finalized" --trigger-event-filters="bucket=my-bucket"，Google Cloud 其實會建立三個資源：一個 Cloud Run 服務、一個 Eventarc trigger，以及（GCS 場景下）一個 Pub/Sub subscription 作為 Eventarc 的傳輸管道。trigger filter 把供應端事件轉成 CloudEvents 並 POST 到 Cloud Run URL。

觸發器過濾類型

Eventarc filter 接受精確匹配屬性，例如 bucket=my-bucket、methodName=storage.objects.delete、serviceName=storage.googleapis.com。多個 --trigger-event-filters flag 用 AND 邏輯組合。另外還有 --trigger-event-filters-path-pattern flag 做路徑樣式比對，例如過濾 Cloud Audit Logs 的 resourceName=projects/_/buckets/my-bucket/objects/*。當題目說「只在特定 prefix 內物件被刪除時觸發」時，答案就是這個 path pattern。

直接來源 vs Audit Log 來源

Eventarc 有兩種 trigger。直接來源（GCS、Firestore、Pub/Sub、Firebase Alerts、Cloud IoT）以最低延遲遞送原生型別化事件。Audit Log 來源則把任何 Cloud Audit Logs 條目轉成 CloudEvent，讓你可以對「任何」Google Cloud API 呼叫觸發函式——BigQuery job 完成、IAM 政策變更、Compute Engine VM 建立——前提是 Data Access 或 Admin Activity log 已啟用。Audit Log trigger 延遲較高（10-60 秒）但涵蓋面非常廣。

觸發器來源深入解析

每個觸發來源有自己的遞送保證、延遲特性與 IAM 需求。考試通常會挑這四個高頻來源。

Pub/Sub 觸發器

Pub/Sub 是非同步觸發的主力。第 1 代用 --trigger-topic=my-topic，第 2 代用 --trigger-event-filters="type=google.cloud.pubsub.topic.v1.messagePublished" --trigger-topic=my-topic，會建立一個推送到你函式的 subscription。遞送是至少一次 (at-least-once)，所以 handler 必須是冪等的。第 2 代裡 Pub/Sub 訊息以 base64 編碼後放在 CloudEvent envelope 的 data 欄位。回傳 2xx 即隱含 ack；非 2xx 或 throw exception 會讓 Pub/Sub 在 subscription 的 ack deadline 過後重送。

Cloud Storage 觸發器

GCS trigger 在物件層級事件觸發：google.cloud.storage.object.v1.finalized（新物件或覆寫物件變成 durable）、deleted、archived、metadataUpdated。第 1 代用舊事件型別如 google.storage.object.finalize。CloudEvent 的 data 欄位帶 GCS 物件中繼資料：bucket、name、size、contentType、generation、metageneration。常見考題場景是「處理每個上傳的圖片」——答案是依 bucket 過濾的 finalize trigger，函式內透過 Cloud Storage client library 讀取物件（千萬別期望 event payload 內含位元組；event 只給中繼資料）。

Firestore 觸發器

Firestore trigger 在文件寫入時觸發（created、updated、deleted，或 written 匹配任何變更）。CloudEvent payload 包含文件路徑、舊值與新值。這些 trigger 只對 Native mode 的 Firestore 有效；Datastore mode 不會發 Firestore event。常用於 fan-out 模式：當使用者文件變更時，函式同步反正規化到其他 collection 或讓快取失效。

Cloud Audit Logs 觸發器

如前述，Audit Log trigger 把 API 行為轉成事件。CloudEvent 的 data 欄位是完整的 LogEntry proto，含 protoPayload、resource、severity、principalEmail。用於合規自動化：服務帳戶 key 一被建立就撤銷、BigQuery dataset IAM 變更時告警、VM 建立時自動標籤。

並行：第 2 代的決定性差異

並行是第 2 代 Cloud Functions 最大的效能與成本槓桿，而第 1 代根本沒這個東西。

並行的意義

第 1 代每個 function instance 一次只處理一個請求。如果同時來 100 個請求，平台會起 100 個 instance，你付 100 個 instance-second。第 2 代透過 --concurrency=N 把並行從 1 設到 1000。設 --concurrency=80（Cloud Run 預設，但不是 CF2 預設），單個 instance 可以同時處理 80 個請求，I/O 密集型工作的 instance 數與帳單可以降到 1/80。

預設值為 1 的陷阱

關鍵是 Cloud Functions 第 2 代預設 --concurrency=1，模擬第 1 代行為讓搬遷無痛。你必須主動調高。考試常出現「為什麼我 CF2 成本跟第 1 代一樣？」的場景；答案就是沒設並行旗標。

何時該調高並行

I/O 密集型工作就調高：呼叫外部 HTTP、查資料庫、等 Pub/Sub。CPU 密集型工作（影像處理、影音轉檔、ML 推論）就維持在 1，否則並行請求會搶 CPU 互相拖死。如果你在沒有鎖的情況下改全域記憶體狀態，也要維持在 1，否則並行呼叫會 race。

擴展控制：min-instances 與 max-instances

擴展控制讓你在成本、延遲與失控呼叫的爆炸半徑之間做取捨。

--max-instances

--max-instances 限制同時 instance 數量上限。第 2 代預設 1000（第 1 代 3000）。設 --max-instances=10 在你的函式呼叫下游容量受限的系統時很關鍵——沒分片的 Cloud SQL、有 rate limit 的第三方 API、舊式地端服務。沒設上限的話，流量突波會把下游打爆或拉出一張驚喜帳單。達到上限後，HTTP 額外請求會被短暫排隊然後收 429 Too Many Requests，事件驅動則繼續排在 Pub/Sub 佇列。

--min-instances 與冷啟動

--min-instances=N 持續維持 N 個熱 instance，消除前 N 個並行請求的冷啟動延遲。閒置 instance 會以折扣價計費（約活躍價的 10%）。這是延遲敏感 HTTP endpoint 的解，特別是 Java 或 .NET 函式冷啟動可能超過 5 秒。Pub/Sub 批次工作偶爾延遲沒差的話，min-instances 維持 0 即可。

min-instances 之外的冷啟動緩解

冷啟動還可以靠 (a) 選輕量執行環境（Go 與 Node.js 最快，Java 與 .NET 最慢）、(b) 在 module scope 初始化重物件如資料庫連線池讓它跨呼叫共用、(c) CF2 專屬的 --cpu-boost 在啟動時給更多 CPU。

支援的執行環境與 Buildpack 模型

Cloud Functions 支援精選的語言 runtime，每個有自己的棄用時程。

執行環境清單

目前平台支援 Node.js (18、20、22)、Python (3.10、3.11、3.12、3.13)、Go (1.21、1.22、1.23)、Java (11、17、21)、Ruby (3.0、3.2、3.3)、PHP (8.1、8.2、8.3)、.NET (6、8)。每個 runtime 的棄用日期大致對齊上游社群支援週期；棄用 runtime 仍能執行，但 EOL 日後不能再新部署。

底層的 Buildpack

兩個世代都用 Google Cloud Buildpacks 把你的原始碼目錄轉成 OCI 容器。你提供原始碼與 manifest 檔（package.json、requirements.txt、go.mod、pom.xml 等）；buildpack 偵測 runtime、安裝相依、注入 Functions Framework 把進入點接上 HTTP server 或 CloudEvents listener。第 2 代產生的容器就是 Cloud Run 跑的那個 image，你可以用 gcloud artifacts docker images list 拉下來，甚至直接部署到 Cloud Run 繞過 Functions 抽象。

自訂相依與原生二進制

每個 runtime 都有標準拉相依的方式（npm、pip、Go modules、Maven）。原生二進制或系統套件方面，第 1 代很受限——你幾乎沒控制權。第 2 代因為產出 Cloud Run 容器，彈性大得多，包括 --source 指到 Dockerfile 路徑或用 Cloud Build 客製。

密鑰管理：--set-secrets vs Secret Manager IAM

把密鑰寫死在程式碼或環境變數裡是考試經典陷阱。Cloud Functions 對 Secret Manager 有第一級整合。

部署時掛載密鑰

建議模式是 --set-secrets="DB_PASSWORD=projects/PROJECT/secrets/db-password:latest"。冷啟動時，平台抓密鑰值並把它當成 DB_PASSWORD 環境變數暴露給函式。:latest 別名抓現行版本；也可以 pin 特定版本如 :3 以利回滾。用 --set-secrets="/app/secrets/key=projects/PROJECT/secrets/api-key:latest" 改以檔案形式掛載密鑰，這對多行或二進制密鑰（如 PEM key）較佳。

IAM 不可省略

函式的 runtime 服務帳戶——預設是 [email protected]，或用 --service-account 指定自訂帳戶——必須在每個被引用的密鑰上持有 roles/secretmanager.secretAccessor。沒設好的話部署會成功，但函式第一次冷啟動時權限錯誤才會浮上來。

輪替模式

Secret Manager 輪替是單向的：輪替建立新版本，但已啟動的熱 instance 還是繼續讀已注入環境變數的舊值。要及時撿到輪替，要嘛在輪替時重新部署（用 Pub/Sub 觸發的 Cloud Build），要嘛在函式內用 Secret Manager client library 動態抓取，付一點每次呼叫的成本。

VPC Egress：Connector 與 Direct VPC

Cloud Functions 預設跑在 Google 代管網路，完整公網 egress 但對你的 VPC 零存取。許多真實工作負載需要存取私有資源——私有 IP 的 Cloud SQL、透過 Cloud VPN 的地端服務、內部 load balancer——這就要設定 VPC egress。

Serverless VPC Access Connector

舊路徑是 Serverless VPC Access Connector，這是一個由 f1-micro 級 instance 池組成的代管資源，在一個 /28 subnet 內代理流量進你的 VPC。用 gcloud compute networks vpc-access connectors create 建立一次，然後用 --vpc-connector=my-connector 掛到函式上，egress scope 用 --egress-settings=private-ranges-only（只走 RFC1918）或 --egress-settings=all-traffic（全部 egress 走 VPC，用於 NAT 控制 outbound IP）。Connector 不論函式是否被呼叫都 24/7 計費，且每 instance 有 throughput 上限。

Direct VPC egress（第 2 代）

Cloud Functions 第 2 代支援 Direct VPC egress，函式底層的 Cloud Run instance 直接接到 VPC subnet，不用 connector。用 --network=my-vpc --subnet=my-subnet 設定。Direct VPC 省掉 connector 成本、移除 throughput 瓶頸、少一個 proxy hop 而降低延遲。代價是每 instance 第一次連線時冷啟動延遲較高，因為平台要拉起網路介面；以及一個 instance 吃一個 IP 的位址消耗模式，subnet 要小心規劃大小。

重試行為與 Dead-Letter Queue

可靠性語意在 HTTP 與事件驅動函式之間差異很大，這也是考試重點。

HTTP 重試（沒有內建）

HTTP 函式不會自動重試。如果 handler 回 5xx，錯誤直接傳回呼叫端，由呼叫端決定要不要重試。也就是說 HTTP 客戶端要自己負責重試政策——指數退避、jitter、circuit breaker，例如用 Cloud Tasks 或 client SDK 重試政策。

事件驅動重試

Pub/Sub 觸發與 Eventarc 觸發的函式在啟用重試後失敗會重試。第 2 代 Pub/Sub 函式的重試由底層 Pub/Sub subscription 的 ackDeadline（預設 10 秒，最大 600 秒）與 retryPolicy（最小最大退避，預設 10 秒到 600 秒）決定。第 1 代 Pub/Sub 函式部署時加 --retry 啟用 7 天內自動重試。

Dead-letter topic

要阻止無限重試迴圈，在 Pub/Sub subscription 上設一個 dead-letter topic。在 N 次遞送嘗試之後（可設 5 到 100，預設 5），訊息會被轉到 dead-letter topic 供檢查、告警或重播。這需要 Pub/Sub 服務帳戶 [email protected] 在該 topic 上有 roles/pubsub.publisher。

記憶體、CPU 與逾時設定

資源與逾時旋鈕直接決定效能、成本與函式能做的工作類型。

記憶體層級

第 1 代提供 128、256、512、1024、2048、4096、8192 MB 七個層級，CPU 隨記憶體隱式擴展。第 2 代繼承 Cloud Run，記憶體可連續設定到 32 GiB，並用 --cpu=1 到 --cpu=8 明確指定 CPU。較高記憶體每 GB-second 較貴但跑得更快，跑得快常常反而總帳單更低——測過再優化。

逾時

第 1 代 HTTP 與事件驅動函式都上限 540 秒（9 分鐘）。第 2 代 HTTP 函式可跑到 3600 秒（60 分鐘），與 Cloud Run 同；第 2 代事件驅動函式仍上限 540 秒，因為 Eventarc 與 Pub/Sub push 遞送有自己的 deadline。逾時值要設成函式工作的合理上限；逾時時平台會 SIGKILL 終止，砍掉進行中的工作不會 flush buffer。

明確選 CPU

對 CF2，--cpu=2 或更高是 CPU 密集工作（影像處理、ML 推論、壓縮）的對應旋鈕。並行為 1 時 CPU 完整給單一請求，並行大於 1 時 CPU 共用。要追次秒級延遲目標就再加 --cpu-boost，讓每個 instance 起頭 10 秒拿到額外 CPU。

白話文解釋

類比 1：電燈開關與智慧燈泡

第 1 代 Cloud Functions 是一條線的老式電燈開關。撥一下，燈亮；撥回，燈滅。一個開關、一顆燈、一次一個動作。第 2 代 Cloud Functions 是 mesh 網路上的智慧燈泡。同一個實體燈座（你的函式程式碼）可以回應幾十種觸發來源——語音指令、動作感測、排程計時、App 按鍵——因為有一個路由器（Eventarc）把每種訊號翻譯成共通協定（CloudEvents）才送到燈泡。而且燈泡可以調光、變色、同時處理多個指令（並行）。

類比 2：拿無線電的保全人員

想像一個保全人員坐在崗哨。第 1 代的世界裡，警報響起時，一個保全去查那一個警報。五個警報同時響，就要派五個不同的保全出去。第 2 代的世界裡，保全戴著無線電（並行設定），可以坐在同一個崗哨同時協調最多 1000 個警報——只要那些警報是要打電話給人而不是親自去跑現場。Pub/Sub 是調度無線電，Eventarc 是把任何建築物配線系統的警報轉成通用語言的翻譯機，Secret Manager 是放主鑰匙的上鎖抽屜。

類比 3：餐廳廚房

Cloud Functions 是一個只在訂單票印出來時才開火的廚房。Runtime（Node.js、Python、Go）是料理類別——每個廚房只專做一種。觸發器是出單機：HTTP 票來自走進門的客人（網頁請求）、Pub/Sub 票來自外送 App、GCS 票在供應商放下一箱食材時觸發、Audit Log 票在衛生稽查簽單時響。逾時是一張單可以煮多久才會被經理丟掉：舊廚房 9 分鐘，新廚房一小時。Min-instances 是淡季也保留在班的線上廚師，第一張單就不用等人打卡上班。

常見問題

Q1：背景函式與 HTTP 函式有什麼區別？

HTTP 函式由直接的 HTTPS 請求觸發，並同步回傳 response 給呼叫端。背景（事件驅動）函式則由 Pub/Sub、Cloud Storage、Firestore、Eventarc 或 Cloud Audit Logs 的事件非同步觸發。在第 2 代裡，背景函式收 CloudEvents v1.0 envelope，HTTP 函式收標準 HTTP request 物件。IAM 也不同：HTTP 函式由底層 Cloud Run 服務的 roles/run.invoker 控管，事件驅動函式則由 Eventarc 服務帳戶呼叫。

Q2：如何處理函式失敗與重試？

事件驅動函式要啟用自動重試（第 1 代用 --retry，第 2 代透過 Pub/Sub subscription 的重試政策），並把每個 handler 設計成冪等的——用 event 的 id 去重，或用交易型存儲寫入。一定要設 dead-letter topic 加上最大遞送次數上限（5-100），毒丸訊息才會被隔離而不是永遠重試。HTTP 函式的重試是呼叫端的責任；用 Cloud Tasks 做有編排、可重試的 HTTP 呼叫。

Q3：什麼時候選 Cloud Functions vs Cloud Run vs App Engine？

當你只有一個事件 handler、不需要 HTTP 路由、不需要自訂容器、執行時長短到中等時選 Cloud Functions。需要完整 Docker 容器控制、多路由 HTTP 服務、或已經容器化的工作負載時選 Cloud Run——記住 CF2 底層就是 Cloud Run。想要代管框架體驗加上 App Engine 專屬功能（如 Memorystore-backed session）時選 App Engine Standard。多數新無伺服器工作負載的實際取捨在 CF2（事件驅動簡潔）與 Cloud Run（其他一切）之間。

Q4：怎麼讓函式啟動延遲降低？

用 --min-instances=1（或更多）持續維持熱 instance。選輕量 runtime——Go 與 Node.js 冷啟動次秒，Java 與 .NET 常超過 5 秒。在 module scope 初始化重物件（資料庫連線池、ML 模型載入）而非請求 handler 內。CF2 加 --cpu-boost 在啟動時拿到更多 CPU。如果這些旋鈕還達不到延遲 SLO，那函式本身就是錯誤的抽象——用 Cloud Run 加 --min-instances 與 --cpu-always-allocated 才能拿到真正的低延遲穩態。

Q5：怎麼讓函式安全地連到私有 Cloud SQL 或 Memorystore？

私有 IP 的 Cloud SQL 與 Memorystore 都要 VPC egress。CF2 用 Direct VPC egress（--network 與 --subnet）把函式直接接到 VPC subnet。CF1 用 Serverless VPC Access Connector（--vpc-connector）。Cloud SQL 也可以用 Cloud SQL Auth Proxy 作為函式內 sidecar 模式（用 connector library 內嵌）。所有路徑都要確保函式服務帳戶有對應 IAM（Cloud SQL 是 roles/cloudsql.client），密鑰如資料庫密碼從 Secret Manager 透過 --set-secrets 取得，絕不寫死。

Q6：函式超過記憶體或逾時上限會怎樣？

記憶體耗盡會以 OOM 錯誤砍掉 function instance；平台對 HTTP 呼叫端回 500，對事件驅動來源傳遞失敗訊號（重試啟用時觸發重試）。逾時用盡時依設定逾時送 SIGKILL（第 1 代上限 540 秒、第 2 代 HTTP 上限 3600 秒、第 2 代事件驅動上限 540 秒），進行中請求失敗。長時間執行又無法切片的工作，選 Cloud Run 用其上限 3600 秒逾時加 --cpu-always-allocated 做背景處理，或用 Workflows / Cloud Tasks 編排一連串短函式呼叫。