比较 App Engine 和 Cloud Run

本指南向熟悉 App Engine 的用户介绍 Cloud Run。其中介绍了无服务器平台之间的主要异同，以帮助您为从 App Engine 标准环境或 App Engine 柔性环境迁移进行准备。

概览

Cloud Run 以十多年来运行 App Engine 的经验为基础构建而成，是 Google Cloud 无服务器技术的最新发展成果。Cloud Run 在与 App Engine 标准环境大致相同的基础架构上运行，因此这两个平台有许多相似之处。

Cloud Run 整合了 App Engine 标准环境和 App Engine 柔性环境中的许多最佳功能，在 App Engine 体验的基础上加以改进。Cloud Run 服务可以处理与 App Engine 服务相同的工作负载，但 Cloud Run 为客户在实现这些服务时提供了更大的灵活性。这种灵活性以及与 Google Cloud 和第三方服务的加强集成也使得 Cloud Run 能够处理无法在 App Engine 上运行的工作负载。

比较摘要

虽然 App Engine 和 Cloud Run 有许多相似之处和不同之处，但此概览着重介绍了刚开始使用 Cloud Run 的 App Engine 客户最相关的方面。

资源模型

Cloud Run 资源模型与 App Engine 非常相似，但存在一些关键区别：

• Cloud Run 没有顶级应用资源或相应的 default 服务。
• 同一项目中的 Cloud Run 服务可以部署到不同区域。 在 App Engine 中，项目中的所有服务都位于同一区域。
• Cloud Run 使用“修订版本”而不是“版本”一词，以与 Knative 资源模型保持一致。
• Cloud Run 修订版本名称采用以下格式：SERVICE_NAME-REVISION_SUFFIX，其中 REVISION_SUFFIX 自动生成，或使用 --revision-suffix=REVISION_SUFFIX 部署标志设置。
• Cloud Run 修订版本是不可变的，这意味着您无法像使用 App Engine 版本那样重复使用名称（使用 --version=VERSION_ID 部署标志）。
• Cloud Run 服务网址基于首次部署服务时自动生成的服务标识符。服务标识符使用以下格式：SERVICE_NAME-<auto-generated identifier>。 服务标识符是唯一的，并且在服务的生命周期内不会更改。
• 在 Cloud Run 中，默认情况下仅公开服务网址（SERVICE_IDENTIFIER.run.app 和 https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app）。如需处理特定修订版本，您必须配置流量标记。在 App Engine 中，系统会自动公开服务网址和版本网址。

部署和配置

在 App Engine 中，大多数配置都是在每个部署中包含的 app.yaml 中完成的。这种简单性会产生一定的费用，原因是虽然可以使用 Admin API 更新一些设置，但大多数更改都需要重新部署服务。

虽然 Cloud Run 具有 service.yaml 配置文件，但它与 app.yaml 的使用方式不同。通过源代码部署时，不能使用 Cloud Run service.yaml，因为必需的元素之一是最终容器映像的路径。此外，service.yaml 符合 Knative 规范，对于不熟悉 Kubernetes 样式的配置文件的用户来说，可能难以理解。如需详细了解如何使用 service.yaml 管理配置，请参阅 Cloud Run 文档。

对于刚开始使用 Cloud Run 的 App Engine 客户，使用 gcloud CLI 部署标志与 App Engine 部署配置管理更为一致。

如需在 Cloud Run 中部署新代码时设置配置，请使用 gcloud run deploy 标志：

gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

尽管没有必要在每个部署中使用配置标志（请参阅管理配置），但这样做有助于简化配置管理。

在 Cloud Run 中，您还可以使用 gcloud run services update 更新配置，而无需重新部署源代码：

gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

由于 Cloud Run 修订版本是不可变的，因此该命令会创建具有更新后配置的新修订版本，但使用与现有修订版本相同的容器映像。

管理配置

对于 App Engine 部署，必须为每个部署提供所有设置，并且为任何未提供的设置分配默认值。以 App Engine service-a 为例，其版本使用如下所示的 app.yaml 文件：

runtime: python39
service: service-a
instance_class: F4

runtime: python39
service: service-a

runtime: python39
service: service-a
instance_class: F4
default values:
..
..

runtime: python39
service: service-a
default values:
instance_class: F1
..
..

version1 是使用 instance_class: F4 配置的，而 version2 没有为 instance_class 提供值，而是使用默认 instance_class: F1 配置的。

对于 Cloud Run，任何提供的配置设置都会应用，但任何未提供的配置设置都会保留其现有值。您只需为要更改的设置提供值。例如：

gcloud run deploy service-a \
--cpu=4

gcloud run deploy service-a

service: service-a
vCPUs: 4
default values:
..
..

service: service-a
vCPUs: 4
default values:
..
..

在 App Engine 中，如果未使用配置设置进行部署，则系统会使用所有默认设置创建一个版本。在 Cloud Run 中，如果未使用配置设置进行部署，则系统会使用与先前修订版本相同的配置设置创建一个修订版本。对于 Cloud Run 服务的第一个修订版本，不使用配置设置进行部署时将使用所有默认设置创建一个修订版本。

配置默认值

入口点

通过源代码部署时，App Engine 会从 app.yaml 中的 entrypoint 属性读取入口点命令。如果未提供入口点，则系统会使用特定于运行时的默认值。通过源代码部署时，Cloud Run 会使用 Google Cloud 的 Buildpack，并且某些语言没有默认入口点，这意味着您必须提供一个入口点，否则构建会失败。例如，Python Buildpack 需要使用 Procfile 或指定 GOOGLE_ENTRYPOINT 构建环境变量。

如需了解任何特定于语言的配置要求，请参阅 Buildpack 文档。

扩缩

虽然 Cloud Run 和 App Engine 标准环境具有很多相同的扩缩基础架构，但 Cloud Run 已得到简化，从而实现更快的扩缩。在此简化过程中，可配置的设置仅限于：

• 最大并发数
• 实例数上限和实例数下限

对于 Cloud Run 实例，目标 CPU 利用率不可配置，固定为 60%。如需详细了解自动扩缩功能，请参阅 Cloud Run 文档。

App Engine 柔性环境使用 Compute Engine 自动扩缩器，因此与 App Engine 标准环境和 Cloud Run 的扩缩特性截然不同。

空闲实例超时

在 App Engine 中，空闲实例在最后一个请求处理完成后最长保持活跃状态 15 分钟。Cloud Run 可让您使用 CPU 分配来配置此行为。要获得与 App Engine 相同的行为，请将 CPU 分配设置为始终分配 CPU。或者，使用“仅在处理请求期间分配的 CPU”，立即关停空闲实例（如果没有待处理请求）。

预热请求

Cloud Run 使用容器入口点命令自动预热实例，因此您无需手动启用预热请求或配置 /_ah/warmup 处理程序。如果您要在实例启动时运行代码，则在处理任何请求之前，您可以执行以下任一操作：

• 配置您的应用以侦听请求
• 配置自定义启动探测

静态内容

在 App Engine 标准环境中，您可以通过从 Cloud Storage 传送或通过配置处理程序来传送静态内容，而无需使用计算资源。Cloud Run 没有传送静态内容的处理程序选项，因此您可以从 Cloud Run 服务（与动态内容相同）或从 Cloud Storage 传送内容。

Cloud Run Invoker 角色

Cloud Run 还能够使用 Identity and Access Management (IAM) 控制对服务的访问权限。服务的 IAM 政策绑定可以使用 gcloud CLI、控制台或 Terraform 设置。

如需复制 App Engine 行为，您可以通过允许未经身份验证的请求来公开服务。可以在部署时设置此配置，也可以通过更新现有服务的 IAM 政策绑定来设置。

gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker"

或者，您可以选择通过授予可按服务配置的 Cloud Run Invoker IAM 角色来控制谁有权访问服务。

gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

环境变量和元数据

App Engine 和 Cloud Run 都有特定自动设置的环境变量。下表显示了 App Engine 环境变量以及等效的 Cloud Run 环境变量。与 App Engine 相比，Cloud Run 仅实现少量环境变量，但元数据服务器提供的数据大致相同。

默认环境变量

通用元数据服务器路径

后续步骤

• 快速入门：使用 Cloud Run 部署 Web 服务
• 我的应用是否适合 Cloud Run？
• 将我的 App Engine 自定义网域迁移到 Cloud Load Balancing
• 其他资源：
  • 使用 Docker 从 App Engine 迁移到 Cloud Run（Python：Codelab、视频，Java：Codelab）
  • 使用 Buildpack 从 App Engine 迁移到 Cloud Run（Python：Codelab、视频，Java：Codelab）