AWS Lambda 架构深入探究

AWS Lambda 是现代云架构中最受欢迎的服务之一，因其能够在完全托管的无服务器环境中运行代码而广受认可。然而，尽管 Lambda 广受欢迎，许多开发者和架构师对它的底层运作机制却知之甚少，常常将其视为“编写能够在云端神奇运行的代码”的简单方法。

本文将探讨 AWS Lambda 背后的架构，详细解析它如何以真正的无服务器方式管理实例、配置资源并处理执行。最终，您将全面了解 Lambda 的内部工作原理，从而能够进行更明智的优化，并在应用程序中更有效地利用它。

Lambda 中的关键概念

在讨论无服务器和云计算时，务必记住服务器确实在后台运行。但是，这些服务器完全由云提供商管理—​​—这意味着它们负责配置、扩展、安全和隔离。这使得开发者可以专注于他们的应用程序，而无需承担管理基础设施的开销。

让我们深入了解 Lambda 架构中您需要了解的一些基本概念。

Lambda 运行时

AWS Lambda 通过使用运行时支持多种编程语言。运行时提供特定于语言的环境，用于管理 Lambda 和函数代码之间调用事件、上下文信息和响应的传递。您可以从 AWS 提供的运行时中进行选择，或者，如果您的应用程序需要不同的环境，您可以灵活地创建自定义运行时。

每个受支持的编程语言的主要版本都带有唯一的运行时标识符，例如 nodejs20.x 或 python3.13，允许您选择最适合您应用程序需求的版本。

工作主机和 MicroVM

Lambda 使用工作主机（EC2 Spot 实例）运行，这些主机管理由 Firecracker（我们接下来会讨论 Firecracker）构建的众多 microVM（承载执行环境的虚拟机）。每个 microVM 都专用于单个函数调用，从而确保执行环境的隔离和安全。此外，该架构的设计使得多个工作器主机可以并发处理同一 Lambda 函数的调用。这种设置不仅提供了高可用性和强大的负载均衡，还增强了服务在不同可用区之间的可扩展性和可靠性；

Worker 的最大租约期限为 14 小时。当 Worker 达到最大租约期限时，将不再路由任何调用，MicroVM 将被正常终止，底层 Worker 实例也将终止。Lambda 会持续监控其队列生命周期内的活动并发出警报。

Firecracker

Firecracker 是驱动所有 Lambda 函数的引擎。它是 Amazon 开发的虚拟化技术，使用 Rust 编写。

Firecracker 是 Lambda 架构中的一个重要组件。它支持为每个函数调用创建轻量级、安全的 microVM。此机制确保根据 Lambda 函数的需求高效地分配和扩展资源；

Firecracker 在 EC2 Spot 实例内管理 MicroVM，而 Lambda 服务则管理所有工作线程

Lambda 调用

AWS Lambda 提供多种调用方法以满足各种应用需求，其架构旨在高效支持每种方法。目前为止，我们讨论的关键概念根据所使用的调用方法以不同的方式运作，并以不同的方式进行交互，从而优化性能和可扩展性。

在深入了解 Lambda 环境中如何处理每个调用之前，让我们先回顾一下可用的调用类型。

• 同步调用：通常用于 API 等交互式工作负载。例如，API 网关触发 Lambda 函数，该函数随后查询数据库并直接响应。此方法即时响应，适用于实时数据处理。
• 异步调用：用于处理上传到 S3 的数据等场景。事件触发由 AWS Lambda 管理的内部队列，然后该队列异步处理该函数。此方法非常适合不需要立即响应触发事件的工作负载。
• 事件源映射：对于 Kinesis 或 DynamoDB Streams 等流数据服务尤其有用。Lambda 会轮询这些源，并根据传入的数据调用相应的函数。此方法能够高效地进行批处理，对于处理连续数据流的应用程序而言至关重要。

Lambda 通用架构

Lambda 函数的调用方式多种多样，虽然调用方法会根据触发它的服务而有所不同，但其核心内部架构保持一致。然而，Lambda 与同步 (Sync) 和异步 (Async) 调用的交互方式有所不同。

每个 Lambda 调用的核心都是前端服务，它是 Lambda 函数的入口点。当 Lambda 函数被调用时，前端服务会管理请求并将其定向到相应的数据平面服务，从而启动执行流程。

Lambda 函数的调用主要有两种方式：同步或异步。

• 同步调用：在同步调用中，前端服务会将请求直接路由到 MicroVM 进行立即处理。
• 异步调用：对于异步调用，前端服务会将请求放入 Lambda 内部的队列中。这种内部排队机制可以有效地将排队事件分发到可用的 MicroVM 上。队列通过确保事件的顺畅分发，使 Lambda 能够保持负载均衡并优化性能，尤其是在高流量时段或需求高峰期。

下一步是深入研究 Lambda 内部架构中同步调用与异步调用的执行情况。首先，让我们来了解一下事件源映射组件的架构，它是 Lambda 功能的重要组成部分。

事件源映射架构

在 Lambda 的架构中，事件源映射发挥着至关重要的作用，它使 Lambda 能够轮询来自特定事件源的新记录或消息，然后调用目标 Lambda 函数。此过程由 Lambda 服务内部管理，该服务会批量读取传入消息，并将其作为单个事件负载传递给您的函数。批处理支持高吞吐量消息处理，每个批次最多可处理 10,000 条消息。

Lambda 还提供了“批处理窗口”功能，允许您指定 Lambda 在调用函数之前等待收集记录的最长时间（以秒为单位）。此功能可帮助您控制 Lambda 如何根据时间、数量或负载大小聚合消息，从而优化函数调用以满足应用程序的性能需求。

基于这些功能，我们可以设想如下的事件源映射架构：

AWS Lambda 事件源映射架构

• 轮询消费者：轮询消费者负责根据每个 Lambda 函数的配置，从支持的来源（例如 SQS、DynamoDB Streams 或 Kinesis）持续轮询记录。
• 聚合器：聚合器根据 Lambda 触发器设置中定义的条件收集记录，这些条件可以包括消息大小、记录数量或批处理窗口时间。当达到这些阈值时，聚合器将准备批处理以供处理。
• 调用器进程：达到聚合阈值后，调用器进程将启动对前端服务的同步调用。然后，该服务层调用在 MicroVM 内部执行的 Lambda 函数代码，以确保高效、独立的处理。

有了这个基础，我们现在可以深入研究 Lambda 内部架构中同步执行与异步执行的内部工作原理。

Lambda 中的同步执行

Invoke API 可以通过两种模式调用：事件模式和请求-响应模式。

• 事件模式将负载加入队列以进行异步调用。
• 请求-响应模式使用提供的负载同步调用函数并立即返回响应。

在这两种情况下，函数执行始终在 Lambda 执行环境中进行（我们稍后会介绍），但负载采用不同的路径。

当 Lambda 收到请求-响应调用时，它会直接传递给调用服务。如果调用服务不可用，调用者可以暂时将负载加入客户端队列，以一定次数重试调用。

如果被调用的服务收到了负载，它会尝试为请求识别可用的执行环境，并将负载传递给该执行环境以完成调用。如果不存在现有或合适的执行环境，则会根据请求动态创建一个。在传输过程中，发送到调用服务的调用负载将受到 TLS 的保护。

Lambda 服务内部的流量（从负载均衡器向下）会经过 Lambda 服务所拥有的、位于请求发送至的 AWS 区域内的独立内部虚拟私有云 (VPC)。

步骤 1：工作器管理器 (Worker Manager) 与 Placement Service 通信，后者负责将工作负载放置到指定主机的某个位置（它正在配置沙盒），并将其返回给工作器管理器 (Worker Manager)。

Lambda 函数在沙盒中运行，沙盒提供了最小的 Linux 用户空间、一些常用库和实用程序。它会在 EC2 实例上创建执行环境（工作器）。

步骤 2：然后，工作器管理器可以调用 Init 函数，通过从 S3/ECR 镜像下载 Lambda 包并设置 Lambda 运行时来初始化函数以供执行。

步骤 3：前端工作器现在可以调用 Invoke 函数。

Lambda 中的异步执行

事件调用模式的有效负载始终在调用前排队等待处理。所有负载均在 Amazon SQS 队列中排队等待处理。排队事件在传输过程中始终使用 TLS 进行保护，并在静态时使用服务器端加密 (SSE) 进行加密。

Lambda 使用的 Amazon SQS 队列由 Lambda 服务管理，客户无法看到这些队列。

排队事件可以存储在共享队列中，但可能会根据客户无法直接控制的一系列因素（例如，调用速率、事件大小等）迁移或分配到专用队列。

Lambda 的轮询器队列会批量检索排队事件。轮询器队列是一组 Amazon EC2 实例，其目的是处理尚未处理的排队事件调用。当轮询器队列检索到需要处理的排队事件时，它会将其传递给调用服务，就像客户在请求-响应模式调用中所做的那样。

如果调用无法执行，轮询器队列会将事件临时存储在主机的内存中，直到能够成功完成执行，或超过运行重试次数。轮询器队列本身不会将任何负载数据写入磁盘。

如果事件在所有处理尝试中均失败，Lambda 会将其丢弃。死信队列 (DLQ) 功能允许将异步调用中未处理的事件发送到客户定义的 Amazon SQS 队列或 Amazon SNS 主题。

步骤 1：应用程序负载均衡器将调用转发到可用的前端，前端会将事件放入内部队列 (SQS)。

步骤 2：一组轮询器被分配到此内部队列，负责轮询事件并将事件同步移动到前端。事件被放入前端后，将遵循我们之前展示的同步调用模式。

Lambda 运行时

我们已经介绍了如何调用 AWS Lambda 以及它如何与这些调用方法交互，从而深入了解了 Lambda 的架构及其处理不同调用类型的能力。现在，让我们深入了解 Lambda 的 MicroVM，以了解 Lambda 如何执行代码并管理用户请求和事件。

Lambda 通过使用运行时支持多种编程语言。运行时是一种特定于语言的环境，用于促进 Lambda 和函数代码之间调用事件、上下文信息和响应的通信。您可以从 AWS 提供的运行时中进行选择，也可以创建自定义运行时以满足您应用程序的独特需求。

每个受支持的编程语言的主要版本都有一个唯一的运行时标识符，例如 nodejs20.x 或 python3.13。此外，如果您将函数定义为容器镜像，则可以在创建容器镜像时同时选择运行时和 Linux 发行版。

Lambda 运行时 API

AWS Lambda 为自定义运行时提供了一个 HTTP API，用于接收来自 Lambda 服务的调用事件，并在 Lambda 执行环境（在 MicroVM 上运行）内发回响应数据。

要创建 API 请求 URL，运行时需要从 AWS_LAMBDA_RUNTIME_API 环境变量获取 API 端点，添加 API 版本，并添加所需的资源路径。

Lambda 执行环境

现在我们已经了解了 Lambda 如何与执行环境中的 Runtime API 交互，后者负责处理函数调用并向 Lambda 报告服务之后，是时候了解此执行环境的生命周期了。

当 Lambda 调用您的函数时，它会在执行环境中运行。执行环境是一个安全、隔离的运行时环境，用于管理函数执行所需的资源。此环境还支持函数运行时及其相关扩展程序的生命周期。

• 运行时与扩展程序通信：在执行环境中，函数的运行时使用运行时 API 与 Lambda 通信。您添加到函数中的任何外部扩展程序都通过扩展程序 API 与 Lambda 交互，并且这些扩展程序可以使用遥测 API 接收日志消息和遥测数据。
• 配置和资源管理：创建 Lambda 函数时，您可以定义内存分配和最大执行时间等配置。Lambda 使用此配置来设置执行环境，确保资源按指定方式分配。
• 环境共享：函数的运行时和任何外部扩展程序在执行环境中作为单独的进程运行，但它们共享权限、资源、凭证和环境变量，从而在保持隔离的同时实现顺畅的交互。

Lambda 通过尽可能地复用执行环境来优化性能。如果先前调用的环境可用，Lambda 会重用该环境，从而减少创建新环境的开销。否则，Lambda 将根据需要初始化一个新的执行环境。

执行环境生命周期事件

每个阶段都以 Lambda 发送给运行时和所有已注册扩展程序的事件开始。运行时和每个扩展程序通过发送 Next API 请求来指示完成。当运行时和每个扩展程序完成且没有待处理事件时，Lambda 会冻结执行环境。

AWS Lambda 执行环境的生命周期可以分为几个关键阶段，每个阶段在函数的准备、运行和管理中都发挥着至关重要的作用。了解这些阶段可以帮助您优化函数性能并做出明智的 Lambda 配置决策。

初始化阶段

在初始化阶段，Lambda 执行三个任务：

• 启动所有扩展程序（扩展初始化）
• 引导运行时（运行时初始化）
• 运行函数的静态代码（函数初始化）
• 运行所有 beforeCheckpoint 运行时钩子（仅限 Lambda SnapStart ~ Java）

当运行时和所有扩展程序通过发送 Next API 请求发出信号表明它们已准备就绪时，初始化阶段结束。初始化阶段限制为 10 秒。如果所有三个任务未在 10 秒内完成，Lambda 会在首次函数调用时使用配置的函数超时时间重试 Init 阶段。

10 秒超时时间不适用于使用预置并发或 SnapStart 的函数。对于预置并发和 SnapStart 函数，初始化代码最多可以运行 15 分钟。时间限制为 130 秒或配置的函数超时时间（最长 900 秒），以较高者为准。

使用预置并发时，Lambda 会在您配置函数的程序控制 (PC) 设置时初始化执行环境。Lambda 还会确保已初始化的执行环境在调用之前始终可用。您可能会看到函数的调用阶段和初始化阶段之间存在间隙。根据函数的运行时和内存配置，您还可能会在已初始化的执行环境上的首次调用中看到不同的延迟。

对于使用按需并发的函数，Lambda 偶尔可能会在调用请求之前初始化执行环境。发生这种情况时，您可能还会注意到函数的初始化和调用阶段之间存在时间间隔。我们建议您不要依赖此行为。

Init 阶段的故障

如果函数在 Init 阶段崩溃或超时，Lambda 会在 INIT_REPORT 日志中发出错误信息。

调用阶段

当 Lambda 函数响应 Next API 请求而被调用时，Lambda 会向运行时和每个扩展程序发送一个调用事件。

函数的超时设置限制了整个调用阶段的持续时间。例如，如果您将函数超时设置为 360 秒，则该函数和所有扩展程序都需要在 360 秒内完成。请注意，没有独立的调用后阶段。调用后阶段的持续时间是所有调用时间（运行时 + 扩展程序）的总和，并且在函数和所有扩展程序执行完成后才会计算。

调用阶段在运行时和所有扩展程序通过发送 Next API 请求表示其已完成之后结束。

调用阶段中的故障

如果 Lambda 函数在调用阶段崩溃或超时，Lambda 会重置执行环境。

• 第一阶段是 INIT 阶段，此阶段运行无误。
• 第二阶段是 INVOKE 阶段，此阶段运行无误。
• 假设您的函数在某个时刻遇到调用失败（例如函数超时或运行时错误）。标记为 INVOKE WITH ERROR 的第三阶段演示了此场景。发生这种情况时，Lambda 服务将执行重置。重置的行为类似于 Shutdown 事件。首先，Lambda 关闭运行时，然后向每个已注册的外部扩展程序发送 Shutdown 事件。该事件包含关闭的原因。如果此环境用于新的调用，Lambda 会在下一次调用时重新初始化扩展程序和运行时。
• 请注意，Lambda 重置不会在下一个 init 阶段之前清除 /tmp 目录内容。此行为与常规关闭阶段一致。
• 第四阶段表示调用失败后立即进入的 INVOKE 阶段。此时，Lambda 通过重新运行 INIT 阶段来再次初始化环境。这称为抑制初始化。当发生抑制初始化时，Lambda 不会在 CloudWatch Logs 中明确报告额外的 INIT 阶段。相反，您可能会注意到 REPORT 行中的持续时间包含额外的 INIT 持续时间 + INVOKE 持续时间。
• 第五个阶段代表 SHUTDOWN 阶段，该阶段运行时不会出现错误。

关闭阶段

当 Lambda 即将关闭运行时时，它会向每个已注册的外部扩展程序发送一个关闭事件。扩展程序可以利用这段时间执行最终的清理任务。关闭事件是对 Next API 请求的响应。

持续时间：整个关闭阶段的上限为 2 秒。如果运行时或任何扩展程序没有响应，Lambda 会通过信号 (SIGKILL) 终止它。

在函数和所有扩展程序完成后，Lambda 会维护执行环境一段时间，以备下次函数调用。但是，Lambda 每隔几小时就会终止一次执行环境，以便进行运行时更新和维护——即使对于连续调用的函数也是如此。您不应假设执行环境会无限期地持续存在。

当再次调用该函数时，Lambda 会解冻环境以供重用。重用执行环境具有以下含义：

在函数处理程序方法之外声明的对象将保持初始化状态，从而在再次调用该函数时提供额外的优化。例如，如果您的 Lambda 函数建立了数据库连接，则后续调用将使用原始连接，而不是重新建立连接。我们建议您在代码中添加逻辑，在创建新连接之前检查连接是否存在。

每个执行环境在 /tmp 目录中提供 512 MB 到 10,240 MB（以 1 MB 为增量）的磁盘空间。当执行环境冻结时，目录内容会保留，从而提供可用于多次调用的临时缓存。您可以添加额外的代码来检查缓存中是否包含您存储的数据。

如果 Lambda 重用执行环境，则由您的 Lambda 函数启动的、在函数结束时未完成的后台进程或回调将会恢复。请确保代码中的所有后台进程或回调在代码退出之前都已完成。

编写 Lambda 函数代码时，请将执行环境视为无状态，假设它仅存在于一次调用中。Lambda 每隔几小时就会终止一次执行环境，以便进行运行时更新和维护 - 即使对于连续调用的函数也是如此。在函数启动时初始化任何所需状态（例如，从 Amazon DynamoDB 表中获取购物车数据）。退出之前，将永久性数据更改提交到持久存储，例如 Amazon Simple Storage Service (Amazon S3)、DynamoDB 或 Amazon Simple Queue Service (Amazon SQS)。避免依赖现有数据结构、临时文件或跨调用的状态，例如计数器或聚合。这可确保您的函数独立处理每次调用。

执行环境中的存储和状态

执行环境永远不会在不同的函数版本或客户之间重复使用，但在同一函数版本的调用之间可以重复使用单个环境。这意味着数据和状态可以在调用之间保留。数据和/或状态可能会在被销毁之前持续保留数小时，这是正常执行环境生命周期管理的一部分。

出于性能原因，函数可以利用此行为来提高效率，方法是在调用之间保留和重用本地缓存或长连接。在执行环境内部，这些多次调用由单个进程处理，因此，如果调用发生在可重用的执行环境中，任何进程范围的状态（例如 Java 中的静态状态）都可以供将来的调用重用。

每个 Lambda 执行环境还包含一个可写入的文件系统，位于 /tmp。此存储无法跨执行环境访问或共享。与进程状态一样，写入 /tmp 的文件将在整个执行环境的生命周期内保留。这使得昂贵的传输操作（例如下载机器学习 (ML) 模型）的成本可以分摊到多次调用中。如果函数不想在调用之间保留数据，则应该不写入 /tmp，或者在调用之间从 /tmp 中删除其文件。/tmp 目录是静态加密的。

Lambda 控制计划与安全性

当 Lambda 代表您运行函数时，它会管理运行代码所需的底层系统的预置和配置。这使您的开发人员能够专注于业务逻辑和代码编写，而无需管理底层系统。

Lambda 服务分为控制平面和数据平面。每个平面在服务中都有不同的用途。控制平面提供管理 API（例如 CreateFunction、UpdateFunctionCode、PublishLayerVersion 等），并管理与所有 AWS 服务的集成。与 Lambda 控制平面的通信在传输过程中受到 TLS 保护。存储在 Lambda 控制平面中的客户内容使用 AWS KMS 密钥进行静态加密，这些密钥旨在保护内容免遭未经授权的披露或篡改。

数据平面是 Lambda 的调用 API，用于提示 Lambda 函数的调用。调用 Lambda 函数时，数据平面会在 AWS Lambda Worker（或简称为 Worker，一种 Amazon EC2 实例）上为该函数版本分配一个执行环境，或者选择已为该函数版本设置的现有执行环境，然后使用该执行环境完成调用。

执行角色

每个 Lambda 函数还必须配置一个执行角色，这是一个 IAM 角色，Lambda 服务在执行与该函数相关的控制平面和数据平面操作时会代入该角色。Lambda 服务会代入此角色来获取临时安全凭证，这些凭证随后可在函数调用期间作为环境变量使用。出于性能方面的考虑，Lambda 服务会缓存这些凭证，并可能在使用相同执行角色的不同执行环境中重复使用它们。

为了确保遵循最小特权原则，Lambda 建议每个函数都拥有其独特的角色，并为其配置所需的最小权限集。

Lambda 服务还可以承担执行角色，执行某些控制平面操作，例如为 VPC 函数创建和配置弹性网络接口 (ENI)、向 Amazon CloudWatch Application Insights 发送日志、向 AWS X-Ray 发送跟踪记录，或其他与调用无关的操作。

AWS Lambda 中的部署

AWS Lambda 为函数提供两种主要的部署方法，每种方法都适用于不同的应用程序规模和需求。

部署选项：

• ZIP 部署：此方法适用于依赖关系有限的小型函数。ZIP 部署简单易行，但受较小规模的限制，因此不太适合规模更大的应用程序。
• 容器镜像部署：对于大型应用程序，Lambda 支持高达 10 GB 的容器镜像。这种更大的容量非常适合需要更大库或更强大依赖关系的应用程序。

AWS Lambda 具有以下几个特性，可以优化部署性能：

1) Firecracker 中的调用约束

Lambda 使用 Firecracker 创建 MicroVM，每个 MicroVM 每次处理一个调用。这种模型意味着单个实例无法同时处理多个请求，这对于高吞吐量应用程序来说是一个考量因素。

2) 缓存作为性能增强

Lambda 采用三层缓存系统来提升函数性能：

• L1 缓存（工作器主机上的本地缓存）：此缓存直接位于工作器主机上，允许快速访问常用数据，这对于加快函数调用速度至关重要。
• L2 缓存（工作器主机和客户共享）：此共享缓存保存不同 Lambda 函数和客户之间的通用数据，通过减少冗余数据获取来优化性能。
• L3 缓存（由 AWS 管理的 S3 存储桶）：L3 缓存用于访问频率较低的数据，可在 S3 存储桶中提供高效的长期存储，从而减少检索时间。

3) 优化容器部署

为了最大限度地发挥缓存优势，尤其是在容器镜像的情况下，建议策略性地构建容器层。将操作系统和运行时等稳定元素放置在底层，将频繁更改的业务逻辑放置在上层。这种设置可以更高效地缓存静态组件，从而加快 Lambda 函数的加载过程。

结论

AWS Lambda 是一项复杂的服务，它抽象了许多底层复杂性和基础设施管理。然而，深入了解其内部工作原理至关重要。通过了解幕后运作，您可以更好地理解 AWS 如何管理扩展、资源分配和函数执行，以确保流畅的性能。

在本文中，我们探讨了 Lambda 的调用方法、核心架构以及执行环境的生命周期。这些知识将帮助您做出更明智的选择并优化您的 Lambda 函数，从而更好地控制它们在应用程序中的行为、效率和可扩展性。