从 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 环境中实现类似的控制措施,这些信息至关重要。对于每个工作负载,请考虑以下事项:

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

合规性和监管要求

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

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

合规性和监管要求可能与您使用的云服务提供商无关,并且这些要求也可能会影响迁移。例如,您可能需要确保数据和网络流量仅在特定地理区域(例如欧洲联盟 [EU])内传输。

评估您的部署和运营流程

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

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

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

  • 开发工作负载。评估开发团队为构建工作负载而制定的流程。例如,您的开发团队如何设计、编写和测试工作负载?
  • 生成您在来源环境中部署的工件。为了在来源环境中部署工作负载,您可能会生成可部署的工件(例如容器映像或操作系统映像),或者您可能会通过安装和配置软件来自定义现有工件(例如第三方操作系统映像)。收集有关如何生成这些工件的信息有助于确保生成的工件适合在Google Cloud中部署。
  • 存储工件。如果您生成存储在来源环境的 Artifact Registry 中的工件,则需要在 Google Cloud 环境中提供这些工件。为此,您可以使用以下策略:

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

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

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

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

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

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

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

  • 预配和配置您的资源。为了准备来源环境,您可能设计并实现了预配和配置资源的流程。例如,您可能会使用 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 步骤函数 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 工作负载可能需要更少的重构。
  • 幂等性。考虑工作负载是否对其输入具有幂等性。与需要维护已处理输入状态的工作负载相比,对输入具有幂等性的工作负载可能需要更少的重构。
  • State。考虑工作负载是否为无状态工作负载。与维护状态的工作负载相比,无状态工作负载可能需要更少的重构。如需详细了解 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 BuildCloud DeployInfrastructure 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. 重构 build 流程,以仅将工件存储在 Artifact Registry 中。
  5. 如有必要,请将要部署的较低版本的工件从来源环境中的代码库迁移到 Artifact Registry。例如,您可以将容器映像复制到 Artifact Registry。
  6. 当您不再需要来源环境中的代码库时,请将其停用。

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

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

如果您使用 Artifact Registry 存储工件,我们建议您配置控制功能来帮助您保护工件仓库,例如访问权限控制、数据渗漏防范、漏洞扫描和 Binary Authorization。如需了解详情,请参阅控制访问权限和保护工件

重构运维流程

在迁移到 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 架构框架:性能优化

后续步骤

贡献者

作者:

其他贡献者: