# Lambda 运行时 Lambda 通过使用*运行时*支持多种语言。运行时系统提供特定于语言的环境，用于在 Lambda 与函数之间中继调用事件、上下文信息和响应。您可以使用 Lambda 提供的运行时，或构建您自己的运行时。 Lambda 与您所选择的运行时无关。对于简单函数，Python 和 Node.js 等解释性语言提供最快的性能。对于计算更复杂的函数，Java 等编译语言通常初始化速度较慢，但​​在 Lambda 处理程序中运行速度很快。运行时的选择也受开发人员偏好和语言熟悉度影响。 每个主要编程语言版本都有单独的运行时，并具有唯一的*运行时标识符*，例如 `nodejs24.x` 或 `python3.14`。要将某个函数配置为使用新的主要语言版本，您需要更改运行时系统标识符。由于 AWS Lambda 无法保证主要版本之间的向后兼容性，因此该操作应由客户发起。 对于[定义为容器映像的函数](images-create.md)，您可以在创建容器映像时选择运行时系统和 Linux 发行版。要更改运行时，您需要创建一个新的容器映像。 要将 .zip 文件存档作为部署包，您需要在创建函数时选择运行时。要更改运行时，您可以[更新函数的配置](configuration-function-zip.md)。运行时与其中一个 Amazon Linux 发行版配对。底层执行环境提供了您可通过函数代码访问的额外的库和[环境变量](configuration-envvars.md)。 Lambda 调用[执行环境](lambda-runtime-environment.md)中的函数。执行环境提供管理运行函数所需的运行时和其他资源的安全、隔离的运行时环境。Lambda 会重新使用上一个调用的执行环境（如果可用），其也可以创建新的执行环境。 要在 Lambda 中使用 [Go](lambda-golang.md) 或 [Rust](lambda-rust.md) 等其他语言，请使用[仅限操作系统的运行时系统](runtimes-provided.md)。Lambda 执行环境提供[运行时接口](runtimes-api.md)来获取调用事件并发送响应。您可以通过将[自定义运行时系统](runtimes-custom.md)与函数代码一起实施来部署其他语言，也可以在[层](chapter-layers.md)中部署它们。 ## 支持的运行时 下表列出了支持的 Lambda 运行时系统和预计的弃用日期。弃用运行时系统后，您仍然可以在有限的时间内创建和更新函数。有关更多信息，请参阅 [弃用后的运行时系统使用](#runtime-deprecation-levels)。该表根据我们的 [运行时弃用策略](#runtime-support-policy) 提供了当前预测的运行时弃用日期。这些日期仅供规划之用，可能会发生变化。 **重要** Amazon Linux 2 计划于 2026 年 6 月 30 日结束生命周期。Lambda 运行时以及 Java 8（AL2）、Java 11、Java 17、Python 3.10、Python 3.11 以及 provided.al2 的容器基础映像将继续收到针对[关键和选定的重要](https://alas.aws.amazon.com/faqs.html) Amazon Linux 2 安全问题的补丁以及语言运行时补丁，直到下表所示的弃用日期。 我们建议客户尽快升级到基于 Amazon Linux 2023 的运行时环境。对于升级到 Java 21 或 Java 25 的客户，您可以使用 [AWS Transform 自定义](https://docs.aws.amazon.com/transform/latest/userguide/custom.html)来协助这些升级。对于无法升级 Java 版本的客户，我们计划在 2026 年第二季度末之前发布基于 Amazon Linux 2023 的 Java 8、Java 11 和 Java 17 运行时。 | 名称 | 标识符 | 操作系统 | 弃用日期 | 阻止函数创建 | 阻止函数更新 | | --- | --- | --- | --- | --- | --- | | Node.js 24 | `nodejs24.x` | Amazon Linux 2023 | 2028 年 4 月 30 日 | 2028 年 6 月 1 日 | 2028 年 7 月 1 日 | | Node.js 22 | `nodejs22.x` | Amazon Linux 2023 | 2027 年 4 月 30 日 | 2027 年 6 月 1 日 | 2027 年 7 月 1 日 | | Node.js 20 | `nodejs20.x` | Amazon Linux 2023 | 2026 年 4 月 30 日 | 2026 年 8 月 31 日 | Sep 30, 2026 | | Python 3.14 | `python3.14` | Amazon Linux 2023 | 2029 年 6 月 30 日 | 2029 年 7 月 31 日 | 2029 年 8 月 31 日 | | Python 3.13 | `python3.13` | Amazon Linux 2023 | 2029 年 6 月 30 日 | 2029 年 7 月 31 日 | 2029 年 8 月 31 日 | | Python 3.12 | `python3.12` | Amazon Linux 2023 | 2028 年 10 月 31 日 | 2028 年 11 月 30 日 | 2029 年 1 月 10 日 | | Python 3.11 | `python3.11` | Amazon Linux 2 | 2027 年 6 月 30 日 | 2027 年 7 月 31 日 | 2027 年 8 月 31 日 | | Python 3.10 | `python3.10` | Amazon Linux 2 | 2026 年 10 月 31 日 | 2026 年 11 月 30 日 | 2027 年 1 月 15 日 | | Java 25 | `java25` | Amazon Linux 2023 | 2029 年 6 月 30 日 | 2029 年 7 月 31 日 | 2029 年 8 月 31 日 | | Java 21 | `java21` | Amazon Linux 2023 | 2029 年 6 月 30 日 | 2029 年 7 月 31 日 | 2029 年 8 月 31 日 | | Java 17 | `java17` | Amazon Linux 2 | 2027 年 6 月 30 日 | 2027 年 7 月 31 日 | 2027 年 8 月 31 日 | | Java 11 | `java11` | Amazon Linux 2 | 2027 年 6 月 30 日 | 2027 年 7 月 31 日 | 2027 年 8 月 31 日 | | Java 8 | `java8.al2` | Amazon Linux 2 | 2027 年 6 月 30 日 | 2027 年 7 月 31 日 | 2027 年 8 月 31 日 | | .NET 10 | `dotnet10` | Amazon Linux 2023 | 2028 年 11 月 14 日 | 2028 年 12 月 14 日 | 2029 年 1 月 15 日 | | .NET 9（仅限容器） | `dotnet9` | Amazon Linux 2023 | 2026 年 11 月 10 日 | 未计划 | 未计划 | | .NET 8 | `dotnet8` | Amazon Linux 2023 | 2026 年 11 月 10 日 | 2026 年 12 月 10 日 | 2027 年 1 月 11 日 | | Ruby 3.4 | `ruby3.4` | Amazon Linux 2023 | 2028 年 3 月 31 日 | 2028 年 4 月 30 日 | 2028 年 5 月 31 日 | | Ruby 3.3 | `ruby3.3` | Amazon Linux 2023 | 2027 年 3 月 31 日 | 2027 年 4 月 30 日 | 2027 年 5 月 31 日 | | Ruby 3.2 | `ruby3.2` | Amazon Linux 2 | 2026 年 3 月 31 日 | 2026 年 8 月 31 日 | Sep 30, 2026 | | 仅限操作系统的运行时系统 | `provided.al2023` | Amazon Linux 2023 | 2029 年 6 月 30 日 | 2029 年 7 月 31 日 | 2029 年 8 月 31 日 | | 仅限操作系统的运行时系统 | `provided.al2` | Amazon Linux 2 | 2026 年 7 月 31 日 | 2026 年 8 月 31 日 | Sep 30, 2026 | **注意** 对于新区域，Lambda 将不支持设置为在未来 6 个月内弃用的运行时系统。 Lambda 通过补丁和对次要版本发布的支持使托管运行时系统及其对应的容器基础映像保持最新。有关更多信息，请参阅 [Lambda 运行时更新](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html)。 要以编程方式与 Lambda 函数中的其他 AWS 服务和资源进行交互，您可以使用其中一个 AWS SDK。Node.js、Python 和 Ruby 运行时中包含 AWS SDK 的一个版本。但是，为了保持对依赖项的完全控制并在自动运行时更新期间最大限度地提高[向后兼容性](runtimes-update.md#runtime-update-compatibility)，建议您始终在函数的部署包或 [Lambda](chapter-layers.md) 层中包含您的代码使用的 SDK 模块（以及任何依赖项）。 建议您仅在部署中无法包含其他程序包时才使用包含运行时的 SDK 版本。例如，当您使用 Lambda 控制台代码编辑器或在 CloudFormation 模板中使用内联函数代码创建函数时。 Lambda 会定期更新 Node.js、Python 和 Ruby 运行时中包含的 AWS SDK 的版本。要确定您正在使用的运行时中包含的 AWS SDK 版本，请参阅以下部分： + [包含运行时的 SDK 版本（Node.js）](lambda-nodejs.md#nodejs-sdk-included) + [包含运行时的 SDK 版本（Python）](lambda-python.md#python-sdk-included) + [包含运行时的 SDK 版本（Ruby）](lambda-ruby.md#ruby-sdk-included) 弃用 Go 1.x 运行时系统后，Lambda 继续支持 Go 编程语言。有关更多信息，请参阅 AWS Compute Blog **上的 [Migrating AWS Lambda functions from the Go1.x runtime to the custom runtime on Amazon Linux 2](https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-from-the-go1-x-runtime-to-the-custom-runtime-on-amazon-linux-2/)。 受支持的所有 Lambda 运行时系统均支持 x86\$164 和 arm64 架构。 ## 新的运行时系统版本 只有在新语言版本的发布周期达到长期支持（LTS）阶段时，Lambda 才会为其提供托管运行时系统。例如，在 [Node.js 发布周期](https://nodejs.org/en/about/previous-releases)中，当发布进入 Active LTS 阶段时。 在版本进入长期支持阶段之前，其仍处于开发阶段，仍可能发生重大变化。默认情况下，Lambda 会自动应用运行时系统更新，因此对运行时系统版本进行重大更改可能会导致函数无法按预期运行。 Lambda 不为未计划发布 LTS 的语言版本提供托管运行时系统。 下表列出了即将推出的 Lambda 运行时系统的目标发布月份。这些日期可能会发生变化，仅供参考。 + **Ruby 3.5**：2026 年 3 月 + **AL2023 上的 Java 8、11 和 17**：2026 年第二季度 + **Node.js 26**：2026 年 11 月 + **Python 3.15**：2026 年 11 月 ## 运行时弃用策略 适用于 .zip 文件存档的 Lambda 运行时是围绕不断进行维护和安全更新的操作系统、编程语言和软件库的组合构建的。Lambda 的标准弃用策略是，当运行时系统的任何主要组件的社区长期支持（LTS）结束且安全更新不再可用时，就会弃用该运行时系统。大多数情况是因为语言运行时系统，但是在某些情况下，由于操作系统（OS）的 LTS 结束，也可能会弃用运行时系统。 当运行时被弃用后，AWS 可能不再对该运行时系统应用安全补丁或更新，使用该运行时系统的函数将不再有资格获得技术支持。此类已弃用的运行时系统按“原样”提供，不提供任何担保，并且可能包含漏洞、错误、缺陷或其他漏洞。 要了解有关管理运行时系统升级和弃用的更多信息，请参阅以下部分和 AWS Compute Blog** 上的 [Managing AWS Lambda runtime upgrades](https://aws.amazon.com/blogs/compute/managing-aws-lambda-runtime-upgrades/)。 **重要** Lambda 偶尔会将 Lambda 运行时系统所支持的语言版本的支持终止日期延后一段有限的时间。在此期间，Lambda 仅对运行时系统操作系统应用安全补丁。Lambda 在编程语言运行时系统的支持到期后不会对其应用安全补丁。 ## 责任共担模式 Lambda 负责为所有受支持的托管运行时和容器基础映像整理和发布安全更新。默认情况下，Lambda 将这些更新自动应用于使用托管式运行时的函数。如果默认的自动运行时更新设置已更改，则请参阅[运行时管理控件责任共担模式](runtime-management-shared.md)。对于使用容器映像部署的函数，您负责从最新的基础映像中重建函数的容器映像并对其进行重新部署。 当运行时被弃用时，Lambda 更新托管式运行时和容器基础映像的责任即告终止。您将负责升级函数以使用支持的运行时或基础映像。 在所有情况下，您都有责任将更新应用于函数代码，包括其依赖项。下表汇总了您在责任共担模式下的责任。 | 运行时生命周期阶段 | Lambda 的责任 | 您的责任 | | --- | --- | --- | | 支持的托管式运行时 | 提供定期的运行时更新，包括安全补丁和其他更新。 默认情况下自动应用运行时更新（有关非默认行为，请参阅 [运行时更新模式](runtimes-update.md#runtime-management-controls)）。 | 更新您的函数代码，包括依赖项，以解决任何安全漏洞。 | | 支持的容器映像 | 通过安全补丁和其他更新提供对容器基础映像的定期更新。 | 更新您的函数代码，包括依赖项，以解决任何安全漏洞。 使用最新的基础映像定期重新构建和重新部署您的容器映像。 | | 托管式运行时即将弃用 | 在运行时弃用之前，通过文档、Health Dashboard、电子邮件和 Trusted Advisor 通知客户。 运行时更新的责任在弃用时结束。 | 监控 Lambda 文档、Health Dashboard、电子邮件或 Trusted Advisor 以了解运行时弃用信息。 在弃用之前的运行时之前，将函数升级到支持的运行时。 | | 容器映像即将弃用 | 使用容器映像的函数不可用弃用通知。 容器基础映像更新的责任在弃用时结束。 | 在弃用之前的映像之前，请注意弃用计划并将函数升级到支持的基础映像。 | ## 弃用后的运行时系统使用 当运行时被弃用后，AWS 可能不再对该运行时系统应用安全补丁或更新，使用该运行时系统的函数将不再有资格获得技术支持。虽然您可以继续无限期地调用您的函数，但 AWS 强烈建议您迁移到受支持的运行时。已弃用的运行时按“原样”提供，不提供任何担保，并且可能包含漏洞、错误、缺陷或其他漏洞。使用已弃用运行时的函数也可能会出现性能下降或证书过期等其他问题，进而导致函数无法正常运行。 在某个运行时弃用后，您可以随时更新函数以使用较新的受支持的运行时。我们建议在生产环境中应用更改之前使用新的运行时测试您的函数。函数更新受阻后，您将无法恢复到已弃用的运行时。建议使用函数[版本](configuration-versions.md)和[别名](configuration-aliases.md)，以便通过回滚来实现安全部署。 以下时间线描述了运行时被弃用时发生的情况： | 运行时生命周期阶段 | 时间 | 内容 | | --- | --- | --- | | 弃用通知期 | 弃用前至少 180 天 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/lambda-runtimes.html) | | 弃用 | 弃用日期 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/lambda-runtimes.html) | | 阻止函数创建 | 弃用后至少 30 天 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/lambda-runtimes.html) | | 阻止函数更新 | 弃用后至少 60 天 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/lambda-runtimes.html) | **注意** 对于某些运行时系统，AWS 会将块函数创建日期和块函数更新日期推迟到弃用后通常的 30 天和 60 天之后。AWS 根据客户反馈进行了此项更改，让您有更多时间升级函数。请参阅 [支持的运行时](#runtimes-supported) 和 [已弃用的运行时](#runtimes-deprecated) 中的表格，查看运行时系统的相关日期。在这些表提供的日期之前，Lambda 不会开始阻止函数创建或更新。 ## 接收运行时系统弃用通知 当运行时系统接近其弃用日期时，如果您 AWS 账户 中的任何函数使用该运行时，Lambda 会向您发送电子邮件提醒。通知还显示在 Health Dashboard 和 AWS Trusted Advisor 中。 + 接收电子邮件通知： Lambda 会在运行时系统被弃用前至少 **180 天**向您发送电子邮件提醒。这封电子邮件将列出使用运行时系统的所有函数的 \$1LATEST 版本。要查看受影响函数版本的完整列表，请使用 Trusted Advisor 或查看 [检索使用已弃用运行时的 Lambda 函数的相关数据](runtimes-list-deprecated.md)。 Lambda 会向您 AWS 账户 的主要账户联系人发送电子邮件通知。有关查看或更新账户中电子邮件地址的信息，请参阅《AWS 一般参考》**中的[更新联系人信息](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html)。 + 通过 Health Dashboard 接收通知： Health Dashboard 将在运行时系统被弃用前至少 **180 天**显示通知。通知显示在**您的账户运行状况**页面的[其他通知](https://health.aws.amazon.com/health/home#/account/dashboard/other-notifications)下。通知的**受影响资源**选项卡列出了使用运行时系统的所有函数的 \$1LATEST 版本。 **注意** 要查看受影响函数版本的最新完整列表，请使用 Trusted Advisor 或查看 [检索使用已弃用运行时的 Lambda 函数的相关数据](runtimes-list-deprecated.md)。 Health Dashboard 通知将在受影响的运行时系统被弃用 90 天后过期。 + 使用 AWS Trusted Advisor Trusted Advisor 将在运行时被弃用前至少 **180 天**显示通知。通知显示在[安全](https://console.aws.amazon.com/trustedadvisor/home#/category/security)页面上。受影响函数的列表显示在**使用弃用运行时系统的 AWS Lambda 函数**下。此函数列表显示 \$1LATEST 和已发布的版本，并会自动更新以反映函数的当前状态。 您可以在 Trusted Advisor 控制台的[首选项](https://console.aws.amazon.com/trustedadvisor/home?#/preferences)页面中的 Trusted Advisor 打开每周电子邮件通知。 ## 已弃用的运行时 已经终止对下列运行时的支持： | 名称 | 标识符 | 操作系统 | 弃用日期 | 阻止函数创建 | 阻止函数更新 | | --- | --- | --- | --- | --- | --- | | Python 3.9 | python3.9 | Amazon Linux 2 | 2025 年 12 月 15 日 | 2026 年 8 月 31 日 | Sep 30, 2026 | | Node.js 18 | nodejs18.x | Amazon Linux 2 | 2025 年 9 月 1 日 | 2026 年 8 月 31 日 | Sep 30, 2026 | | .NET 6 | dotnet6 | Amazon Linux 2 | 2024 年 12 月 20 日 | 2026 年 8 月 31 日 | Sep 30, 2026 | | Python 3.8 | python3.8 | Amazon Linux 2 | 2024 年 10 月 14 日 | 2026 年 8 月 31 日 | Sep 30, 2026 | | Node.js 16 | nodejs16.x | Amazon Linux 2 | 2024 年 6 月 12 日 | 2026 年 8 月 31 日 | Sep 30, 2026 | | .NET 7（仅限容器） | dotnet7 | Amazon Linux 2 | 2024 年 5 月 14 日 | 不适用 | 不适用 | | Java 8 | java8 | Amazon Linux | 2024 年 1 月 8 日 | 2024 年 2 月 8 日 | Sep 30, 2026 | | Go 1.x | go1.x | Amazon Linux | 2024 年 1 月 8 日 | 2024 年 2 月 8 日 | Sep 30, 2026 | | 仅限操作系统的运行时系统 | provided | Amazon Linux | 2024 年 1 月 8 日 | 2024 年 2 月 8 日 | Sep 30, 2026 | | Ruby 2.7 | ruby2.7 | Amazon Linux 2 | 2023 年 12 月 7 日 | 2024 年 1 月 9 日 | Sep 30, 2026 | | Node.js 14 | nodejs14.x | Amazon Linux 2 | 2023 年 12 月 4 日 | 2024 年 1 月 9 日 | Sep 30, 2026 | | Python 3.7 | python3.7 | Amazon Linux | 2023 年 12 月 4 日 | 2024 年 1 月 9 日 | Sep 30, 2026 | | .NET Core 3.1 | dotnetcore3.1 | Amazon Linux 2 | 2023 年 4 月 3 日 | 2023 年 4 月 3 日 | 2023 年 5 月 3 日 | | Node.js 12 | nodejs12.x | Amazon Linux 2 | 2023 年 3 月 31 日 | 2023 年 3 月 31 日 | 2023 年 4 月 30 日 | | Python 3.6 | python3.6 | Amazon Linux | 2022 年 7 月 18 日 | 2022 年 7 月 18 日 | 2022 年 8 月 29 日 | | .NET 5（仅限容器） | dotnet5.0 | Amazon Linux 2 | 2022 年 5 月 10 日 | 不适用 | 不适用 | | .NET Core 2.1 | dotnetcore2.1 | Amazon Linux | 2022 年 1 月 5 日 | 2022 年 1 月 5 日 | 2022 年 4 月 13 日 | | Node.js 10 | nodejs10.x | Amazon Linux 2 | 2021 年 7 月 30 日 | 2021 年 7 月 30 日 | 2022 年 2 月 14 日 | | Ruby 2.5 | ruby2.5 | Amazon Linux | 2021 年 7 月 30 日 | 2021 年 7 月 30 日 | 2022 年 3 月 31 日 | | Python 2.7 | python2.7 | Amazon Linux | 2021 年 7 月 15 日 | 2021 年 7 月 15 日 | 2022 年 5 月 30 日 | | Node.js 8.10 | nodejs8.10 | Amazon Linux | 2020 年 3 月 6 日 | 2020 年 2 月 4 日 | 2020 年 3 月 6 日 | | Node.js 4.3 | nodejs4.3 | Amazon Linux | 2020 年 3 月 5 日 | 2020 年 2 月 3 日 | 2020 年 3 月 5 日 | | Node.js 4.3 边缘 | nodejs4.3-edge | Amazon Linux | 2020 年 3 月 5 日 | 2019 年 3 月 31 日 | 2019 年 4 月 30 日 | | Node.js 6.10 | nodejs6.10 | Amazon Linux | 2019 年 8 月 12 日 | 2019 年 7 月 12 日 | 2019 年 8 月 12 日 | | .NET Core 1.0 | dotnetcore1.0 | Amazon Linux | 2019 年 6 月 27 日 | 2019 年 6 月 30 日 | 2019 年 7 月 30 日 | | .NET Core 2.0 | dotnetcore2.0 | Amazon Linux | 2019 年 5 月 30 日 | 2019 年 4 月 30 日 | 2019 年 5 月 30 日 | | Node.js 0.10 | nodejs | Amazon Linux | 2016 年 8 月 30 日 | 2016 年 9 月 30 日 | 2016 年 10 月 31 日 | 在大多数情况下，语言版本或操作系统的使用结束期限预先可知。以下链接提供了 Lambda 支持作为托管运行时系统使用的每种语言的终止使用计划。 **语言和框架支持政策** + **Node.js** – [github.com](https://github.com/nodejs/Release#release-schedule) + **Python** – [devguide.python.org](https://devguide.python.org/versions/#versions) + **Ruby** – [www.ruby-lang.org](https://www.ruby-lang.org/en/downloads/branches/) + **Java** – [www.oracle.com](https://www.oracle.com/java/technologies/java-se-support-roadmap.html) 和 [Corretto 常见问题](https://aws.amazon.com/corretto/faqs/) + **Go** – [golang.org](https://golang.org/doc/devel/release.html) + **.NET** – [dotnet.microsoft.com](https://dotnet.microsoft.com/platform/support/policy/dotnet-core) # 了解 Lambda 如何管理运行时版本更新 Lambda 通过安全更新、错误修复、新功能、性能增强和对次要发行版的支持，使每个托管运行时保持更新。这些运行时更新作为*运行时版本*发布。Lambda 通过将函数从早期运行时版本迁移到新的运行时版本，来对函数应用运行时更新。 对于使用托管式运行时的函数，默认情况下，Lambda 会自动应用运行时更新。借助自动运行时更新，Lambda 免去了修补运行时版本的操作负担。对于大多数客户来说，自动更新是正确的选择。您可以通过[配置运行时管理设置](runtime-management-configure-settings.md)来更改此默认行为。 Lambda 还将每个新的运行时版本作为容器映像发布。要更新基于容器的函数的运行时版本，您必须从更新后的基本映像[创建一个新的容器映像](images-create.md)并重新部署函数。 每个运行时版本都与版本号和 ARN（Amazon 资源名称）相关联。运行时版本号使用 Lambda 定义的编号方案，独立于编程语言使用的版本号。运行时版本号并不总是连续的。例如，版本 42 后可能是版本 45。运行时版本 ARN 是每个运行时版本的唯一标识符。您可以在 Lambda 控制台或[函数日志 `INIT_START` 行](runtime-management-identify.md)中查看函数当前运行时版本的 ARN。 不应将运行时版本与运行时标识符混淆。每个运行时都有唯一的**运行时标识符**，例如 `python3.14` 或 `nodejs24.x`。它们对应于每个主要的编程语言版本。运行时版本描述单个运行时的补丁版本。 **注意** 相同运行时版本号的 ARN 可能因 AWS 区域 和 CPU 架构而异。 **Topics** + [ ## 向后兼容性 ](#runtime-update-compatibility) + [ ## 运行时更新模式 ](#runtime-management-controls) + [ ## 两阶段运行时版本推出 ](#runtime-management-two-phase) + [ # 配置 Lambda 运行时管理设置 ](runtime-management-configure-settings.md) + [ # 回滚 Lambda 运行时版本 ](runtime-management-rollback.md) + [ # 识别 Lambda 运行时版本更改 ](runtime-management-identify.md) + [ # 了解 Lambda 运行时管理的责任共担模式 ](runtime-management-shared.md) + [ # 控制高合规性应用程序的 Lambda 运行时更新权限 ](runtime-management-hc-applications.md) ## 向后兼容性 Lambda 致力于提供与现有函数向后兼容的运行时更新。但是，与软件修补一样，在极少数情况下，运行时更新会对现有函数产生负面影响。例如，安全性补丁可能会暴露现有函数的潜在问题，而该问题取决于先前的不安全行为。 在构建和部署函数时，重要的是要了解如何管理依赖项，以避免与未来的运行时更新可能出现不兼容。例如，假设您的函数依赖于程序包 A，而程序包 A 又依赖于程序包 B。两个包程序都包含在 Lambda 运行时中（例如，它们可能是 SDK 或其依赖项的一部分，或者是运行时系统库的一部分）。 考虑以下场景： | 部署 | 补丁兼容 | Reason | | --- | --- | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/runtimes-update.html) | 是 | 将来对程序包 A 和 B 的运行时更新是向后兼容的。 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/runtimes-update.html) | 是 | 您的部署具有优先权，因此未来对程序包 A 和 B 的运行时更新无效。 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/runtimes-update.html) | 是\$1 | 未来对程序包 B 的运行时更新是向后兼容的。 \$1如果 A 和 B 紧密耦合，则可能会出现兼容性问题。例如，适用于 Python 的 AWS SDK 中的 `boto3` 和 `botocore` 程序包应该一起部署。 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/runtimes-update.html) | 否 | 未来对程序包 A 的运行时更新可能需要程序包 B 的更新版本。但是，程序包 B 的已部署版本优先，并且可能与程序包 A 的更新版本不兼容。 | 为保持与未来的运行时更新兼容，请遵循以下最佳实践： + **如果可能，将所有依赖项打包：**在部署包中包含所有必需的库，包括 AWS SDK 及其依赖项。这样可以确保一组稳定、兼容的组件。 + **谨慎使用运行时提供的 SDK：**只有在无法包含其他程序包时（例如，在 AWS CloudFormation 模板中使用 Lambda 控制台代码编辑器或内联代码时），才依赖运行时提供的 SDK。 + **避免覆盖系统库：**不要部署可能与未来的运行时更新冲突的自定义操作系统库。 ## 运行时更新模式 Lambda 致力于提供与现有函数向后兼容的运行时更新。但是，与软件修补一样，在极少数情况下，运行时更新会对现有函数产生负面影响。例如，安全性补丁可能会暴露现有函数的潜在问题，而该问题取决于先前的不安全行为。在运行时版本不兼容的极少数情况下，Lambda 运行时管理控件有助于减少对工作负载造成任何有风险的影响。对于每个[函数版本](configuration-versions.md)（`$LATEST` 或已发布版本），您可以选择以下运行时更新模式之一： + **自动（默认）**– 通过 [两阶段运行时版本推出](#runtime-management-two-phase)，自动更新到最新的安全运行时版本。我们建议大多数客户使用此模式，以便您始终受益于运行时更新。 + **函数更新** – 当您更新函数时，系统将更新到最新的安全运行时版本。当您更新函数时，Lambda 会将函数的运行时更新为最新的安全运行时版本。这种方法可将运行时更新与函数部署同步，这样您就可以控制 Lambda 应用运行时更新的时间。使用此模式，您可以尽早检测和缓解少数运行时更新不兼容问题。使用此模式时，您必须定期更新函数以保持最新的函数运行时。 + **手动** – 手动更新您的运行时版本。您需要在函数配置中指定运行时版本。该函数将无限期使用此运行时版本。在极少数情况下，新的运行时版本与现有函数不兼容，您可以使用此模式将函数回滚到早期运行时版本。不建议使用 **Manual**（手动）模式来尝试实现跨部署的运行时一致性。有关更多信息，请参阅 [回滚 Lambda 运行时版本](runtime-management-rollback.md)。 将运行时更新应用于函数的责任因您选择的运行时更新模式而异。有关更多信息，请参阅 [了解 Lambda 运行时管理的责任共担模式](runtime-management-shared.md)。 ## 两阶段运行时版本推出 Lambda 按照以下顺序推出新的运行时版本： 1. 在第一阶段，每当您创建或更新函数时，Lambda 都会应用新的运行时版本。当您调用 [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) 或 [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) API 操作时，函数会更新。 1. 在第二阶段，Lambda 会更新任何使用 **Auto**（自动）运行时更新模式且尚未更新到新运行时版本的函数。 推出过程的总持续时间因多种因素而异，例如运行时更新中包含的任何安全性补丁的严重性。 如果您正在积极开发和部署函数，您很可能会在第一阶段接受新的运行时版本。这可以使运行时更新与函数更新同步。在极少数情况下，最新的运行时版本会对应用程序造成负面影响，而这种方法可让您及时采取纠正措施。未处于积极开发阶段的函数在第二阶段仍能获得自动运行时更新的操作优势。 这种方法不影响设置为 **Function update**（函数更新）或 **Manual**（手动）模式的函数。使用 **Function update**（函数更新）模式的函数只有在创建或更新时才会接收最新的运行时更新。使用 **Manual**（手动）模式的函数不接收运行时更新。 Lambda 以渐进、滚动的方式跨 AWS 区域 发布新的运行时版本。如果您的函数设置为 **Auto**（自动）或 **Function update**（函数更新）模式，则同时部署到不同区域或在同一区域不同时间部署的函数可能会采用不同的运行时版本。需要在其环境中保证运行时系统版本一致性的客户应[使用容器映像部署其 Lambda 函数](images-create.md)。**手动**模式旨在作为临时缓解措施，以便在出现运行时与您的函数不兼容的极少数情况下回滚运行时版本。 # 配置 Lambda 运行时管理设置 您可以使用 Lambda 控制台或 AWS Command Line Interface（AWS CLI）配置运行时管理设置。 **注意** 您可以为每个[函数版本](configuration-versions.md)单独配置运行时管理设置。 **配置 Lambda 更新运行时版本的方式（控制台）** 1. 打开 Lamba 控制台的[函数页面](https://console.aws.amazon.com/lambda/home#/functions)。 1. 选择一个函数的名称。 1. 在 **Code**（代码）选项卡上的 **Runtime settings**（运行时设置）下，选择 **Edit runtime management configuration**（编辑运行时管理配置）。 1. 在 **Runtime management configuration**（运行时管理配置）下，选择以下选项之一： + 要让函数自动更新到最新的运行时版本，请选择 **Auto**（自动）。 + 要在更改函数后将函数更新到最新的运行时版本，请选择 **Function update**（函数更新）。 + 要仅在更改运行时版本 ARN 后将函数更新到最新的运行时版本，请选择 **Manual**（手动）。您可以在 **Runtime management configuration**（运行时管理配置）下找到运行时版本 ARN。您也可以在函数日志 `INIT_START` 行中找到 ARN。 有关这些选项的更多信息，请参阅[运行时更新模式](runtimes-update.md#runtime-management-controls)。 1. 选择**保存**。 **配置 Lambda 更新运行时版本的方式（AWS CLI）** 要为函数配置运行时管理，请运行 [put-runtime-management-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/put-runtime-management-config.html) AWS CLI 命令。使用 `Manual` 模式时，还必须提供运行时版本 ARN。 ``` aws lambda put-runtime-management-config \ --function-name my-function \ --update-runtime-on Manual \ --runtime-version-arn arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1 ``` 您应该可以看到类似于如下所示的输出内容： ``` { "UpdateRuntimeOn": "Manual", "FunctionArn": "arn:aws:lambda:us-east-2:111122223333:function:my-function", "RuntimeVersionArn": "arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1" } ``` # 回滚 Lambda 运行时版本 在极少数情况下，新的运行时版本与现有函数不兼容，您可以将其运行时版本回滚到早期版本。这样，可以使应用程序保持正常运行并最大限度地减少中断，从而在返回到最新的运行时版本之前有时间解决不兼容问题。 Lambda 不会对您可以使用任何特定运行时版本的时间施加限制。但是，我们强烈建议您尽快更新到最新的运行时版本，以便从最新的安全性补丁、性能改进和功能中受益。Lambda 提供回滚到早期运行时版本的选项，仅作为出现运行时更新兼容性问题的极少数情况下的临时缓解措施。如果长时间使用早期运行时版本的函数，最终可能会出现性能下降或证书过期等问题，进而导致函数无法正常运行。 您可以通过以下方式回滚运行时版本： + [使用手动运行时更新模式](#runtime-management-rollback-manual) + [使用已发布的函数版本](#runtime-management-rollback-published) 有关更多信息，请参阅 AWS 计算博客上的 [推出 AWS Lambda 运行时管理控件](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-runtime-management-controls/)。 ## 使用 Manual（手动）运行时更新模式回滚运行时版本 如果您使用的是 **Auto**（自动）运行时版本更新模式，或者 `$LATEST` 运行时版本，则可以使用 **Manual**（手动）模式回滚运行时版本。对于要回滚的[函数版本](configuration-versions.md)，将运行时版本更新模式更改为 **Manual**（手动），并指定先前运行时版本的 ARN。有关查找先前运行时版本的 ARN 的更多信息，请参阅 [识别 Lambda 运行时版本更改](runtime-management-identify.md)。 **注意** 如果函数的 `$LATEST` 版本配置为使用 **Manual**（手动）模式，则无法更改函数使用的 CPU 架构或运行时版本。要进行这些更改，必须更改为 **Auto**（自动）或 **Function update**（函数更新）模式。 ## 使用已发布的函数版本回滚运行时版本 已发布的[函数版本](configuration-versions.md)是您对其进行创建时，`$LATEST` 函数代码和配置的不可变快照。在 **Auto**（自动）模式下，Lambda 会在运行时版本推出的第二阶段自动更新已发布函数版本的运行时版本。在 **Function update**（函数更新）模式下，Lambda 不会更新已发布函数版本的运行时版本。 因此，使用 **Function update**（函数更新）模式的已发布函数版本会创建函数代码、配置和运行时版本的静态快照。通过将 **Function update**（函数更新）模式与函数版本结合使用，您可以将运行时更新与部署同步。您还可以通过将流量重定向到较早发布的函数版本，来协调代码、配置和运行时版本的回滚。您可以将此方法集成到持续集成和持续交付（CI/CD）中，以便在运行时更新不兼容的极少数情况下实现全自动回滚。使用此方法时，必须定期更新函数并发布新的函数版本以获取最新的运行时更新。有关更多信息，请参阅 [了解 Lambda 运行时管理的责任共担模式](runtime-management-shared.md)。 # 识别 Lambda 运行时版本更改 [运行时版本号](runtimes-update.md)和 ARN 记录在 `INIT_START` 日志行中，Lambda 每次创建新的[执行环境](concepts-basics.md#gettingstarted-concepts-runtime)时都会将其发送到 CloudWatch Logs。由于执行环境对所有函数调用使用相同的运行时系统版本，因此 Lambda 仅在执行初始化阶段时才会发送 `INIT_START` 日志行。Lambda 不会针对每次函数调用发送此日志行。Lambda 将日志行发送到 CloudWatch Logs，但不会在控制台中显示。 **注意** 运行时版本号并不总是连续的。例如，版本 42 后可能是版本 45。 **Example 示例 INIT\$1START 日志行** ``` INIT_START Runtime Version: python:3.13.v14 Runtime Version ARN: arn:aws:lambda:eu-south-1::runtime:7b620fc2e66107a1046b140b9d320295811af3ad5d4c6a011fad1fa65127e9e6I ``` 您可以使用 [Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-CreateRule.html) 来识别运行时版本之间的转换，而不是直接使用日志。以下规则计算每个 `INIT_START` 日志行中不同的运行时版本。要使用该规则，请将示例日志组名称 `/aws/lambda/*` 替换为函数或函数组的相应前缀。 ``` { "Schema": { "Name": "CloudWatchLogRule", "Version": 1 }, "AggregateOn": "Count", "Contribution": { "Filters": [ { "Match": "eventType", "In": [ "INIT_START" ] } ], "Keys": [ "runtimeVersion", "runtimeVersionArn" ] }, "LogFormat": "CLF", "LogGroupNames": [ "/aws/lambda/*" ], "Fields": { "1": "eventType", "4": "runtimeVersion", "8": "runtimeVersionArn" } } ``` 以下 CloudWatch Contributor Insights 报告显示了上述规则捕获的运行时版本转换示例。橙线表示早期运行时版本（**python:3.13.v12**）的执行环境初始化，蓝线表示新运行时版本（**python:3.13.v14**）的执行环境初始化。 ![\[\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/runtime_version_graph.png) # 了解 Lambda 运行时管理的责任共担模式 Lambda 负责为所有受支持的托管运行时和容器映像整理和发布安全更新。更新现有函数以使用最新运行时版本的责任因所使用的运行时更新模式而异。 Lambda 负责将运行时更新应用于配置为使用 **Auto**（自动）运行时更新模式的所有函数。 对于使用 **Function update**（函数更新）运行时更新模式配置的函数，您负责定期更新函数。Lambda 负责在您进行这些更新时应用运行时更新。如果您不更新函数，则 Lambda 不会更新运行时。如果您不经常更新函数，我们强烈建议您将其配置为自动运行时更新，以便其继续接收安全更新。 对于配置为使用 **Manual**（手动）运行时更新模式的函数，您需要负责更新函数以使用最新的运行时版本。强烈建议您仅使用此模式来回滚运行时版本，以此作为在出现运行时更新不兼容问题的极少数情况下的临时缓解措施。我们还建议您尽快切换为 **Auto**（自动）模式，以最大限度地减少未修补函数的时间。 如果您[使用容器映像部署函数](images-create.md)，则 Lambda 负责发布更新的基本映像。在这种情况下，您负责从最新的基本映像中重建函数的容器映像并对其进行重新部署。 下表对此进行了总结： **** | Deployment mode (部署模式) | Lambda 的责任 | 客户责任 | | --- | --- | --- | | 托管运行时，Auto（自动）模式 | 发布包含最新补丁的新运行时版本。 将运行时补丁应用于现有函数。 | 如果出现运行时更新兼容性问题的极少数情况，请回滚到先前的运行时版本。遵循[向后兼容性](runtimes-update.md#runtime-update-compatibility)的最佳实践。 | | 托管运行时，Function update（函数更新）模式 | 发布包含最新补丁的新运行时版本。 | 定期更新函数以获取最新的运行时版本。 如果您不经常更新函数，请将函数切换为 **Auto**（自动）模式。 如果出现运行时更新兼容性问题的极少数情况，请回滚到先前的运行时版本。遵循[向后兼容性](runtimes-update.md#runtime-update-compatibility)的最佳实践。 | | 托管运行时，Manual（手动）模式 | 发布包含最新补丁的新运行时版本。 | 只有在出现运行时更新兼容性问题的极少数情况下，才能使用此模式进行临时运行时回滚。 尽快将函数切换为 **Auto**（自动）或 **Function update**（函数更新）模式和最新的运行时版本。 | | 容器映像 | 发布包含最新补丁的新容器映像。 | 使用最新的容器基本映像定期重新部署函数以获取最新的补丁。 | 有关与 AWS 责任共担的更多信息，请参阅[责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)。 # 控制高合规性应用程序的 Lambda 运行时更新权限 Lambda 客户通常依赖自动运行时更新来满足修补要求。如果您的应用程序需要严格遵守修补即时性要求，则您可能需要限制对早期运行时版本的使用。您可以使用 AWS Identity and Access Management（IAM）拒绝 AWS 账户中的用户访问 [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html) API 操作，以此限制 Lambda 的运行时管理控件。此操作用于为函数选择运行时更新模式。拒绝访问此操作会导致所有函数默认为 **Auto**（自动）模式。您可以使用[服务控制策略（SCP）](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)在整个组织中应用此限制。如果您必须将函数回滚到早期运行时版本，可根据具体情况授予策略例外。 # 检索使用已弃用运行时的 Lambda 函数的相关数据 Lambda 运行时即将弃用时，Lambda 会通过电子邮件予以提醒，并在 Health Dashboard 和 Trusted Advisor 中提供通知。这些电子邮件和通知将列出使用运行时的函数的 \$1LATEST 版本。要列出所有使用特定运行时的函数版本，可以利用 AWS Command Line Interface（AWS CLI）或一种 AWS SDK。 如果有大量函数使用即将弃用的运行时，还可以借助 AWS CLI 或 AWS SDK 来确定优先更新最常调用函数的顺序。 有关如何使用 AWS CLI 和 AWS SDK 收集使用特定运行时的函数的相关数据，请参阅以下各节的内容。 ## 列出使用特定运行时的函数版本 要使用 AWS CLI 列出使用特定运行时的所有函数版本，请运行以下命令。将 `RUNTIME_IDENTIFIER` 替换为要弃用的运行时系统名称，然后选择自己的 AWS 区域 名称。要仅列出 \$1LATEST 函数版本，请在命令中省略 `--function-version ALL`。 ``` aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='RUNTIME_IDENTIFIER'].FunctionArn" ``` **提示** 该示例命令列出了特定 AWS 账户 在 `us-east-1` 区域中的函数。您需要为您的账户拥有函数的每个区域以及每个 AWS 账户 重复此命令。 您还可以使用一种 AWS SDK 列出使用特定运行时的函数。以下示例代码使用 V3 适用于 JavaScript 的 AWS SDK 和 适用于 Python (Boto3) 的 AWS SDK 来返回使用特定运行时的函数的函数 ARN 列表。该示例代码还会返回列出的各函数的 CloudWatch 日志组。您可以使用该日志组来查找该函数的上次调用日期。有关更多信息，请参阅下文的[识别最常用和最近调用的函数](#runtimes-list-deprecated-statistics)小节。 ------ #### [ Node.js ] **Example 用于列出使用特定运行时的函数的 JavaScript 代码** ``` import { LambdaClient, ListFunctionsCommand } from "@aws-sdk/client-lambda"; const lambdaClient = new LambdaClient(); const command = new ListFunctionsCommand({ FunctionVersion: "ALL", MaxItems: 50 }); const response = await lambdaClient.send(command); for (const f of response.Functions){ if (f.Runtime == ''){ // Use the runtime id, e.g. 'nodejs24.x' or 'python3.14' console.log(f.FunctionArn); // get the CloudWatch log group of the function to // use later for finding the last invocation date console.log(f.LoggingConfig.LogGroup); } } // If your account has more functions than the specified // MaxItems, use the returned pagination token in the // next request with the 'Marker' parameter if ('NextMarker' in response){ let paginationToken = response.NextMarker; } ``` ------ #### [ Python ] **Example 用于列出使用特定运行时的函数的 Python 代码** ``` import boto3 from botocore.exceptions import ClientError def list_lambda_functions(target_runtime): lambda_client = boto3.client('lambda') response = lambda_client.list_functions( FunctionVersion='ALL', MaxItems=50 ) if not response['Functions']: print("No Lambda functions found") else: for function in response['Functions']: if function['PackageType']=='Zip' and function['Runtime'] == target_runtime: print(function['FunctionArn']) # Print the CloudWatch log group of the function # to use later for finding last invocation date print(function['LoggingConfig']['LogGroup']) if 'NextMarker' in response: pagination_token = response['NextMarker'] if __name__ == "__main__": # Replace python3.12 with the appropriate runtime ID for your Lambda functions list_lambda_functions('python3.12') ``` ------ 要了解有关使用 AWS SDK 通过 [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html) 操作列出函数的更多信息，请参阅您首选编程语言的 [SDK 文档](https://aws.amazon.com/developer/tools/)。 您还可以使用 AWS Config 高级查询功能列出使用受影响运行时系统的所有函数。此查询仅返回函数的 \$1LATEST 版本，但您可以使用单个命令聚合查询以列出所有区域和多个 AWS 账户 中的函数。要了解更多信息，请参阅《AWS Config 开发人员指南》中的[查询 AWS Auto Scaling 资源的当前配置状态](https://docs.aws.amazon.com/config/latest/developerguide/querying-AWS-resources.html)。** ## 识别最常用和最近调用的函数 如果 AWS 账户 包含的函数使用即将弃用的运行时，则可能需要优先更新经常调用的函数或最近调用的函数。 如果只有几个函数，则可以使用 CloudWatch Logs 控制台通过查看函数的日志流来收集这些信息。有关更多信息，请参阅 [View log data sent to CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData)。 要查看最近调用函数的次数，您还可以利用 Lambda 控制台中显示的 CloudWatch 指标信息。要查看此信息，请执行以下操作： 1. 打开 Lamba 控制台的[函数](https://console.aws.amazon.com/lambda/home#/functions)页面。 1. 选择您想要查看调用统计信息的函数。 1. 选择**监控**选项卡。 1. 使用日期范围选择器设置要查看统计数据的时间段。最近调用显示在**调用**窗格中。 对于有大量函数的账户，借助 AWS CLI 或一种 AWS SDK，通过 [DescribeLogStreams](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DescribeLogStreams.html) 和 [GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html) API 操作以编程方式收集这些数据可能更高效。 以下示例提供了使用 V3 适用于 JavaScript 的 AWS SDK 和 适用于 Python (Boto3) 的 AWS SDK 的代码片段，用于识别特定函数的上次调用日期，并确定过去 14 天内特定函数的调用次数。 ------ #### [ Node.js ] **Example 用于查找函数上次调用时间的 JavaScript 代码** ``` import { CloudWatchLogsClient, DescribeLogStreamsCommand } from "@aws-sdk/client-cloudwatch-logs"; const cloudWatchLogsClient = new CloudWatchLogsClient(); const command = new DescribeLogStreamsCommand({ logGroupName: '', orderBy: 'LastEventTime', descending: true, limit: 1 }); try { const response = await cloudWatchLogsClient.send(command); const lastEventTimestamp = response.logStreams.length > 0 ? response.logStreams[0].lastEventTimestamp : null; // Convert the UNIX timestamp to a human-readable format for display const date = new Date(lastEventTimestamp).toLocaleDateString(); const time = new Date(lastEventTimestamp).toLocaleTimeString(); console.log(`${date} ${time}`); } catch (e){ console.error('Log group not found.') } ``` ------ #### [ Python ] **Example 用于查找函数上次调用时间的 Python 代码** ``` import boto3 from datetime import datetime cloudwatch_logs_client = boto3.client('logs') response = cloudwatch_logs_client.describe_log_streams( logGroupName='', orderBy='LastEventTime', descending=True, limit=1 ) try: if len(response['logStreams']) > 0: last_event_timestamp = response['logStreams'][0]['lastEventTimestamp'] print(datetime.fromtimestamp(last_event_timestamp/1000)) # Convert timestamp from ms to seconds else: last_event_timestamp = None except: print('Log group not found') ``` ------ **提示** 您可以使用 [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html) API 操作来查找函数的日志组名称。有关如何执行此操作的示例，请参阅[列出使用特定运行时的函数版本](#runtimes-list-deprecated-versions)中的代码。 ------ #### [ Node.js ] **Example 用于查找过去 14 天内调用次数的 JavaScript 代码** ``` import { CloudWatchClient, GetMetricStatisticsCommand } from "@aws-sdk/client-cloudwatch"; const cloudWatchClient = new CloudWatchClient(); const command = new GetMetricStatisticsCommand({ Namespace: 'AWS/Lambda', MetricName: 'Invocations', StartTime: new Date(Date.now()-86400*1000*14), // 14 days ago EndTime: new Date(Date.now()), Period: 86400 * 14, // 14 days. Statistics: ['Sum'], Dimensions: [{ Name: 'FunctionName', Value: '' }] }); const response = await cloudWatchClient.send(command); const invokesInLast14Days = response.Datapoints.length > 0 ? response.Datapoints[0].Sum : 0; console.log('Number of invocations: ' + invokesInLast14Days); ``` ------ #### [ Python ] **Example 用于查找过去 14 天内调用次数的 Python 代码** ``` import boto3 from datetime import datetime, timedelta cloudwatch_client = boto3.client('cloudwatch') response = cloudwatch_client.get_metric_statistics( Namespace='AWS/Lambda', MetricName='Invocations', Dimensions=[ { 'Name': 'FunctionName', 'Value': '' }, ], StartTime=datetime.now() - timedelta(days=14), EndTime=datetime.now(), Period=86400 * 14, # 14 days Statistics=[ 'Sum' ] ) if len(response['Datapoints']) > 0: invokes_in_last_14_days = int(response['Datapoints'][0]['Sum']) else: invokes_in_last_14_days = 0 print(f'Number of invocations: {invokes_in_last_14_days}') ``` ------ # 修改运行时环境 您可以使用[内部扩展](lambda-extensions.md)来修改运行时进程。内部扩展不是单独的进程 – 其作为运行时进程的一部分运行。 Lambda 提供特定语言的[环境变量](configuration-envvars.md)，您可以设置此变量，向运行时添加选项和工具。Lambda 还提供[包装程序脚本](#runtime-wrapper)，此脚本允许 Lambda 将运行时启动委托给脚本。您可以创建包装脚本来自定义运行时启动行为。 ## 特定于语言的环境变量 Lambda 支持仅配置方法，以便在函数初始化期间通过以下特定语言的环境变量预加载代码： + `JAVA_TOOL_OPTIONS` – 在 Java 上，Lambda 支持此环境变量以在 Lambda 中设置其他命令行变量。此环境变量允许您指定工具的初始化，特别是使用 `agentlib` 或 `javaagent` 选项启动本机或 Java 编程语言代理。有关更多信息，请参阅[`JAVA_TOOL_OPTIONS`环境变量](https://docs.aws.amazon.com/lambda/latest/dg/java-customization.html#java-tool-options)。 + `NODE_OPTIONS` – 在 [Node.js 运行时系统](lambda-nodejs.md)中可用。 + `DOTNET_STARTUP_HOOKS` – 在 .NET Core 3.1 及更高版本中，此环境变量指定了 Lambda 可以使用的程序集 (dll) 的路径。 使用特定于语言的环境变量是设置启动属性的首选方法。 ## 包装脚本 您可以创建一个*包装程序脚本*，自定义 Lambda 函数的运行时启动行为。使用包装脚本，您可以设置无法通过特定于语言的环境变量设置的配置参数。 **注意** 如果包装脚本未成功启动运行时进程，则调用可能会失败。 所有本机 [Lambda 运行时系统](lambda-runtimes.md)都支持包装脚本。[仅限操作系统的运行时系统](runtimes-provided.md)（`provided` 运行时系统系列）不支持包装脚本。 当您为函数使用包装程序脚本时，Lambda 会使用您的脚本启动运行时。Lambda 会向脚本发送解释器的路径以及标准运行时启动的所有原始参数。您的脚本可以扩展或转换程序的启动行为。例如，脚本可以注入和更改参数、设置环境变量或捕获指标、错误和其他诊断信息。 您可以通过将 `AWS_LAMBDA_EXEC_WRAPPER` 环境变量的值设置为可执行二进制文件或脚本的文件系统路径来指定脚本。 ### 示例：创建并使用包装脚本作为 Lambda 层 在以下示例中，您创建一个包装脚本，以使用 `-X importtime` 选项启动 Python 解释器。当您运行该函数时，Lambda 会生成一个日志条目，显示每次导入的导入持续时间。 **创建并使用包装脚本作为层** 1. 为层创建目录： ``` mkdir -p python-wrapper-layer/bin cd python-wrapper-layer/bin ``` 1. 在 `bin` 目录中，将以下代码粘贴到名为 `importtime_wrapper` 的新文件中。这是包装脚本。 ``` #!/bin/bash # the path to the interpreter and all of the originally intended arguments args=("$@") # the extra options to pass to the interpreter extra_args=("-X" "importtime") # insert the extra options args=("${args[@]:0:$#-1}" "${extra_args[@]}" "${args[@]: -1}") # start the runtime with the extra options exec "${args[@]}" ``` 1. 为脚本提供可执行文件权限： ``` chmod +x importtime_wrapper ``` 1. 为层创建 .zip 文件： ``` cd .. zip -r ../python-wrapper-layer.zip . ``` 1. 确认 .zip 文件具有以下目录结构： ``` python-wrapper-layer.zip └ bin └ importtime_wrapper ``` 1. 使用 .zip 包[创建层](creating-deleting-layers.md#layers-create)。 1. 使用 Lambda 控制台创建 Lambda 函数。 1. 打开 [Lambda 控制台](https://console.aws.amazon.com/lambda)。 1. 选择 **Create function**（创建函数）。 1. 输入**函数名称**。 1. 在**运行时**中，选择**支持的最新** Python 运行时。 1. 选择 **Create function (创建函数)**。 1. 将层添加到函数。 1. 选择您的函数，然后选择**代码**选项卡（如果尚未选择）。 1. 向下滚动到**层**部分，然后选择**添加层**。 1. 对于**层源**，选择**自定义层**，然后从**自定义层**下拉列表中选择您的层。 1. 对于**版本**，选择 **1**。 1. 选择 **添加**。 1. 添加包装器环境变量。 1. 选择**配置**，然后选择**环境变量**。 1. 在 **Environment variables (环境变量)** 下，选择 **Edit (编辑)**。 1. 选择 **Add environment variable (添加环境变量)**。 1. 对于 **Key**（键），输入 `AWS_LAMBDA_EXEC_WRAPPER`。 1. 在**值**中，输入 `/opt/bin/importtime_wrapper`（`/opt/` \$1 .zip 层的文件夹结构）。 1. 选择**保存**。 1. 测试包装脚本。 1. 选择**测试**选项卡。 1. 在**测试事件**下，选择**测试**。您无需创建测试事件 – 默认事件将起作用。 1. 向下滚动到**日志输出**。由于您的包装脚本使用 `-X importtime` 选项启动了 Python 解释器，因此日志会显示每次导入所需的时间。例如： ``` 532 | collections import time: 63 | 63 | _functools import time: 1053 | 3646 | functools import time: 2163 | 7499 | enum import time: 100 | 100 | _sre import time: 446 | 446 | re._constants import time: 691 | 1136 | re._parser import time: 378 | 378 | re._casefix import time: 670 | 2283 | re._compiler import time: 416 | 416 | copyreg ``` # 将 Lambda 运行时 API 用于自定义运行时 AWS Lambda 提供了用于[自定义运行时](runtimes-custom.md)的 HTTP API，接收来自 Lambda 的调用事件并在 Lambda [执行环境](lambda-runtimes.md)中发送回响应数据。本节包含 Lambda 运行时 API 的 API 参考。 **Lambda 托管实例支持并发请求** Lambda 托管实例使用与 Lambda（默认）函数相同的运行时 API。关键区别在于，托管实例可以接受不超过 `AWS_LAMBDA_MAX_CONCURRENCY` 配置限制的并发 `/next` 和 `/response` 请求。这样一来，就可以在单个执行环境中同时处理多个调用。有关托管实例的更多信息，请参阅 [了解 Lambda 托管实例执行环境](lambda-managed-instances-execution-environment.md)。 ![\[执行环境的体系结构图。\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/telemetry-api-concept-diagram.png) 运行时 API 版本 **2018-06-01** 的 OpenAPI 规范在 [runtime-api.zip](samples/runtime-api.zip) 中提供 为了创建 API 请求 URL，运行时会从 `AWS_LAMBDA_RUNTIME_API` 环境变量获取 API 终端节点，添加 API 版本，然后添加所需的资源路径。 **Example 请求** ``` curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next" ``` **Topics** + [ ## 下一个调用 ](#runtimes-api-next) + [ ## 调用响应 ](#runtimes-api-response) + [ ## 初始化错误 ](#runtimes-api-initerror) + [ ## 调用错误 ](#runtimes-api-invokeerror) ## 下一个调用 **路径** – `/runtime/invocation/next` **方法** – **GET** 运行时将此消息发送到 Lambda 以请求调用事件。响应主体包含来自调用的有效负载，该负载是包含来自函数触发器的事件数据的 JSON 文档。响应标头包含有关调用的额外数据。 **响应标头** + `Lambda-Runtime-Aws-Request-Id` – 请求 ID，用于标识触发了函数调用的请求。 例如：`8476a536-e9f4-11e8-9739-2dfe598c3fcd`。 + `Lambda-Runtime-Deadline-Ms` – 函数超时的日期（Unix 时间形式，以毫秒为单位）。 例如：`1542409706888`。 + `Lambda-Runtime-Invoked-Function-Arn` – Lambda 函数的 ARN、版本或在调用中指定的别名。 例如：`arn:aws:lambda:us-east-2:123456789012:function:custom-runtime`。 + `Lambda-Runtime-Trace-Id` – [AWS X-Ray跟踪标头](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html#xray-concepts-tracingheader)。 例如：`Root=1-5bef4de7-ad49b0e87f6ef6c87fc2e700;Parent=9a9197af755a6419;Sampled=1`。 + `Lambda-Runtime-Client-Context` – 对于来自 AWS Mobile SDK 的调用，为有关客户端应用程序和设备的数据。 + `Lambda-Runtime-Cognito-Identity` – 对于来自 AWS Mobile SDK 的调用，为有关 Amazon Cognito 身份提供商的数据。 不要对 `GET` 请求设置超时，因为响应可能会延迟。在 Lambda 引导运行时和运行时返回事件之间，运行时进程可能会冻结几秒钟。 请求 ID 用于跟踪 Lambda 中的调用。使用它可在您发送响应时指定调用。 跟踪标头包含跟踪 ID、父 ID 和采样决策。如果对请求进行采样，则由 Lambda 或某个上游服务对请求进行采样。运行时应设置具有标头的值的 `_X_AMZN_TRACE_ID`。X-Ray 开发工具包会读取此项以获取 ID 并确定是否要跟踪请求。 ## 调用响应 **路径** – `/runtime/invocation/AwsRequestId/response` **方法** – **POST** 在函数运行完成后，运行时会将调用响应发送到 Lambda。对于同步调用，Lambda 会将响应发送到客户端。 **Example 成功请求** ``` REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9 curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "SUCCESS" ``` ## 初始化错误 如果函数返回错误或运行时在初始化期间遇到错误，则运行时将使用此方法向 Lambda 报告错误。 **路径** – `/runtime/init/error` **方法** – **POST** **标头** `Lambda-Runtime-Function-Error-Type` – 运行时遇到的错误类型。必需：否 此标头由字符串值组成。Lambda 接受任何字符串，但建议您使用 格式。例如： + Runtime.NoSuchHandler + Runtime.APIKeyNotFound + Runtime.ConfigInvalid + Runtime.UnknownReason **主体参数** `ErrorRequest` – 有关错误的其他信息。必需：否 此字段是具有以下结构的 JSON 对象： ``` { errorMessage: string (text description of the error), errorType: string, stackTrace: array of strings } ``` 请注意，Lambda 接受任何 `errorType` 值。 以下示例显示了 Lambda 函数错误消息，其中函数无法解析调用中提供的事件数据。 **Example 函数错误** ``` { "errorMessage" : "Error parsing event data.", "errorType" : "InvalidEventDataException", "stackTrace": [ ] } ``` **响应正文参数** + `StatusResponse` – 字符串。状态信息，随 202 个响应代码一起发送。 + `ErrorResponse` – 其他错误信息，随错误响应代码一起发送。ErrorResponse 包含错误类型和错误消息。 **响应代码** + 202 – 已接受 + 403 – 禁止访问 + 500 – 容器错误。不可恢复状态。运行时应立即退出。 **Example 初始化错误请求** ``` ERROR="{\"errorMessage\" : \"Failed to load function.\", \"errorType\" : \"InvalidFunctionException\"}" curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/init/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled" ``` ## 调用错误 如果函数返回错误或运行时遇到错误，则运行时将使用此方法向 Lambda 报告错误。 **路径** – `/runtime/invocation/AwsRequestId/error` **方法** – **POST** **标头** `Lambda-Runtime-Function-Error-Type` – 运行时遇到的错误类型。必需：否 此标头由字符串值组成。Lambda 接受任何字符串，但建议您使用 格式。例如： + Runtime.NoSuchHandler + Runtime.APIKeyNotFound + Runtime.ConfigInvalid + Runtime.UnknownReason **主体参数** `ErrorRequest` – 有关错误的其他信息。必需：否 此字段是具有以下结构的 JSON 对象： ``` { errorMessage: string (text description of the error), errorType: string, stackTrace: array of strings } ``` 请注意，Lambda 接受任何 `errorType` 值。 以下示例显示了 Lambda 函数错误消息，其中函数无法解析调用中提供的事件数据。 **Example 函数错误** ``` { "errorMessage" : "Error parsing event data.", "errorType" : "InvalidEventDataException", "stackTrace": [ ] } ``` **响应正文参数** + `StatusResponse` – 字符串。状态信息，随 202 个响应代码一起发送。 + `ErrorResponse` – 其他错误信息，随错误响应代码一起发送。ErrorResponse 包含错误类型和错误消息。 **响应代码** + 202 – 已接受 + 400 – 错误请求 + 403 – 禁止访问 + 500 – 容器错误。不可恢复状态。运行时应立即退出。 **Example 错误请求** ``` REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9 ERROR="{\"errorMessage\" : \"Error parsing event data.\", \"errorType\" : \"InvalidEventDataException\"}" curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled" ``` # 何时使用 Lambda 仅限操作系统的运行时 Lambda 为 Java、Python、Node.js、.NET 和 Ruby 提供[托管运行时系统](lambda-runtimes.md)。要使用无法作为托管运行时系统使用的编程语言创建 Lambda 函数，请使用仅限操作系统的运行时系统（`provided` 运行时系统系列）。仅限操作系统的运行时系统有三种主要用例： + **本机提前（AOT）编译**：Go、Rust、Swift 和 C\$1\$1 等语言本机编译为可执行的二进制文件，不需要专用语言运行时系统。这些语言只需要一个可以运行编译后二进制文件的操作系统环境。您还可以使用 Lambda 的仅限操作系统的运行时系统来部署使用.NET 本机 AOT 和 Java GraalVM 本机映像编译的二进制文件。 您必须在二进制文件中包含运行时系统接口客户端。运行时系统接口客户端调用 [将 Lambda 运行时 API 用于自定义运行时](runtimes-api.md) 来检索函数调用，然后调用您的函数处理程序。Lambda 为 [Rust](lambda-rust.md)、[Go](golang-package.md#golang-package-mac-linux)、[.NET 本机 AOT](dotnet-native-aot.md)、[Swift](https://github.com/awslabs/swift-aws-lambda-runtime)（实验性）和 [C\$1\$1](https://github.com/awslabs/aws-lambda-cpp)（实验性）提供了运行时系统接口客户端。 您的二进制文件必须在 Linux 环境下编译，且与您计划用于函数的指令集架构（x86\$164 或 arm64）相同。 + **第三方运行时系统**：您可以使用现成的运行时来运行 Lambda 函数，例如适用于 PHP 的 [Bref](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2)。 + **自定义运行时系统**：您可以为 Lambda 未提供托管运行时系统的语言或语言版本（例如 Node.js 19）构建自己的运行时系统。有关更多信息，请参阅 [构建 AWS Lambda 的自定义运行时系统](runtimes-custom.md)。对于仅限操作系统的运行时系统，该用例最不常见。 Lambda 支持以下仅限操作系统的运行时系统： | 名称 | 标识符 | 操作系统 | 弃用日期 | 阻止函数创建 | 阻止函数更新 | | --- | --- | --- | --- | --- | --- | | 仅限操作系统的运行时系统 | `provided.al2023` | Amazon Linux 2023 | 2029 年 6 月 30 日 | 2029 年 7 月 31 日 | 2029 年 8 月 31 日 | | 仅限操作系统的运行时系统 | `provided.al2` | Amazon Linux 2 | 2026 年 7 月 31 日 | 2026 年 8 月 31 日 | Sep 30, 2026 | 与 Amazon Linux 2 相比，Amazon Linux 2023 (`provided.al2023`) 运行时系统具有多项优势，包括较小的部署占用空间和 `glibc` 等更新版本的库。 `provided.al2023` 运行时系统使用 `dnf` 而不是 `yum` 作为程序包管理器，后者是 Amazon Linux 2 中的默认程序包管理器。有关 `provided.al2023` 和 `provided.al2` 之间区别的更多信息，请参阅 AWS 计算博客上的 [AWS Lambda 的 Amazon Linux 2023 运行时系统简介](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/)。 # 构建 AWS Lambda 的自定义运行时系统 您可以采用任何编程语言实施 AWS Lambda 运行时。运行时是一个程序，调用函数时，改程序将运行 Lambda 函数的处理程序方法。该运行时系统可包含在函数的部署包中，也可以分布在[层](chapter-layers.md)中。创建 Lambda 函数时，请选择[仅限操作系统的运行时系统](runtimes-provided.md)（`provided` 运行时系统系列）。 **注意** 创建自定义运行时系统是一个高级用例。如果您想了解有关编译为本机二进制文件或使用第三方现成运行时系统的信息，请参阅 [何时使用 Lambda 仅限操作系统的运行时](runtimes-provided.md)。 有关自定义运行时系统部署过程的演练，请参阅 [教程：构建自定义运行时系统](runtimes-walkthrough.md)。 **Topics** + [ ## 要求 ](#runtimes-custom-build) + [ ## 在自定义运行时中实施响应流 ](#runtimes-custom-response-streaming) + [ ## 为 Lambda 托管实例构建自定义运行时 ](#runtimes-custom-managed-instances) ## 要求 自定义运行时系统必须完成某些初始化和处理任务。运行时系统会运行函数的设置代码、从环境变量读取处理程序名称，以及从 Lambda 运行时系统 API 读取调用事件。运行时会将事件数据传递到函数处理程序，并将来自处理程序的响应发布回 Lambda。 ### 初始化任务 初始化任务将对[函数的每个实例](lambda-runtime-environment.md)运行一次以准备用于处理调用的环境。 + **检索设置** – 读取环境变量以获取有关函数和环境的详细信息。 + `_HANDLER` – 处理程序的位置（来自函数的配置）。标准格式为 `file.method`，其中 `file` 是没有表达式的文件的名称，`method` 是在文件中定义的方法或函数的名称。 + `LAMBDA_TASK_ROOT` – 包含函数代码的目录。 + `AWS_LAMBDA_RUNTIME_API` – 运行时 API 的主机和端口。 有关可用变量的完整列表，请参阅 [定义运行时环境变量](configuration-envvars.md#configuration-envvars-runtime)。 + **初始化函数** – 加载处理程序文件并运行它包含的任何全局或静态代码。函数应该创建静态资源（如开发工具包客户端和数据库连接）一次，然后将它们重复用于多个调用。 + **处理错误** – 如果出现错误，请调用[初始化错误](runtimes-api.md#runtimes-api-initerror) API 并立即退出。 计入收费的执行时间和超时的初始化计数。当执行触发您的函数的新实例的初始化时，您可以在日志和 [AWS X-Ray 跟踪](services-xray.md)中看到初始化时间。 **Example 日志** ``` REPORT RequestId: f8ac1208... Init Duration: 48.26 ms Duration: 237.17 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 26 MB ``` ### 处理任务 其运行时，运行时将使用 [Lambda 运行时界面](runtimes-api.md)来管理传入事件和报告错误。完成初始化任务后，运行时将在一个循环中处理传入事件。在运行时代码中，按顺序执行下面的步骤。 + **获取事件** – 调用[下一个调用](runtimes-api.md#runtimes-api-next) API 来获取下一个事件。响应正文包含事件数据。响应标头包含请求 ID 和其他信息。 + **传播跟踪标头** – 从 API 响应中的 `Lambda-Runtime-Trace-Id` 标头获取 X-Ray 跟踪标头。使用相同的值在本地设置 `_X_AMZN_TRACE_ID` 环境变量。X-Ray SDK 使用此值在服务之间连接追踪数据。 + **创建上下文对象** – 使用来自 API 响应中的环境变量和标头的上下文信息创建一个对象。 + **调用函数处理程序** – 将事件和上下文对象传递到处理程序。 + **处理响应** – 调用[调用响应](runtimes-api.md#runtimes-api-response) API 以发布来自处理程序的响应。 + **处理错误** – 如果出现错误，请调用[调用错误](runtimes-api.md#runtimes-api-invokeerror) API。 + **清理** – 释放未使用的资源，将数据发送到其他服务，或在获取下一个事件之前执行其他任务。 ### Entrypoint 自定义运行时的入口点是一个名为 `bootstrap` 的可执行文件。引导文件可以是运行时，也可以调用创建运行时的另一个文件。如果部署包的根目录不包含名为 `bootstrap` 的文件，则 Lambda 将在函数的层中查找该文件。如果 `bootstrap` 文件不存在或不是可执行文件，则函数将在调用后返回 `Runtime.InvalidEntrypoint` 错误。 以下是一个 `bootstrap` 文件示例，该文件使用捆绑版本的 Node.js 在名为 `runtime.js` 的单独文件中运行 JavaScript 运行时系统。 **Example bootstrap** ``` #!/bin/sh cd $LAMBDA_TASK_ROOT ./node-v11.1.0-linux-x64/bin/node runtime.js ``` ## 在自定义运行时中实施响应流 对于[响应流式处理函数](configuration-response-streaming.md)，`response` 和 `error` 端点的行为略经修改，允许运行时系统将部分响应流式传输到客户端并以区块形式返回负载。有关特定行为的更多信息，请参阅以下内容： + `/runtime/invocation/AwsRequestId/response` – 从运行时系统传播 `Content-Type` 标头以发送到客户端。Lambda 通过 HTTP/1.1 分块传输编码，以区块形式返回响应负载。要将响应流式传输到 Lambda，运行时系统必须： + 将 `Lambda-Runtime-Function-Response-Mode` HTTP 标头设置为 `streaming`。 + 将 `Transfer-Encoding` 标头设置为 `chunked`。 + 编写符合 HTTP/1.1 分块传输编码规范的响应。 + 成功编写响应后，关闭底层连接。 + `/runtime/invocation/AwsRequestId/error` – 运行时系统可以使用此端点向 Lambda 报告函数或运行时系统错误，Lambda 也接受 `Transfer-Encoding` 标头。只能在运行时开始发送调用响应之前调用此端点。 + 使用 `/runtime/invocation/AwsRequestId/response` 中的错误后缀报告中游错误 – 要报告运行时系统开始编写调用响应后发生的错误，运行时系统可以选择附加名为 `Lambda-Runtime-Function-Error-Type` 和 `Lambda-Runtime-Function-Error-Body` 的 HTTP 尾随标头。Lambda 将此视为成功响应，并将运行时系统提供的错误元数据转发给客户端。 **注意** 要附加尾随标头，运行时必须在 HTTP 请求的开头设置 `Trailer` 标头值。这是 HTTP/1.1 分块传输编码规范的要求。 + `Lambda-Runtime-Function-Error-Type` – 运行时系统遇到的错误类型。此标头由字符串值组成。Lambda 接受任何字符串，但建议您使用 ** 格式。例如 `Runtime.APIKeyNotFound`。 + `Lambda-Runtime-Function-Error-Body` – 有关错误的 Base64 编码信息。 ## 为 Lambda 托管实例构建自定义运行时 Lambda 托管实例使用与 Lambda（默认）函数相同的运行时 API。但是，为了支持托管实例的并发执行模型，自定义运行时的实施方式存在关键差异。 ### 并发请求处理 为托管实例构建自定义运行时的主要区别在于支持并发调用。与 Lambda（默认）函数的运行时一次处理一个调用不同，托管实例可以在单个执行环境中同时处理多个调用。 您的自定义运行时必须： + **支持并发的 `/next` 请求**：运行时可以对[下一个调用](runtimes-api.md#runtimes-api-next) API 同时进行多次调用，但最多不超过 `AWS_LAMBDA_MAX_CONCURRENCY` 环境变量指定的限制。 + **处理并发的 `/response` 请求**：多个调用可以同时对[调用响应 API](runtimes-api.md#runtimes-api-response) 进行调用。 + **实现线程安全的请求处理**：确保通过妥善管理共享资源和状态来确保并发调用不会相互干扰。 + **使用唯一的请求 ID**：使用 `Lambda-Runtime-Aws-Request-Id` 标头分别跟踪每次调用，以便将响应与相应的请求进行匹配。 ### 实施模式 托管实例运行时的典型实施模式涉及到创建工作线程或进程来处理并发调用： 1. **读取并发限制**：在初始化时，读取 `AWS_LAMBDA_MAX_CONCURRENCY` 环境变量，以确定要支持的并发调用数量。 1. **创建工作线程池**：初始化等于并发限制的工作线程池（线程、进程或异步任务）。 1. **工作线程处理循环**：每个工作线程独立进行以下操作： + 调用 `/runtime/invocation/next` 以获取调用事件 + 使用事件数据调用函数处理程序 + 将响应发布到 `/runtime/invocation/AwsRequestId/response` + 重复循环 ### 其他注意事项 + **日志记录格式**：托管实例仅支持 JSON 日志格式。确保您的运行时能够遵循 `AWS_LAMBDA_LOG_FORMAT` 环境变量并且仅使用 JSON 格式。有关更多信息，请参阅 [配置 JSON 和纯文本日志格式](monitoring-cloudwatchlogs-logformat.md)。 + **共享资源**：将 `/tmp` 目录之类的共享资源与并发调用结合使用时，一定要谨慎。实施适当的锁定机制以避免竞争条件。 有关 Lambda 托管实例执行环境的更多信息，请参阅[了解 Lambda 托管实例执行环境](lambda-managed-instances-execution-environment.md)。 # 教程：构建自定义运行时系统 在本教程中，您将创建一个具有自定义运行时的 Lambda 函数。首先，您在函数的部署程序包中包含运行时。然后，您将其迁移到一个您独立于函数管理的层。最后，您通过更新运行时层的基于资源的权限策略来将运行时层与全球共享。 ## 先决条件 本教程假设您对 Lambda 基本操作和 Lambda 控制台有一定了解。如果您还没有了解，请按照 [使用控制台创建 Lambda 函数](getting-started.md#getting-started-create-function) 中的说明创建您的第一个 Lambda 函数。 要完成以下步骤，您需要 [AWS CLI 版本 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)。在单独的数据块中列出了命令和预期输出： ``` aws --version ``` 您应看到以下输出： ``` aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2 ``` 对于长命令，使用转义字符 (`\`) 将命令拆分为多行。 在 Linux 和 macOS 中，可使用您首选的 shell 和程序包管理器。 **注意** 在 Windows 中，操作系统的内置终端不支持您经常与 Lambda 一起使用的某些 Bash CLI 命令（例如 `zip`）。[安装 Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10)，获取 Ubuntu 和 Bash 与 Windows 集成的版本。本指南中的示例 CLI 命令使用 Linux 格式。如果您使用的是 Windows CLI，则必须重新格式化包含内联 JSON 文档的命令。 您需要一个 IAM 角色来创建 Lambda 函数。该角色需要权限方可将日志发送到 CloudWatch Logs 并访问您的函数使用的 AWS 服务。如果您没有函数开发的角色，请立即创建一个。 **创建执行角色** 1. 在 IAM 控制台中，打开 [Roles（角色）页面](https://console.aws.amazon.com/iam/home#/roles)。 1. 选择**创建角色**。 1. 创建具有以下属性的角色。 + **Trusted entity**（可信任的实体）– **Lambda**。 + **Permissions**（权限）– **AWSLambdaBasicExecutionRole**。 + **Role name**（角色名称）– **lambda-role**。 **AWSLambdaBasicExecutionRole** 策略具有函数将日志写入 CloudWatch Logs 所需的权限。 ## 创建函数 使用自定义运行时创建 Lambda 函数。此示例包含两个文件：一个运行时系统 `bootstrap` 文件和一个函数处理程序。两个文件都在 Bash 中实施。 1. 为项目创建一个目录，然后切换到该目录。 ``` mkdir runtime-tutorial cd runtime-tutorial ``` 1. 创建名为 `bootstrap` 的新文件。这是自定义运行时系统。 **Example bootstrap** ``` #!/bin/sh set -euo pipefail # Initialization - load function handler source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh" # Processing while true do HEADERS="$(mktemp)" # Get an event. The HTTP request will block until one is received EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next") # Extract request ID by scraping response headers received above REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2) # Run the handler function from the script RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA") # Send the response curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE" done ``` 运行时将从部署程序包加载函数脚本。它使用两个变量来查找脚本。`LAMBDA_TASK_ROOT` 向它告知在何处提取程序包，`_HANDLER` 包含脚本的名称。 在运行时系统加载函数脚本之后，它会使用运行时系统 API 从 Lambda 检索调用事件，并将事件传递到处理程序，然后将响应发送回 Lambda。为了获取请求 ID，运行时会将来自 API 响应的标头保存到临时文件，并从该文件读取 `Lambda-Runtime-Aws-Request-Id` 标头。 **注意** 运行时还具有其他职责（包括错误处理），并向处理程序提供上下文信息。有关详细信息，请参阅[要求](runtimes-custom.md#runtimes-custom-build)。 1. 为函数创建脚本。以下示例脚本将定义一个处理程序函数，该函数将选取事件数据，将该数据记录到 `stderr`，然后返回它。 **Example function.sh** ``` function handler () { EVENT_DATA=$1 echo "$EVENT_DATA" 1>&2; RESPONSE="Echoing request: '$EVENT_DATA'" echo $RESPONSE } ``` `runtime-tutorial` 目录现在应如下所示： ``` runtime-tutorial ├ bootstrap └ function.sh ``` 1. 使文件可执行并将其添加到 .zip 文件存档。这就是部署包。 ``` chmod 755 function.sh bootstrap zip function.zip function.sh bootstrap ``` 1. 创建名为 `bash-runtime` 的函数。对于 `--role`，请输入您的 Lambda [执行角色](lambda-intro-execution-role.md)的 ARN。 ``` aws lambda create-function --function-name bash-runtime \ --zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \ --role arn:aws:iam::123456789012:role/lambda-role ``` 1. 调用函数。 ``` aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out ``` 如果使用 **cli-binary-format** 版本 2，则 AWS CLI 选项是必需的。要将其设为默认设置，请运行 `aws configure set cli-binary-format raw-in-base64-out`。有关更多信息，请参阅*版本 2 的 AWS Command Line Interface 用户指南*中的 [AWS CLI 支持的全局命令行选项](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)。 应出现如下响应： ``` { "StatusCode": 200, "ExecutedVersion": "$LATEST" } ``` 1. 验证响应。 ``` cat response.txt ``` 应出现如下响应： ``` Echoing request: '{"text":"Hello"}' ``` ## 创建层 要将运行时代码与函数代码分开，请创建一个仅包含运行时的层。层可让您单独开发函数的各个依赖项，而且，通过对多个函数使用相同的层，还可以减少存储使用。有关更多信息，请参阅 [使用层管理 Lambda 依赖项](chapter-layers.md)。 1. 创建包含 `bootstrap` 文件的 .zip 文件。 ``` zip runtime.zip bootstrap ``` 1. 使用 [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x) 命令创建层。 ``` aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip ``` 这将创建第一个版本的层。 ## 更新函数 要在函数中使用运行时系统层，请将函数配置为使用该层，并从函数中删除运行时代码。 1. 更新函数配置以拉入到层。 ``` aws lambda update-function-configuration --function-name bash-runtime \ --layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1 ``` 这会将运行时添加到 `/opt` 目录中的函数中。为确保 Lambda 使用层中的运行时系统，您必须从函数的部署包中移除 `boostrap`，如接下来的两个步骤所示。 1. 创建包含函数代码的 .zip 文件。 ``` zip function-only.zip function.sh ``` 1. 更新函数代码以仅包含处理程序脚本。 ``` aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip ``` 1. 调用函数以确认它适用于运行时系统层。 ``` aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out ``` 如果使用 **cli-binary-format** 版本 2，则 AWS CLI 选项是必需的。要将其设为默认设置，请运行 `aws configure set cli-binary-format raw-in-base64-out`。有关更多信息，请参阅*版本 2 的 AWS Command Line Interface 用户指南*中的 [AWS CLI 支持的全局命令行选项](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)。 应出现如下响应： ``` { "StatusCode": 200, "ExecutedVersion": "$LATEST" } ``` 1. 验证响应。 ``` cat response.txt ``` 应出现如下响应： ``` Echoing request: '{"text":"Hello"}' ``` ## 更新运行时 1. 要记录有关执行环境的信息，请更新运行时脚本以输出环境变量。 **Example bootstrap** ``` #!/bin/sh set -euo pipefail # Configure runtime to output environment variables echo "## Environment variables:" env # Load function handler source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh" # Processing while true do HEADERS="$(mktemp)" # Get an event. The HTTP request will block until one is received EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next") # Extract request ID by scraping response headers received above REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2) # Run the handler function from the script RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA") # Send the response curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE" done ``` 1. 创建包含新版本 `bootstrap` 文件的 .zip 文件。 ``` zip runtime.zip bootstrap ``` 1. 创建新版本的 `bash-runtime` 层。 ``` aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip ``` 1. 配置函数以使用新版本的层。 ``` aws lambda update-function-configuration --function-name bash-runtime \ --layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2 ``` ## 共享层 要与其他 AWS 账户 共享层，请在该层的[基于资源的策略](access-control-resource-based.md)中添加跨账户权限语句。执行 [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) 命令，并将账户 ID 指定为 `principal`。在每个语句中，您可以向 [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) 中的单个账户、所有账户或组织授予权限。 以下示例向账户 111122223333 授予访问 `bash-runtime` 层版本 2 的权限。 ``` aws lambda add-layer-version-permission \ --layer-name bash-runtime \ --version-number 2 \ --statement-id xaccount \ --action lambda:GetLayerVersion \ --principal 111122223333 \ --output text ``` 您应该可以看到类似于如下所示的输出内容： ``` {"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"} ``` 权限仅适用于单个层版本。每次创建新的层版本时都需重复此过程。 ## 清理 删除每个版本的层。 ``` aws lambda delete-layer-version --layer-name bash-runtime --version-number 1 aws lambda delete-layer-version --layer-name bash-runtime --version-number 2 ``` 由于函数包含对版本 2 的层的引用，因此该层仍然存在于 Lambda 中。函数可继续工作，但无法再被配置为使用删除的版本。如果您修改了函数的层的列表，则必须指定新版本或忽略已删除的层。 使用 [delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html) 命令删除函数。 ``` aws lambda delete-function --function-name bash-runtime ``` # 开源存储库 AWS Lambda 提供各种开源工具、库和组件，帮助您构建、自定义和优化无服务器应用程序。这些资源包括由 AWS 维护并在 GitHub 上提供的运行时接口客户端、事件库、容器基础映像、开发工具和示例项目。通过利用这些开源存储库，您可以扩展 Lambda 的功能、创建自定义运行时、处理来自各种 AWS 服务的事件，并深入了解函数的性能。本页概述了支持 Lambda 开发的主要开源项目。 ## 运行时接口客户端 Lambda 运行时接口客户端 (RIC) 是一些开源库，用于实现[运行时 API](runtimes-api.md) 并管理函数代码与 Lambda 服务之间的交互。这些客户端负责接收调用事件、传递上下文信息以及报告错误。 Lambda 托管运行时和容器基本映像所使用的运行时接口客户端均作为开源发布。当您构建自定义运行时或扩展现有运行时时，可以使用这些开源库来简化实现。以下开源 GitHub 存储库包含 Lambda RIC 的源代码： + [Node.js 运行时接口客户端](https://github.com/aws/aws-lambda-nodejs-runtime-interface-client) + [Python 运行时接口客户端](https://github.com/aws/aws-lambda-python-runtime-interface-client) + [Java 运行时接口客户端](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-runtime-interface-client) + [Ruby 运行时接口客户端](https://github.com/aws/aws-lambda-ruby-runtime-interface-client) + [.NET 运行时接口客户端](https://github.com/aws/aws-lambda-dotnet) + [Rust 运行时接口客户端](https://github.com/aws/aws-lambda-rust-runtime) + [Go 运行时系统接口客户端](https://github.com/aws/aws-lambda-go) + [Swift 运行时接口客户端](https://github.com/awslabs/swift-aws-lambda-runtime)（实验性） + [C\$1\$1 运行时接口客户端](https://github.com/awslabs/aws-lambda-cpp)（实验性） + [Lambda 基本映像](https://github.com/aws/aws-lambda-base-images) 有关使用这些客户端构建自定义运行时的更多信息，请参阅[构建 AWS Lambda 的自定义运行时系统](runtimes-custom.md)。 ## 事件库 Lambda 事件库提供类型定义和帮助程序实用程序，用于处理来自各种 AWS 服务的事件。这些库可帮助您以类型安全的方式解析和处理事件数据，从而更轻松地处理来自 Amazon S3、Amazon DynamoDB 和 Amazon API Gateway 等服务的事件。 对于编译语言，AWS 提供以下事件库： + [Java 事件库](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-events) + [.NET 事件库](https://github.com/aws/aws-lambda-dotnet/tree/master/Libraries/src) + [Go 事件库](https://github.com/aws/aws-lambda-go/tree/main/events) + [Rust 事件库](https://github.com/awslabs/aws-lambda-rust-runtime) 对于 Node.js、Python 和 Ruby 等解释型语言，事件可以直接解析为 JSON 对象，而无需单独的库。但是，使用 Node.js 和 Python 的开发人员可以利用 powertools for AWS Lambda，它为 AWS 事件提供内置架构，其提供类型提示、数据验证和类似于编译语言库提供的功能。 + [Powertools for TypeScript](https://docs.powertools.aws.dev/lambda/typescript/latest/features/parser/#built-in-schemas) + [Powertools for Python](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parser/#built-in-models) ## 容器基本映像 AWS 提供开源容器基本映像，您可以将其作为构建 Lambda 函数容器映像的起点。这些基本映像包括运行时接口客户端以及在 Lambda 执行环境中运行函数所需的其他组件。 有关可用基本映像及其使用方法的更多信息，请参阅 [AWS Lambda 基本映像](https://github.com/aws/aws-lambda-base-images)存储库和[使用容器映像创建 Lambda 函数](images-create.md)。 ## 开发工具 AWS 提供了其他开源开发工具来帮助您构建和优化 Lambda 函数： ### Powertools for AWS Lambda Powertools for AWS Lambda 通过必要的实用程序简化无服务器开发以防止重复处理，以及用于多记录处理和 Kafka 使用者库的批处理。这些功能可帮助您最大限度地减少代码复杂性和运营开销。 您还可以利用内置事件架构验证、结构化日志记录和跟踪以及参数存储集成，这些功能旨在加速创建生产就绪型 Lambda 函数，同时遵循 AWS 架构完善的最佳实践。 GitHub 存储库： + [Python](https://github.com/aws-powertools/powertools-lambda-python) + [TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript) + [Java](https://github.com/aws-powertools/powertools-lambda-java) + [.NET](https://github.com/aws-powertools/powertools-lambda-dotnet) ### Java 开发工具 + [Java Profiler（实验性）](https://github.com/aws/aws-lambda-java-libs/tree/main/experimental/aws-lambda-java-profiler) - 一款用于分析 Java Lambda 函数的工具。 + [Java 库](https://github.com/aws/aws-lambda-java-libs) - 一个包含用于 Lambda 开发的全面 Java 库和工具的存储库，其中包括 JUnit 测试实用程序和分析工具等关键项目。 + [无服务器 Java 容器](https://github.com/aws/serverless-java-container) - 一个使您能够以最少更改在 Lambda 上运行现有 Java 应用程序的库。 ### .NET 开发工具 [AWS Lambda .NET](https://github.com/aws/aws-lambda-dotnet) 存储库为 Lambda 开发提供 .NET 库和工具，包括用于 .NET CLI 的 AWS Lambda Lambda 工具和用于托管 .NET Core 应用程序的 .NET Core 服务器等关键项目。 ## 示例项目 在 [Serverless Land 存储库](https://serverlessland.com/repos)中探索全面的示例 Lambda 项目和应用程序。这些示例演示了各种 Lambda 使用案例、集成模式和最佳实践，可帮助您开始使用无服务器应用程序