比較 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 代) 是函式的原始版本，事件觸發條件、執行階段和可設定性有限。瞭解如何將第 1 代函式升級至 Cloud Run。

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

概念

下表大致列出了函式的概念差異。

	Cloud Run functions	Cloud Run functions (第 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 functions (第 1 代) 定價

設定

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

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

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

部署作業

自 2024 年 8 月起，您可以使用 Cloud Run 部署及管理透過 Cloud Functions v2 API 建立的函式。這項異動會導致下列情況：

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

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

下表大致列出了建立、部署、編輯及管理函式時的差異：

	Cloud Run functions	Cloud Run functions (第 1 代)
Google Cloud 控制台	Cloud Run	Cloud Run functions (第 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 functions	Cloud Run functions (第 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 函式的入門指南。