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

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 等开发平台中。源代码目录对于持续集成和持续开发 (CI/CD) 流水线等 DevOps 流程至关重要，因为当您迁移到 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 工作负载，请确保您了解其合规性和监管要求，具体操作步骤如下：

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

合规性和监管要求可能独立于您使用的云服务提供商，并且这些要求也可能对迁移产生影响。例如，您可能需要确保数据和网络流量保留在某些地理位置（例如欧盟）的边界内。

评估您的部署和运营流程

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

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

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

  • 开发工作负载。评估开发团队为构建工作负载而制定的流程。例如，您的开发团队如何设计、编写和测试工作负载？
  • 生成您在来源环境中部署的工件。为了在来源环境中部署工作负载，您可能会生成可部署的工件（例如容器映像或操作系统映像），或者您可能会通过安装和配置软件来自定义现有工件（例如第三方操作系统映像）。收集有关如何生成这些制品的信息有助于确保生成的制品适合在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 资源
由事件（例如用于网站和 Web 应用、API 和微服务、流式数据处理以及事件驱动型架构）触发的 AWS Lambda 函数。 您可以使用触发器调用的 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 步骤函数 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 Access and 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 Lambda 工作负载可能需要较少的重构。
  • 幂等性。考虑工作负载在输入方面是否遵循幂等原则。与需要维护已处理哪些输入的状态的工作负载相比，对输入具有幂等性的工作负载可能需要较少的重构。
  • 状态。考虑工作负载是否为无状态。与维护状态的工作负载相比，无状态工作负载可能需要较少的重构。如需详细了解 Cloud Run 支持的存储数据服务，请参阅 Cloud Run 存储方案。
  • 运行时环境。考虑工作负载是否对其运行时环境做出任何假设。对于这些类型的工作负载，您可能需要满足 Cloud Run 运行时环境中的相同假设，或者如果对 Cloud Run 运行时环境不能做出相同的假设，您需要重构工作负载。例如，如果工作负载要求提供某些软件包或库，那么您需要将其安装在将要托管该工作负载的 Cloud Run 运行时环境中。
  • 配置注入。请考虑工作负载是否支持使用环境变量和密钥注入（设置）其配置。与支持其他配置注入机制的工作负载相比，支持此类注入的工作负载可能需要较少的重构。
  • 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 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 精心设计的框架：性能优化。

后续步骤

贡献者

作者：

其他贡献者：