比較 Cloud Run 函式

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

本指南將比較最新和原始的 Google Cloud 函式部署選項。本頁面可協助先前使用 Cloud Functions API 建立函式的使用者，轉換至 Cloud Run Admin API。本頁面說明幾個領域的重要差異，例如概念、設定、部署、觸發條件和重試。

比較

Cloud Run 函式有兩個版本：

• Cloud Run 函式是最新版的函式，會在 Cloud Run 上部署為服務。您可以透過下列任一方式建立這些項目：

  • Cloud Run Admin API (建議)：使用此 API 建立的函式 (例如使用Google Cloud 主控台、gcloud run、REST API 或 Terraform) 只能透過 Cloud Run Admin API 管理。
  • Cloud Functions v2 API：使用這個 API 建立的函式 (例如，使用 gcloud functions、REST API 或 Terraform) 可透過 Cloud Run Admin API 和 Cloud Functions v2 API 進行管理。使用這個 API 時，您可以在部署函式時指定觸發事件。瞭解如何分離 v2 API 函式，以便專門使用 Cloud Run Admin API 管理該函式。

• Cloud Run 函式 (第 1 代) (舊稱 Cloud Functions (第 1 代)) 是函式的原始版本，僅支援有限的事件觸發條件、執行階段和可設定性。瞭解詳情。

直接將函式部署至 Cloud Run，系統就會自動將函式建構為容器，並部署為 Cloud Run 服務。

概念

下表概述函式概念上的差異。

	Cloud Run 函式	Cloud Run 函式 (第 1 代)
舊產品名稱	Cloud Functions (第 2 代)	Cloud Functions (第 1 代)
資源模型	函式是從原始碼部署的 Cloud Run 服務	從原始碼部署函式
函式類型的術語	HTTP 函式 所有語言執行階段都支援 CloudEvents 函式 (也稱為事件導向函式)。	HTTP 函式 只有 Ruby、.NET 和 PHP 執行階段支援 CloudEvents。針對 Node.js、Go、Python 和 Java，請使用背景函式建立事件驅動函式。
已指派的 HTTPS 網址	run.app 使用 Cloud Functions v2 API 建立的函式也有 cloudfunctions.net 端點。	cloudfunctions.net
圖片註冊中心	僅限 Artifact Registry	Artifact Registry 或 Container Registry (已淘汰)
部署作業的 IAM 角色	Cloud Run 原始碼開發人員 (roles/run.sourceDeveloper) 服務用量消費者 (roles/run.serviceusage.serviceUsageConsumer) 服務帳戶使用者 (roles/iam.serviceAccountUser)	Cloud Functions 開發人員 (roles/cloudfunctions.developer)
內部基礎架構	Cloud Run	Google 內部
定價模式	Cloud Run 定價	Cloud Run 函式 (第 1 代) 定價

設定

Cloud Run 會將函式建構到容器中，並以服務的形式部署函式。將函式部署至 Cloud Run 後，您就能完全存取及控管函式的行為。舉例來說，您可以啟用直接虛擬私有雲、設定 GPU、使用掛載磁區等等。

下表列出函式設定的差異：

	Cloud Run 函式	Cloud Run 函式 (第 1 代)
要求逾時	HTTP 觸發函式的執行時間上限為 60 分鐘 使用 Cloud Functions v2 API 建立的事件驅動函式，最多可執行 9 分鐘	最長 9 分鐘
執行個體大小	最多 16 GiB RAM 和 4 個 vCPU	最多 8 GB RAM 和 2 個 vCPU
並行	每個函式執行個體最多可處理 1,000 個並行要求	每個函式執行個體 1 個並行要求
流量拆分	支援	不支援

部署作業

自 2024 年 8 月起，您可以使用 Cloud Run 部署及管理使用 Cloud Functions 第 2 版 API 建立的函式。這項異動會導致以下結果：

• 函式中繼資料 (例如執行階段 ID 和建構設定) 會儲存在 Cloud Run 服務定義中。
• 您可以使用 Cloud Run Admin API 安全地編輯函式。
• 您可以將 Cloud Run 服務定義視為函式的真實來源。

不過，請注意，使用 Cloud Run Admin API 建立的函式無法透過 Cloud Functions API 修改。

下表概略說明函式建立、部署、編輯和管理方式的差異：

	Cloud Run 函式	Cloud Run 函式 (第 1 代)
Google Cloud 控制台	Cloud Run	Cloud Run 函式 (第 1 代)
Cloud SDK	gcloud run deploy：使用 Cloud Run Admin API 或 Cloud Functions API 建立的函式。 gcloud functions deploy：使用 Cloud Functions API 建立的函式。	gcloud functions deploy --no-gen2：使用 Cloud Functions API 建立的函式。
REST API	run.googleapis.com (v1 和 v2)，適用於使用 Cloud Run Admin API 或 Cloud Functions API 建立的函式。 cloudfunctions.googleapis.com (僅限第 2 版)，適用於使用 Cloud Functions API 建立的函式。	cloudfunctions.googleapis.com (v1 和 v2)
Terraform	google_cloud_run_v2_service (使用 Cloud Run Admin API 或 Cloud Functions API 建立的函式)。 google_cloudfunctions2_function：使用 Cloud Functions API 建立的函式。	cloudfunctions_function

觸發條件和重試

下表比較函式觸發條件和重試：

	Cloud Run 函式	Cloud Run 函式 (第 1 代)
觸發及叫用函式	如果是使用 Cloud Run Admin API 建立的函式，您可以在 Google Cloud 控制台中指定觸發事件，作為部署函式的一部分，或是在使用 gcloud CLI 時，在部署函式後指定觸發事件。 如果是使用 Cloud Functions v2 API 建立的函式，您必須在函式部署期間指定觸發條件。	您可以在函式部署期間指定觸發事件。
事件類型	支援 Eventarc 支援的任何事件類型，包括透過 Cloud 稽核記錄的 90 多個事件來源。	直接支援 7 個來源的事件。
重試	如果是使用 Cloud Run Admin API 建立的函式，請更新 Eventarc 中的重試政策，並在 Pub/Sub 中設定死信主題。 如果是使用 Cloud Functions v2 API 建立的函式，您可以使用 --retry 標記，將重試指定為函式部署作業的一部分。	您可以使用 --retry 旗標，在函式部署作業中指定重試。

卸離函式

使用 Cloud Functions v2 API 建立的函式 (例如，使用 gcloud functions、REST API 或 Terraform) 可以與現有的 API 環境分離。卸離函式後，您只能使用 Cloud Run Admin API 管理函式。如果工作負載需要留在 Assured Workloads 的 run.googleapis.com API 邊界內，或是要確保工作負載使用 Cloud Run SKU，建議您這麼做。詳情請參閱「管理函式」。

後續步驟

• 請參閱部署 Cloud Run 函式的入門指南。