GCP 架構
無伺服器微服務新典範：Cloud Run、Cloud Functions 與 Eventarc 實戰
無伺服器微服務新典範：Cloud Run、Cloud Functions 與 Eventarc 實戰
Cloud Run 現在是 Google Cloud 底下一整套容器執行模型的統稱，拆成四種模式：Services 處理 HTTPS 請求、Jobs 跑一次性批次任務、Worker Pools 跑背景常駐工作、Instances 跑長時間占用的持久工作負載。Cloud Functions 已經正式改名為 Cloud Run functions，底層直接以 Cloud Run 服務部署執行；而 Eventarc 則是這一整套架構的黏著層，把 Cloud Storage、Pub/Sub、Firestore 到第三方 SaaS 系統的事件，統一轉成 CloudEvents 格式的觸發訊號。
這篇會照這個順序講清楚：四種模式怎麼選、Cloud Functions 改名之後代表什麼、Eventarc 怎麼接上百種事件來源，以及冷啟動與長連線這類實務上最常被問的問題。
你將學到什麼
Cloud Run 的四種模式
Services 回應 HTTPS 請求、Jobs 跑一次性批次、Worker Pools 常駐拉資料、Instances 跑長期持久工作，四者共用同一套容器執行環境。
Cloud Functions 改名了
官方文件與主控台已全面改稱 Cloud Run functions，第二代函式本來就是以 Cloud Run 服務部署與執行。
Eventarc 接上百種事件來源
Cloud Storage、Pub/Sub、Firestore、Cloud Audit Logs 到第三方 SaaS 系統，事件一律轉成 CloudEvents 格式再送進服務。
長連線該用哪個模式？
短生命週期的請求交給 Services，持續占用連線、常駐拉資料的工作換成 Worker Pools 或 Instances。
Cloud Run 從「一個跑容器的服務」長成「一整套執行模型」，關鍵在於它把不同生命週期的工作負載拆成四種各自最適合的模式。
Cloud Run 到底是什麼，跟 GKE 有什麼不同？
Cloud Run 是 Google Cloud 的完全代管應用平台，讓你直接執行容器、函式或程式碼，不用自己建立叢集，也不用管理底層伺服器。它接受任何能塞進容器的東西，執行環境是沙箱化的容器實例。
計費邏輯是用多少付多少，以毫秒等級計費，沒有流量的時候可以縮到零，不留閒置成本。這也是它常被拿來跟 GKE 放在一起比較的原因：兩者都跑容器，差別在於你要不要自己碰節點與叢集這一層。GKE 把叢集規模、節點類型、升級排程這些決定權留給你，換取更細緻的控制；Cloud Run 則把這些全部代管掉，你只要決定容器的 CPU、記憶體與並行請求數（concurrency）這幾個參數。多數新專案如果沒有非常特殊的網路或叢集需求，從 Cloud Run 開始會比一開始就上 GKE 省下不少維運心力。
Cloud Run 的四種模式該怎麼選？
官方文件目前把 Cloud Run 拆成四種操作模式：Services、Jobs、Worker Pools 與 Instances，共用同一套底層容器執行環境，差別在觸發方式與生命週期。
- Services：透過唯一的 HTTPS 端點回應請求，支援依流量動態自動擴展，最典型的無伺服器 Web 服務型態。
- Jobs：執行一次性或可並行處理的批次任務，做完就停止，適合資料轉檔、排程結算這類工作。它支援設定平行執行的任務數量與重試次數，適合把一個大批次拆成多個獨立子任務平行處理。
- Worker Pools：持續運作的背景工作負載，設計給從訊息佇列或串流管道拉資料處理的情境，不需要公開 HTTP 端點。
- Instances：執行需要單一持久執行環境的長期工作負載，適合長時間運行、狀態較重的代理型工作。
選錯模式通常不是跑不動，而是白白多付維運力氣，例如硬把持續拉資料的背景工作塞進 Services，或是為了跑一次的批次工作常駐一個服務。
Cloud Functions 為什麼改名叫 Cloud Run functions？
如果你比較久沒碰這塊，會發現 Cloud Functions 這個名字已經正式走入歷史，官方文件目前一律稱它 Cloud Run functions。
這不只是換個招牌。第二代 Cloud Functions 骨子裡就是用 Cloud Build 建置，再以 Cloud Run 服務的形式部署與執行，等於函式即服務與容器服務共用同一套底層引擎，也支援跨語言一致的 CloudEvents 事件格式。
如果你在舊教學或舊程式庫裡看到 Cloud Functions 字樣，指的通常還是這個服務，只是文件與主控台介面已經全面改用 Cloud Run functions 這個名字。2026 年查閱時，請以官方最新頁面的用字與功能表為準。
Eventarc 怎麼把上百種事件來源接起來？
Eventarc 的角色，是讓你不用自己刻一套訊息佇列或輪詢機制，就能把「某個地方發生了什麼事」轉成「觸發某個服務去處理」。
官方把它定位成用來建立事件驅動架構、不需要自行實作或維護底層基礎設施的服務，提供 Standard 與 Advanced 兩種版本，統一處理投遞、身分驗證、可觀測性與錯誤處理。
第二代 Cloud Run functions 全面改用 Eventarc 當事件路由層，可接的事件來源大幅擴增，涵蓋 Cloud Storage、Pub/Sub、Firestore、Cloud Audit Logs 到不少第三方 SaaS 系統，事件格式統一採用業界標準 CloudEvents。
| 事件來源 | 常見觸發情境 |
|---|---|
| Cloud Storage | 有新檔案上傳，觸發影像處理或格式轉換流程 |
| Pub/Sub | 收到一則訊息，觸發非同步任務處理 |
| Cloud Audit Logs | 偵測到特定操作紀錄，觸發稽核或告警流程 |
| 第三方 SaaS 事件 | 觸發跨系統整合工作流程，減少自建輪詢邏輯 |
常見的踩坑點是權限設定：建立觸發器時要指定一個服務帳戶，這個帳戶除了要有觸發來源本身的讀取權限（例如 Pub/Sub 訂閱者角色），還需要 Cloud Run 服務的叫用者角色（roles/run.invoker），否則事件送到了，Cloud Run 那端卻拒絕呼叫。這種情況的錯誤訊息通常是 403，代表事件其實已經送達，只是沒有權限觸發，不要誤判成事件根本沒送出去而往錯的方向查。
Cloud Run 適合跑 WebSocket 跟長連線服務嗎？
Cloud Run 原生支援 WebSocket、gRPC 與 HTTP/2 雙向串流，不用額外接轉接層就能跑即時通訊類的服務。
連線可以維持的時間有逾時上限設定，實際數字會隨版本與設定調整，動手前務必查官方最新的逾時設定文件，不要憑舊印象硬套。
冷啟動一直是無伺服器平台的老問題，Cloud Run 這幾年持續在優化執行環境的啟動速度。如果你的服務對回應時間敏感、又不想承受冷啟動的延遲，可以設定最小執行個體數（min instances），讓 Cloud Run 隨時保留至少一個暖機的實例，代價是即使沒有流量也會持續產生費用，這筆取捨要自己衡量。重運算的推理類工作負載，現在也能直接掛載 NVIDIA GPU 在服務層執行，不必外接一套獨立的 GPU 叢集。
如果你的工作負載是要長時間持有單一連線、從訊息佇列持續拉資料處理，官方建議的方向是用 Worker Pools 或 Instances，而不是硬把它塞進原本設計給短生命週期請求用的 Services 模式。
怎麼選：先問自己四個問題？
- 有外部呼叫方在等 HTTPS 回應嗎？有的話，從 Services 開始想，這是設計給請求回應模式的預設選項。
- 這件事做完就結束嗎？不需要常駐的一次性批次任務用 Jobs，不用為了跑一次的事常駐一個服務。
- 是持續拉資料的背景工作嗎？不需要對外暴露端點、持續消費佇列訊息的情境，Worker Pools 通常比自己刻一套輪詢邏輯省事。
- 觸發來源分散在好幾個系統嗎？先看 Eventarc 能不能直接接上，不用自己寫一層整合程式碼。
延伸學習
思維邏輯自我訓練：28 天養成計畫（含入門練習版）
四週把「有感覺」練成「有觀點」。每天一題、一個高階任務配一個低階任務，忙的日子也接得上。買這門課直接附贈《入門練習版》八單元 22 課完整講義與練習單，排在課程最前面，先把思維訓練三部曲、知識吸收金三角這些底層工具建立起來，再進入 28 天的每日練習。
NT$ 999
HE301｜Harness Engineering Architecture（12 小時）
兩天十二小時的架構課，處理的是「第一百次仍然成功」。從能力設計出發，逐層拆解知識、脈絡、記憶、規則、工具、工作流、評估與多代理八種架構，每一種都給治理方式與真實案例。12 章 114 課圖文講義、52 張對照表，附兩天的學員講義與投影片 PDF。課程於 2026 年 8 月 30 日實體開課，完整錄影將於課後上傳。
NT$ 12,999