从 AWS 迁移到 Google Cloud：从 AWS Lambda 迁移到 Cloud Run

Last reviewed 2024-10-21 UTC

Google Cloud 提供了工具、产品、指导和专业服务，可帮助您将无服务器工作负载从 Amazon Web Services (AWS) Lambda 迁移到 Google Cloud。虽然 Google Cloud 提供了多种服务，您可以在这些服务上开发和部署无服务器应用，但本文档重点介绍如何迁移到无服务器运行时环境 Cloud Run。AWS Lambda 和 Cloud Run 有一些相似之处，例如自动预配资源、由云服务提供商进行伸缩以及按用量付费的价格模式。

本文档可帮助您设计、实现和验证将无服务器工作负载从 AWS Lambda 迁移到 Cloud Run 的方案。此外，它还为正在评估此类迁移的潜在好处和流程的用户提供指导。

本文档是关于从 AWS 迁移到Google Cloud 的系列文章中的一篇，该系列文章包括以下文档：

如需详细了解如何为业务逻辑选择合适的无服务器运行时环境，请参阅选择托管式容器运行时环境。如需全面了解 AWS 和 Google Cloud 服务之间的对应关系，请参阅比较 AWS 和 Azure 服务与 Google Cloud 服务。

如需迁移到 Google Cloud，建议您遵循迁移到 Google Cloud：使用入门中所述的迁移框架。

下图说明了迁移过程的路径。

迁移路径包含四个阶段。

您可能需要通过一系列迭代从来源环境迁移到 Google Cloud ，例如，您可能会先迁移一部分工作负载，然后再迁移其他工作负载。对于每个单独的迁移迭代，您都需要遵循一般迁移框架的各个阶段：

  1. 评估和发现工作负载和数据。
  2. 在 Google Cloud上规划和构建基础。
  3. 将工作负载和数据迁移到 Google Cloud。
  4. 优化您的 Google Cloud 环境。

如需详细了解此框架的各个阶段，请参阅迁移到 Google Cloud：使用入门。

如需设计有效的迁移计划，建议您验证计划的每个步骤，并确保您具有回滚策略。为了帮助您验证迁移计划，请参阅迁移到 Google Cloud：验证迁移计划的最佳实践。

迁移无服务器工作负载通常不仅是将函数从一个云服务提供商迁移到另一个云服务提供商。由于基于云的应用依赖于互联的服务网络，因此从 AWS 迁移到 Google Cloud 可能需要将依赖的 AWS 服务替换为 Google Cloud 服务。例如，假设您的 Lambda 函数与 Amazon SQS 和 Amazon SNS 互动。如需迁移此函数，您可能需要采用 Pub/Sub 和 Cloud Tasks 来实现类似的功能。

迁移还为您提供了一个宝贵的机会，让您可以全面审核无服务器应用的架构和设计决策。通过此审核，您可能会发现以下机会：

  • 利用 Google Cloud 内置功能进行优化：了解Google Cloud 服务是否提供独特的优势或更符合应用的要求。
  • 简化架构：评估是否可以通过整合功能或以不同方式使用Google Cloud中的服务来简化架构。
  • 提高成本效益：评估在 Google Cloud上提供的基础架构上运行重构后的应用的潜在费用差异。
  • 提高代码效率：在迁移过程中重构代码。

制定战略性迁移计划。不要将迁移视为重新托管（直接原样迁移）操作。您可以借迁移的机会来提升无服务器应用的整体设计和代码质量。

评估来源环境

在评估阶段，您需要确定从来源环境迁移到 Google Cloud的要求和依赖项。

评估阶段对于成功迁移而言至关重要。您需要深入了解需要迁移的工作负载，它们的要求和依赖项以及您当前的环境。您需要清楚自己的起点，然后才能开始成功地计划和执行 Google Cloud迁移。

评估阶段包括以下任务：

  1. 构建一个完整的工作负载清单。
  2. 根据工作负载的属性和依赖项对工作负载进行分类。
  3. 为您的团队开展 Google Cloud培训和指导。
  4. 在 Google Cloud上构建实验和概念验证。
  5. 计算目标环境的总拥有成本 (TCO)。
  6. 为工作负载选择迁移策略。
  7. 选择迁移工具。
  8. 定义迁移计划和时间表。
  9. 验证迁移计划。

如需详细了解评估阶段和这些任务，请参阅迁移到 Google Cloud：评估和发现工作负载。以下部分基于该文档中的信息。

构建 AWS Lambda 工作负载清单

如需定义迁移范围，您可以创建清单并收集有关 AWS Lambda 工作负载的信息。

为了构建 AWS Lambda 工作负载的清单，我们建议您实现基于 AWS API、AWS 开发者工具和 AWS 命令行界面的数据收集机制。

构建清单后，我们建议您收集清单中每个 AWS Lambda 工作负载的相关信息。对于每个工作负载，请重点关注有助于您预测潜在摩擦的方面。此外，您还需要分析该工作负载，了解在迁移到 Cloud Run 之前可能需要如何修改该工作负载及其依赖项。我们建议您先收集有关每个 AWS Lambda 工作负载以下方面的数据：

  • 使用场景和设计
  • 源代码库
  • 部署制品
  • 调用、触发和输出
  • 运行时和执行环境
  • 工作负载配置
  • 访问权限控制和权限
  • 合规性和监管要求
  • 部署和运营流程

使用情形和设计

收集有关工作负载的用例和设计的信息有助于确定合适的迁移策略。此信息还有助于您了解是否需要在迁移之前修改工作负载及其依赖项。对于每个工作负载，我们建议您执行以下操作：

  • 深入了解工作负载所服务的特定使用情形，并确定与其他系统、资源或进程的任何依赖关系。
  • 分析工作负载的设计和架构。
  • 评估工作负载的延迟时间要求。

源代码库

如果您需要重构 AWS Lambda 工作负载以使其与 Cloud Run 兼容，那么清点 AWS Lambda 函数的源代码会有所帮助。创建此清单需要跟踪代码库，代码库通常存储在 Git 等版本控制系统或 GitHub 或 GitLab 等开发平台中。源代码清单对于您的 DevOps 流程（例如持续集成和持续开发 (CI/CD) 流水线）至关重要，因为在迁移到 Cloud Run 时，这些流程也需要更新。

部署制品

了解工作负载需要哪些部署制品是另一个有助于您了解是否可能需要重构 AWS Lambda 工作负载的组成部分。如需确定工作负载需要哪些部署制品，请收集以下信息：

  • 用于部署工作负载的部署软件包的类型。
  • 包含其他代码（例如库和其他依赖项）的任何 AWS Lambda 层。
  • 工作负载所依赖的任何 AWS Lambda 扩展程序。
  • 您配置的用于指定版本和别名的限定符。
  • 已部署的工作负载版本。

调用、触发器和输出

AWS Lambda 支持多种调用机制，例如触发器，以及不同的调用模型，例如同步调用和异步调用。对于每个 AWS Lambda 工作负载，我们建议您收集以下与触发器和调用相关的信息：

  • 调用工作负载的触发器和事件源映射。
  • 工作负载是否支持同步和异步调用。
  • 工作负载网址和 HTTP(S) 端点。

您的 AWS Lambda 工作负载可以与其他资源和系统进行交互。您需要了解哪些资源会使用 AWS Lambda 工作负载的输出，以及这些资源如何使用这些输出。这些知识有助于您确定是否需要修改可能依赖于这些输出的任何内容，例如其他系统或工作负载。对于每个 AWS Lambda 工作负载，我们建议您收集有关其他资源和系统的以下信息：

  • 工作负载可能会向其发送事件的目标资源。
  • 接收异步调用信息记录的目标。
  • 工作负载所处理事件的格式。
  • 您的 AWS Lambda 工作负载及其扩展程序如何与 AWS Lambda API 或其他 AWS API 进行交互。

为了正常运行，您的 AWS Lambda 工作负载可能会存储持久性数据并与其他 AWS 服务互动。对于每个 AWS Lambda 工作负载，我们建议您收集有关数据和其他服务的以下信息：

  • 工作负载是否访问虚拟私有云 (VPC) 或其他专用网络。
  • 工作负载如何存储持久性数据，例如使用临时数据存储和 Amazon Elastic File System (EFS)。

运行时环境和执行环境

AWS Lambda 支持多种执行环境来运行工作负载。为了正确将 AWS Lambda 执行环境映射到 Cloud Run 执行环境，我们建议您针对每个 AWS Lambda 工作负载评估以下方面：

  • 工作负载的执行环境。
  • 运行工作负载的计算机处理器的指令集架构。

如果您的 AWS Lambda 工作负载在特定于语言的运行时环境中运行，请针对每个 AWS Lambda 工作负载考虑以下事项：

  • 特定于语言的运行时环境的类型、版本和唯一标识符。
  • 您对运行时环境所做的任何修改。

工作负载配置

为了在将工作负载从 AWS Lambda 迁移到 Cloud Run 时对其进行配置，我们建议您评估每个 AWS Lambda 工作负载的配置方式。

对于每个 AWS Lambda 工作负载，请收集有关以下并发和可伸缩性设置的信息：

  • 并发控制。
  • 可伸缩性设置。
  • 工作负载实例的配置，包括可用内存量和允许的最大执行时间。
  • 工作负载是否使用 AWS Lambda SnapStart、预留并发或预置并发来缩短延迟时间。
  • 您配置的环境变量，以及 AWS Lambda 配置和工作负载依赖的环境变量。
  • 标记和基于属性的访问权限控制。
  • 用于处理异常情况的状态机。
  • 使用容器映像的部署软件包的基础映像和配置文件（例如 Dockerfile）。

访问权限控制和权限

在评估过程中，我们建议您从访问控制和管理方面评估 AWS Lambda 工作负载及其配置的安全要求。如果您需要在自己的 Google Cloud 环境中实现类似的控件，这些信息至关重要。对于每个工作负载，请考虑以下事项：

  • 执行角色和权限。
  • 工作负载及其层用于访问其他资源的身份和访问权限管理配置。
  • 其他账号和服务用于访问工作负载的身份和访问权限管理配置。
  • 治理控制功能。

合规性和监管要求

对于每个 AWS Lambda 工作负载，请务必通过执行以下操作来了解其合规性和监管要求：

  • 评估工作负载需要满足的任何合规性和监管要求。
  • 确定工作负载目前是否满足这些要求。
  • 确定是否存在任何需要满足的未来要求。

合规性和监管要求可能与您使用的云提供商无关，但这些要求也可能会对迁移产生影响。例如，您可能需要确保数据和网络流量保持在特定地理位置（例如欧盟 [EU]）的边界内。

评估您的部署和运营流程

请务必清楚了解部署和运营流程的工作原理。这些流程是准备和维护生产环境以及在其中运行的工作负载的实践的基本组成部分。

部署和运营流程可能会构建工作负载正常运行所需的工件。因此，您应该收集有关每种工件类型的信息。例如，工件可以是操作系统软件包、应用部署包、操作系统映像、容器映像或其他类型。

除了工件类型之外，请考虑如何完成以下任务：

  • 开发工作负载。评估开发团队为构建工作负载而制定的流程。例如，您的开发团队如何设计、编写和测试工作负载？
  • 生成您在来源环境中部署的工件。为了在来源环境中部署工作负载，您可能会生成可部署的工件（例如容器映像或操作系统映像），或者您可能会通过安装和配置软件来自定义现有工件（例如第三方操作系统映像）。收集有关如何生成这些制品的信息有助于确保生成的制品适合在Google Cloud中部署。

  • 存储工件。如果您生成存储在来源环境的 Artifact Registry 中的制品，则需要在 Google Cloud 环境中提供这些制品。为此，您可以使用以下策略：

    • 在环境之间建立通信通道：使来源环境中的制品可从目标Google Cloud 环境进行访问。
    • 重构工件构建流程：完成来源环境的小幅度重构，以便在来源环境和目标环境中存储工件。此方法通过在目标 Google Cloud环境中实现制品构建流程之前先构建制品制品库等基础设施来支持迁移。您可以直接实现此方法，也可以在上述先建立通信通道方法的基础上进行构建。

    通过在来源环境和目标环境中均提供制品，您可以专注于迁移，而无需在迁移过程中在目标 Google Cloud 环境中实现制品构建流程。

  • 扫描代码并签名。在工件构建流程中，您可能会使用代码扫描来帮助防范常见漏洞和意外的网络泄露，并使用代码签名来帮助确保只有受信任的代码在您的环境中运行。

  • 在来源环境中部署工件。生成可部署的工件后，您可能会将其部署到来源环境中。建议您评估每个部署流程。评估有助于确保您的部署流程与 Google Cloud兼容。它还有助于您了解最终重构流程所需的工作量。例如，如果部署流程仅适用于来源环境，则可能需要重构它们，从而以您的 Google Cloud 环境为目标。

  • 注入运行时配置。您可能会注入特定集群、运行时环境或工作负载部署的运行时配置。该配置可能会初始化环境变量和其他配置值，例如 Secret、凭据和密钥。为帮助确保运行时配置注入过程在 Google Cloud上正常运行，建议您评估如何配置在来源环境中运行的工作负载。

  • 日志记录、监控和剖析。评估您实施来监控来源环境的健康、相关指标以及您如何使用这些流程提供的数据的日志记录、监控和剖析流程。

  • 身份验证。评估您如何向来源环境进行身份验证。

  • 预配和配置您的资源。为了准备来源环境，您可能设计并实现了预配和配置资源的流程。例如，您可能会使用 Terraform 以及配置管理工具在来源环境中预配和配置资源。

完成评估

从 AWS Lambda 环境构建清单后，请完成评估阶段的其余活动，如迁移到 Google Cloud：评估和发现工作负载中所述。

规划和构建基础

在规划和构建阶段，您需要预配和配置基础架构以执行以下操作：

  • 在 Google Cloud 环境中支持您的工作负载。
  • 连接来源环境和 Google Cloud 环境以完成迁移。

规划和构建阶段由以下任务组成：

  1. 构建资源层次结构。
  2. 配置 Google Cloud的 Identity and Access Management (IAM)。
  3. 设置结算功能。
  4. 设置网络连接。
  5. 强化安全性。
  6. 设置日志记录、监控和提醒。

如需详细了解这些任务，请参阅迁移到 Google Cloud：规划和构建基础。

迁移 AWS Lambda 工作负载

如需将工作负载从 AWS Lambda 迁移到 Cloud Run，请执行以下操作：

  1. 设计、预配和配置 Cloud Run 环境。
  2. 如有需要，请重构 AWS Lambda 工作负载，使其与 Cloud Run 兼容。
  3. 重构部署和运营流程，以便在 Cloud Run 上部署和观测工作负载。
  4. 迁移 AWS Lambda 工作负载所需的数据。
  5. 从功能、性能和费用方面验证迁移结果。

为帮助您避免迁移期间出现问题，并帮助估算迁移所需的工作量，我们建议您评估 AWS Lambda 功能与类似的 Cloud Run 功能之间的对比情况。在比较 AWS Lambda 和 Cloud Run 的功能时，您可能会发现它们看起来很相似。不过，两个云服务提供商在功能设计和实现方面的差异可能会对从 AWS Lambda 到 Cloud Run 的迁移产生重大影响。如以下各部分中所述，这些差异可能会影响您的设计和重构决策。

设计、预配和配置 Cloud Run 环境

迁移阶段的第一步是设计 Cloud Run 环境，使其能够支持从 AWS Lambda 迁移的工作负载。

为了正确设计 Cloud Run 环境，请使用您在评估阶段收集的有关每个 AWS Lambda 工作负载的数据。这些数据可帮助您执行以下操作：

  1. 选择合适的 Cloud Run 资源来部署工作负载。
  2. 设计 Cloud Run 资源配置。
  3. 预配和配置 Cloud Run 资源。

选择合适的 Cloud Run 资源

对于要迁移的每个 AWS Lambda 工作负载，请选择合适的 Cloud Run 资源来部署工作负载。 Cloud Run 支持以下主要资源：

  • Cloud Run 服务：一种用于托管容器化运行时环境的资源，可公开唯一端点，并根据需求自动扩缩底层基础架构。
  • Cloud Run 作业：一种资源，用于执行一个或多个容器以完成操作。

下表总结了 AWS Lambda 资源与这些主要 Cloud Run 资源的对应关系：

AWS Lambda 资源 Cloud Run 资源
由事件触发的 AWS Lambda 函数，例如用于网站和 Web 应用、API 和微服务、流式数据处理以及事件驱动型架构的事件。 可通过触发器调用的 Cloud Run 服务。
已安排运行的 AWS Lambda 函数，例如用于后台任务和批处理作业的函数。 运行直至完成的 Cloud Run 作业。

除了服务和作业之外，Cloud Run 还提供了一些其他资源来扩展这些主要资源。如需详细了解所有可用的 Cloud Run 资源，请参阅 Cloud Run 资源模型。

设计 Cloud Run 资源配置

在预配和配置 Cloud Run 资源之前，您需要先设计其配置。某些 AWS Lambda 配置选项（例如资源限制和请求超时）与类似的 Cloud Run 配置选项相当。以下部分介绍了 Cloud Run 中可用于服务触发器和作业执行、资源配置和安全性的配置选项。这些部分还重点介绍了与 Cloud Run 中的配置选项相当的 AWS Lambda 配置选项。

Cloud Run 服务触发和作业执行

迁移 AWS Lambda 工作负载时，您需要考虑的主要设计决策是服务触发器和作业执行。Cloud Run 提供了多种选项来触发和运行 AWS Lambda 中使用的基于事件的工作负载。此外，Cloud Run 还提供了一些选项，可用于流式工作负载和调度作业。

迁移工作负载时，通常最好先了解 Cloud Run 中可用的触发器和机制。这些信息有助于您了解 Cloud Run 的运作方式。 然后，您可以根据这些了解来确定哪些 Cloud Run 功能可与 AWS Lambda 功能相媲美，以及在重构这些工作负载时可以使用哪些 Cloud Run 功能。

如需详细了解 Cloud Run 提供的服务触发器，请参阅以下资源：

如需详细了解 Cloud Run 提供的作业执行机制，请参阅以下资源：

为了帮助您了解哪些 Cloud Run 调用或执行机制可与 AWS Lambda 调用机制相媲美，请参考下表。对于需要预配的每个 Cloud Run 资源，请务必选择正确的调用或执行机制。

AWS Lambda 功能 Cloud Run 功能
HTTPS 触发器（函数网址） HTTPS 调用
HTTP/2 触发器（使用外部 API 网关部分支持） HTTP/2 调用（原生支持）
WebSocket（通过外部 API 网关支持） WebSocket（原生支持）
不适用（不支持 gRPC 连接） gRPC 连接
异步调用 Cloud Tasks 集成
安排的调用 Cloud Scheduler 集成
采用专有事件格式的基于事件的触发器 以 CloudEvents 格式进行基于事件的调用
Amazon SQS 和 Amazon SNS 集成 Pub/Sub 集成
AWS Lambda Step Functions Workflows 集成
Cloud Run 资源配置

为了补充您为触发和运行迁移的工作负载而做出的设计决策，Cloud Run 支持多种配置选项，可让您微调运行时环境的多个方面。这些配置选项包括资源服务和作业。

如前所述，您可以先了解 Cloud Run 中提供的所有配置选项，从而更好地了解 Cloud Run 的运作方式。了解这些信息后，您便可以将 AWS Lambda 功能与类似的 Cloud Run 功能进行比较，并确定如何重构工作负载。

如需详细了解 Cloud Run 服务提供的配置，请参阅以下资源：

如需详细了解 Cloud Run 提供的作业，请参阅以下资源：

为了帮助您了解哪些 Cloud Run 配置选项与 AWS Lambda 配置选项相当，请参阅下表。对于需要预配的每个 Cloud Run 资源，请务必选择正确的配置选项。

AWS Lambda 功能 Cloud Run 功能
预配置并发 实例数下限
每个实例的预留并发数
（并发池在 AWS 账号中的 AWS Lambda 函数之间共享。）		 每个服务的实例数上限
不适用（不支持，一个请求对应一个实例） 每个实例的并发请求数
不适用（取决于内存分配） CPU 分配
可伸缩性设置 服务的实例自动扩缩
作业的并行性
实例配置（CPU、内存） CPU 和内存限制
执行时间上限 服务请求超时时间
作业的任务超时时间
AWS Lambda SnapStart 启动 CPU 加速
环境变量 环境变量
临时数据存储 内存中卷装载
Amazon Elastic File System 连接 NFS 卷装载
不支持 S3 卷装载 Cloud Storage 卷装载
AWS Lambda 工作负载中的 AWS Secrets Manager Secret
工作负载网址和 HTTP(S) 端点 自动分配的网址
Cloud Run 与 Google Cloud 产品的集成
粘性会话（使用外部负载均衡器） 会话亲和性
限定符 修订版本

除了上表中列出的功能之外，您还应考虑 AWS Lambda 和 Cloud Run 在预配执行环境实例方面的差异。AWS Lambda 会为每个并发请求预配一个实例。不过，Cloud Run 可让您设置一个实例可以处理的并发请求数。也就是说，AWS Lambda 的预配行为相当于在 Cloud Run 中将每个实例的并发请求数上限设置为 1。将并发请求数上限设置为大于 1 可以显著节省费用，因为并发请求会共用实例的 CPU 和内存，但只需支付一次费用。大多数 HTTP 框架都旨在并行处理请求。

Cloud Run 安全性和访问权限控制

在设计 Cloud Run 资源时，您还需要确定迁移的工作负载所需的安全和访问控制措施。Cloud Run 支持多种配置选项，可帮助您保护环境，并为 Cloud Run 工作负载设置角色和权限。

本部分重点介绍了 Cloud Run 中提供的安全和访问权限控制功能。此信息有助于您了解迁移的工作负载在 Cloud Run 中的运行方式，并确定在重构这些工作负载时可能需要的 Cloud Run 选项。

如需详细了解 Cloud Run 提供的身份验证机制，请参阅以下资源：

如需详细了解 Cloud Run 提供的安全功能，请参阅以下资源：

为了帮助您了解哪些 Cloud Run 安全和访问权限控制功能与 AWS Lambda 中提供的功能相当，请参阅下表。对于需要预配的每个 Cloud Run 资源，请务必选择合适的访问权限控制和安全功能。

AWS Lambda 功能 Cloud Run 功能
使用 AWS Identity and Access Management 控制访问权限 使用 Google Cloud的 IAM 进行访问权限控制
执行角色 Google Cloud的 IAM 角色
权限边界 Google Cloud的 IAM 权限和自定义受众群体
治理控件 组织政策服务
代码签名 Binary Authorization
完整的 VPC 访问权限 精细的 VPC 出站流量访问权限控制

预配和配置 Cloud Run 资源

选择要部署工作负载的 Cloud Run 资源后，您需要预配和配置这些资源。如需详细了解如何配置 Cloud Run 资源，请参阅以下内容：

重构 AWS Lambda 工作负载

如需将 AWS Lambda 工作负载迁移到 Cloud Run，您可能需要重构这些工作负载。例如，如果基于事件的工作负载接受包含 Amazon CloudWatch 事件的触发器，您可能需要重构该工作负载，使其接受 CloudEvents 格式的事件。

有多种因素可能会影响您需要为每个 AWS Lambda 工作负载进行重构的程度，例如：

  • 架构。从架构方面考虑工作负载的设计方式。例如，与将业务逻辑与访问 AWS 特定 API 的逻辑混杂在一起的工作负载相比，已将业务逻辑与访问 AWS 特定 API 的逻辑明确分开的 AWS Lambda 工作负载可能需要较少的重构。
  • 幂等性。考虑工作负载在输入方面是否具有幂等性。与需要维护已处理输入相关状态的工作负载相比，对输入具有幂等性的工作负载可能需要更少的重构。
  • 状态。考虑工作负载是否为无状态。与维护状态的工作负载相比，无状态工作负载可能需要更少的重构。如需详细了解 Cloud Run 支持哪些服务来存储数据，请参阅 Cloud Run 存储选项。
  • 运行时环境。考虑工作负载是否对其运行时环境做出了任何假设。对于这些类型的工作负载，您可能需要在 Cloud Run 运行时环境中满足相同的假设，或者在无法对 Cloud Run 运行时环境做出相同假设的情况下重构工作负载。例如，如果工作负载需要某些软件包或库可用，您需要在将要托管该工作负载的 Cloud Run 运行时环境中安装这些软件包或库。
  • 配置注入。考虑工作负载是否支持使用环境变量和 Secret 来注入（设置）其配置。与支持其他配置注入机制的工作负载相比，支持此类注入的工作负载可能需要更少的重构。
  • API。考虑工作负载是否与 AWS Lambda API 交互。 与这些 API 交互的工作负载可能需要重构，以使用 Cloud API 和 Cloud Run API。
  • 错误报告。考虑工作负载是否使用标准输出和错误流报告错误。与使用其他机制报告错误的工作负载相比，执行此类错误报告的工作负载可能需要较少的重构。

如需详细了解如何开发和优化 Cloud Run 工作负载，请参阅以下资源：

重构部署和操作流程

重构工作负载后，您可以重构部署和运营流程以执行以下操作：

  • 在 Google Cloud 环境中预配和配置资源，而不是在来源环境中预配资源。
  • 构建和配置工作负载并在 Google Cloud中部署它们，而不是在来源环境中部署。

您在此过程早期的评估阶段收集了有关这些流程的信息。

您需要为这些流程考虑的重构类型取决于您如何设计和实现它们。重构还取决于您希望每个流程的最终状态是什么。例如，应该考虑以下事项：

  • 您可能已经在来源环境中实现了这些流程，并打算在 Google Cloud中设计和实现类似流程。例如，您可以重构这些流程，以使用 Cloud Build、Cloud Deploy 和 Infrastructure Manager。
  • 您可能已在来源环境之外的其他第三方环境中实现这些流程。在这种情况下，您需要重构这些流程，以将您的 Google Cloud 环境作为目标，而不是将来源环境作为目标。
  • 之前方法的组合。

重构部署和运营流程可能很复杂，并且可能需要花费大量精力。如果您尝试将这些任务作为工作负载迁移的一部分执行，则工作负载迁移可能会变得更加复杂，并可能使您面临风险。评估部署和操作流程后，您可能了解了其设计和复杂性。如果您估计重构部署和操作流程需要大量工作，建议您考虑将重构这些流程作为单独的专用项目的一部分。

如需详细了解如何在 Google Cloud上设计和实现部署流程，请参阅：

本文档重点介绍用于生成要部署的制品并将其部署到目标运行时环境中的部署流程。重构策略在很大程度上取决于这些流程的复杂程度。以下列表概述了一种可能的通用重构策略：

  1. 在 Google Cloud上预配制品库。例如，您可以使用 Artifact Registry 存储制品和构建依赖项。
  2. 重构构建流程，以便在来源环境和 Artifact Registry 中存储制品。
  3. 重构部署流程，以便在目标Google Cloud 环境中部署工作负载。例如，您可以先使用存储在 Artifact Registry 中的制品，在 Google Cloud中部署一小部分工作负载。然后，您逐步增加在 Google Cloud中部署的工作负载数量，直到所有要迁移的工作负载都在Google Cloud上运行。
  4. 重构构建流程，以仅将制品存储在 Artifact Registry 中。
  5. 如有必要，请将要部署的制品的早期版本从来源环境中的存储库迁移到 Artifact Registry。例如，您可以将容器映像复制到 Artifact Registry。
  6. 不再需要来源环境中的代码库时，请将其停用。

为方便在迁移过程中因意外问题而最终回滚，您可以在迁移到 Google Cloud 的过程中将容器映像存储在 Google Cloud 的当前制品库中。最后，在停用来源环境的过程中，您可以重构容器映像构建流程，以仅将制品存储在Google Cloud 中。

虽然这对于成功迁移可能并不重要，但您可能需要将早期版本的制品从源环境迁移到 Google Cloud上的制品库。例如，为了支持将工作负载回滚到任意时间点，您可能需要将较早版本的制品迁移到 Artifact Registry。如需了解详情，请参阅从第三方注册表迁移映像。

如果您使用 Artifact Registry 存储制品，我们建议您配置控制功能来帮助保护制品库，例如访问控制、数据外泄防护、漏洞扫描和二进制文件授权。如需了解详情，请参阅控制访问权限并保护制品。

重构运营流程

在迁移到 Cloud Run 的过程中，我们建议您重构运营流程，以便持续有效地监控 Cloud Run 环境。

Cloud Run 与以下运营服务集成：

迁移数据

此流程中之前的评估阶段应该已帮助您确定要迁移的 AWS Lambda 工作负载是否依赖于 AWS 环境中的数据或生成 AWS 环境中的数据。例如，您可能已确定需要将数据从 AWS S3 迁移到 Cloud Storage，或者从 Amazon RDS 和 Aurora 迁移到 Cloud SQL 和 AlloyDB for PostgreSQL。如需详细了解如何将数据从 AWS 迁移到Google Cloud，请参阅从 AWS 迁移到 Google Cloud：使用入门。

与重构部署和运营流程一样，将数据从 AWS 迁移到 Google Cloud 可能很复杂，并且可能需要花费大量精力。如果您尝试将这些数据迁移任务作为 AWS Lambda 工作负载迁移的一部分执行，则迁移可能会变得复杂，并可能使您面临风险。分析要迁移的数据后，您可能会了解数据的规模和复杂性。如果您估计迁移这些数据需要大量工作，建议您考虑将迁移数据作为单独的专用项目的一部分。

验证迁移结果

验证工作负载迁移不是一次性事件，而是一个持续的过程。在从 AWS Lambda 迁移到 Cloud Run 之前、迁移期间和迁移之后，您都需要始终专注于测试和验证。

为确保成功迁移，并尽可能提升性能和减少中断，我们建议您使用以下流程来验证要从 AWS Lambda 迁移到 Cloud Run 的工作负载：

  • 在开始迁移阶段之前，请重构现有的测试用例，以考虑目标 Google Cloud 环境。
  • 在迁移期间，验证每个迁移里程碑处的测试结果，并进行全面的集成测试。
  • 迁移完成后，请执行以下测试：
    • 基准测试：在 AWS Lambda 上建立原始工作负载的性能基准，例如在不同负载下的执行时间、资源使用率和错误率。在 Cloud Run 上复制这些测试，以找出可能表明存在迁移或配置问题的差异。
    • 功能测试：通过创建和执行测试用例来确保工作负载的核心逻辑保持一致，这些测试用例涵盖了两种环境中的各种输入和预期输出场景。
    • 负载测试：逐步增加流量，以评估 Cloud Run 在实际条件下的性能和可伸缩性。为确保顺利迁移，请解决差异问题，例如错误和资源限制。

优化您的 Google Cloud 环境

优化是迁移的最后一个阶段。在此阶段中，您将对优化任务进行迭代，直到目标环境满足您的优化要求。每个迭代的步骤如下：

  1. 评估您的当前环境、团队和优化循环。
  2. 确定优化要求和目标。
  3. 优化您的环境和团队。
  4. 调整优化循环。

重复执行这个任务序列，直到达到您的优化目标。

如需详细了解如何优化 Google Cloud 环境，请参阅迁移到 Google Cloud：优化您的环境和Google Cloud 架构完善框架：性能优化。

后续步骤

贡献者

作者：

其他贡献者：