选择一个 AWS 无服务器服务

Step Functions 支持用于在一种状态下分配数据并在后续状态中使用数据的变量，以及用于高级数据操作（包括日期格式和数学运算）的 Jsonata 转换。这些功能简化了各州之间的数据共享，减少了对中间处理步骤的需求。对于大规模批处理，分布式地图对来自 Amazon S3、Athena 或 JSON 数据集的数百万个项目并行运行相同的流程，无需预置计算基础设施。

了解应用程序的运行模式是选择无服务器服务的最重要因素。不同的工作负载模式需要不同的服务组合。无服务器数据处理在很大程度上属于以下模式：

每种模式使用不同的无服务器服务组合。有关每种模式的详细示例和推荐的服务组合，请参阅 “选择” 部分。

无服务器计算服务在允许单次执行运行的时间和处理并发性的方式方面存在显著差异。与传统服务器不同，Lambda 事件函数不能持续运行。当某个事件触发某个函数时，这称为调用。Lambda 事件函数的持续时间限制为 15 分钟，但平均而言，在所有 AWS 客户中，大多数调用持续时间不到一秒钟。

Short-lived，事件驱动的调用最好由 Lambda 处理，它支持最长 15 分钟的执行时间，并且可以根据每个请求自动扩展到数千次并发调用。Lambda 服务仅在需要时运行您的函数实例，并自动从每天零个请求扩展到每秒数千个请求。您只需为实际使用的计算时间付费，因此当您的代码未运行时不收取任何费用。Lambda 的每毫秒计费可以降低短时工作负载的成本。

有许多类型的调用事件可以触发短暂的函数。一些示例包括来自 API Gateway 的 HTTP 请求、由 EventBridge 规则管理的时间表、来自物联网设备的消息或文件已上传到 Amazon S3 存储桶的通知。

有状态的交互式会话，例如 AI 编码沙箱、交互式笔记本和多租户 CI 环境，需要隔离的环境在用户交互中保持状态。Lambda MicroVM 与事件函数的计算形式不同：它们使用 Dockerfile-based 编程模型，为每个会话（不是每个请求）分配一个环境，并按基准加突发模型而不是每毫秒计费。MicroVM 具有完整的操作系统功能、基于快照的快速启动、长达 8 小时的使用寿命以及 suspend/resume 减少闲置成本，提供 VM-level 隔离。

Long-running 或稳态进程，例如批处理作业、持久 WebSocket 连接或需要超过 15 分钟的连续处理的服务，最好由 Fargate 提供服务，它可以无限期运行。有关 Fargate 和 Lambda 如何以不同方式进行扩展的详细信息，请参阅扩展模型和延迟选项卡。Fargate 为超过 Lambda 超时或计算限制的工作负载提供一致的资源分配。此外，Lambda 耐用函数支持多步、长时间运行的执行，在多次调用中保持状态。每个单独的调用仍然遵守 15 分钟的限制。耐用功能会自动检查进度并从中断的地方继续，因此总工作流程持续时间可以远远超过 15 分钟，无需进行 Fargate 或外部编排。

考虑工作负载的平均和最大执行时间。偶尔超过 15 分钟的 Lambda 函数会不可预测地失败，需要重新设计架构。您的应用程序架构和需求决定了如何调用函数。例如，批处理模式与按需数据处理有不同的要求。Fargate 适用于主要处理批量数据处理的微服务。Lambda 更易于部署和维护，便于按需处理。

无服务器开发的关键优势之一是，您只需为消耗的资源付费。无服务器技术是按使用量付费的，这意味着您可以随着应用程序需求的变化向上和向下扩展，而无需为空闲容量付费。但是，不同的 AWS 无服务器服务使用不同的定价模式，有利于不同的使用模式。

Pay-per-use 定价（Lambda、Step Functions Express EventBridge）根据实际调用和持续时间收费，空闲时不收取任何费用。对于 Lambda，根据您的函数请求数量和代码运行所需的持续时间向您收费。代码不运行时不会产生任何费用。该模型适用于流量可能降至零的不可预测或高峰工作负载，也适用于需求不确定的早期应用程序。

Capacity-based 预留计算或吞吐容量的定价（Fargate、Amazon Aurora 无服务器、DynamoDB 预置模式）费用。虽然这可能会在低流量时期产生成本，但在持续的、可预测的规模下，如果每个请求的定价将超过等效的预留容量，则会变得更具成本效益。例如，DynamoDB 预置模式允许您根据需要调整表的吞吐容量，这对于流量模式一致的工作负载来说可能更经济。

混合定价（DynamoDB 按需定价、API Gateway）提供按请求定价，无需预先承诺即可线性扩展。这无需预测容量即可提供成本可预测性，但与预置的替代方案相比，在吞吐量非常高的条件下可能会变得昂贵。

在微虚拟机运行期间，对配置的基准资源收取基准加突发定价（Lambda microVMS）费用，可以在活动高峰期突增至基准的4倍。暂停的微虚拟机在保持状态的同时降低了成本。该模型适合具有可变活动和空闲周期的交互式工作负载。

对每日、每周和季节性周期的预期流量模式进行建模。峰值平均比率较高的工作负载有利于按使用量定价。 Steady-state 工作负载可能会受益于基于容量的定价。您也可以组合使用：例如，Lambda 为变量计算提供按使用量付费，以及用于可预测数据访问模式的 DynamoDB 预置模式。

传统的 Web 应用程序框架将路由、数据访问、连接池和集成捆绑到一个代码库中，您可以将其作为一个单元进行部署和维护。设置、配置和维护框架、运行时环境和基础架构会减慢功能交付和错误修复的速度。随着应用程序的增长和对更多外部系统的依赖，这种复杂性增加了新开发人员的开发时间，使跟踪错误的来源变得更加困难，并延迟了新功能的交付。

无服务器服务存在于一系列运营责任上，可以减少或消除这种开销。与其在一个包中管理所有内容，不如组成连接松散的服务，其中每个服务都可以在尽可能少的依赖关系的情况下很好地完成一件事。

最低限度的管理：Lambda、API Gateway、DynamoDB、亚马逊 SQS、亚马逊 SNS 和 Step Functions 无需预置服务器、修补或容量规划。 EventBridge您无需设置连接池、配置运行时环境或管理扩展基础设施。您可以完全专注于编写或生成解决业务问题的代码。

容器管理：Fargate 需要构建和维护容器镜像、配置任务定义和管理部署管道。你不管理底层基础设施，但你拥有容器生命周期。该模型适合需要自定义运行时或拥有现有容器化工作负载的团队，他们希望在不管理集群的情况下运行。

基础设施即代码的复杂性：通过速记语法和本地测试， AWS Serverless Application Model 最大限度地降低无服务器架构的 IaC 复杂性。 AWS Cloud Development Kit (AWS CDK) 并以更陡峭的学习曲线和更多的代码需要维护为代价，为复杂的应用程序Terraform提供更多功能。

考虑一下您团队的现有技能、要管理的服务数量以及组织的运营标准。如果您的团队在维护基础架构上花费的时间比构建功能的时间多，那么向最低限度的管理端转移可以腾出资源用于更高价值的工作。

服务的扩展方式直接影响应用程序在负载下的响应能力。在无服务器架构中，扩展是自动进行的，但是不同的服务使用不同的机制来影响延迟和吞吐量。

Per-request 扩展 (Lambda) 为每个并发请求创建一个新的执行环境。Lambda 在执行环境中调用您的函数，该环境提供了一个安全和隔离的运行时环境，用于管理运行该函数所需的进程和资源。这可以对流量峰值提供近乎即时的响应，在几秒钟内从零次并发执行扩展到数千次。

但是，按请求扩展会引入冷启动，即在 Lambda 创建新的执行环境时发生的初始化延迟。冷启动时间的最大贡献是 Lambda 初始化函数所花费的时间，包括加载函数代码、启动运行时和初始化函数代码。对于 Java、Python 和.NET 工作负载，通过拍摄初始化执行环境的快照并将其缓存以实现低延迟访问，Lambda SnapStart 可以将启动性能提高多达 10 倍，而无需额外付费。对于其他运行时，您可以使用预置并发缓解冷启动，但需要额外付费。

Task-level 扩展 (Fargate) 根据 CPU 利用率、内存使用率或请求数等指标添加或删除容器实例。扩展可在几秒到几分钟内添加新任务，并避免对现有任务处理的请求进行冷启动。任务一旦运行，它将在整个生命周期内保持温暖，从而为其处理的所有请求提供稳定的延迟。

Throughput-based 扩展（DynamoDB、Kinesis）根据需求调整 read/write 容量或分片数量。DynamoDB 按需模式可即时扩展以适应工作负载的流量模式。预置模式需要自动扩展配置，但以较低的每请求成本提供可预测的吞吐量。借助无服务器架构和 DynamoDB，无需连接池即可快速连接和扩展数据库。相反，您可以根据需要调整表格的吞吐量。

对于严格的延迟要求（P99 以下 100 毫秒），请仔细评估冷启动行为。具有预置并发性的 Lambda 或 SnapStart带有预热任务的 Fargate 为 API 工作负载提供可预测的延迟。对于延迟不太重要的数据处理工作负载，标准的 Lambda 扩展通常就足够了。

无服务器架构由通过事件进行通信的多个服务组成。一个事件代表状态的变化或更新。例如，放入购物车的物品、上传到存储系统的文件或准备发货的订单。服务之间原生集成的深度会影响您的构建速度以及需要编写多少自定义代码。

深度原生集成：Lambda 集成了 200 多种 AWS 服务作为事件源。某些服务可以直接触发 Lambda 函数。例如，将图像添加到 Amazon S3 存储桶时，可以触发 Lambda 来调整其大小。某些服务无法直接调用 Lambda，但您可以使用事件源映射，这是一种从事件源读取并调用 Lambda 函数的轮询机制。您可以使用事件源映射来处理来自以下流或队列的项目：DynamoDB Streams、亚马逊 Kinesis、亚马逊 MQ、亚马逊 MSK、自我管理和 Amazon SQS。Apache Kafka

事件路由灵活性： EventBridge 提供基于内容的路由和过滤规则，允许单个事件总线根据事件内容将事件路由到不同的目标。Amazon SNS 提供基于主题的扇出功能，可同时向多个订阅者传送消息。Amazon SQS 提供点对点缓冲，消费者可以在其中主动轮询队列中的消息。常见组合包括将事件 EventBridge 或 Amazon SNS 事件路由到 Amazon SQS 队列作为下游消费者的缓冲区，使用 EventBridge 管道从流或队列中提取事件，以及将事件路由到 Kinesis 进行分析。

API 集成模式：API 网关提供两种集成方法。代理集成直接将所有请求信息传递给 Lambda 函数进行处理，该函数更易于配置。 Non-proxy （自定义）集成可以在数据到达您的函数之前和输出返回给客户端之前对其进行转换，这对于遗留代码迁移或使函数代码专注于业务逻辑很有用。REST API 提供最广泛的功能集，包括缓存、请求验证和 WAF。HTTP API 提供最低的延迟和成本。 AWS AppSync 提供实时订阅和 GraphQL。Lambda 函数 URL 提供最简单的单函数 HTTPS 终端节点，无需 API 网关。对于服务器需要向客户端推送数据的双向通信，API Gateway WebSocket API 提供适用于聊天、实时仪表板和多人游戏的持久连接。

由于事件驱动系统的组件之间的耦合松散，您的计算函数无法识别架构中的其他活动。您可以独立扩展组件，一项服务可以在不影响其他服务的情况下发生故障，并且可以灵活地路由和缓冲事件，并为审计提供日志。

您对无服务器服务的选择会影响您的架构在不同环境中的可移植性。无服务器应用程序通常包含多个 AWS 服务，这些服务与在 Lambda 函数中运行的自定义代码集成在一起。虽然 Lambda 可以与大多数 AWS 服务集成，但您应该考虑在深度平台集成和在其他环境中运行工作负载的能力之间进行权衡。

AWS 原生服务（Lambda、步进函数 EventBridge、DynamoDB）提供最深入的集成和最低的运营开销。您可以通过 AWS SDK 使用这些服务中的任何一项，而无需安装应用程序或配置服务器。熟练通过 Lambda 函数中的代码使用这些服务，是生成精心设计的无服务器应用程序的重要步骤。但是，这些服务会与 AWS特定的 API 和事件格式建立耦合，这意味着迁移到另一个云需要大量重构。

Standards-based 服务（带容器的 Fargate、带Docker容器的亚马逊 MQ AMQP、带有 Amazon MSKApache Kafka）在开放协议或开源技术上运行。如果您需要未提供的自定义运行时 AWS，则可以在 Fargate 上创建和部署自定义容器镜像。亚马逊 MSK 为拥有现有 Kafka 专业知识的团队提供Apache Kafka兼容性。这些选项使工作负载的可移植性更加可行，但代价是操作复杂性更高，与其他 AWS 服务的集成不太紧密。

部署框架： AWS Serverless Application Model 并 AWS Cloud Development Kit (AWS CDK) 生成 CloudFormation 模板，而且是 AWS唯一的。 AWS Serverless Application Model 使用速记语法 CloudFormation 进行扩展，重点是加快无服务器开发，为 API 网关、Lambda 和 Step Functions 资源提供优化定义，并通过 SAM CLI 进行本地 Lambda 测试。Terraform使用跨提供商的单一工作流程提供多云基础设施定义，但无服务器专用工具较少，本地 Lambda 测试能力有限。

容器和基于标准的消息传递可以提高多云需求的可移植性。原生无服务器服务可与其他 AWS 服务紧密集成，当您的工作负载主要运行在上 AWS面时，这可以简化开发。

您需要处理来自 Web 或移动客户端的 HTTP 请求，对其进行处理，并以低延迟返回响应。

对于 Web API 和移动后端，API Gateway 会将 HTTP 请求路由到 Lambda 函数。DynamoDB 处理低延迟的数据访问。HTTP API 以较低的成本提供简单的路由，而 REST API 增加了缓存、请求验证和 WAF 集成。您可以使用 Amazon Cognito 处理身份验证， AWS Serverless Application Model 也可以使用速记语法定义这些资源。

要实现同步处理，请使用 AWS Lambda 计算和 Amazon API Gateway 网关路由请求。 AWS Step Functions 用于协调微服务工作流程。使用 DynamoDB 和 Amazon S3 存储数据和文件，并使用亚马逊 Amazon Cognito 对用户进行身份验证。

例如，假设你要构建一个通过邮政编码查找天气数据的微服务应用程序。客户端通过 Amazon Route 53 解析主机名。HTTP GET 请求路由到 API Getaway，后者通过 Amazon Cognito 验证访问令牌，然后将请求发送到 Lambda 函数。该函数查询 DynamoDB、自定义数据、向亚马逊 SQS 发送事件进行分析，向亚马逊 SNS 发送另一个事件以获取警报。流量减速后，Lambda 会破坏执行环境。您只需为实际功能使用付费。

您需要处理不需要立即响应的事件，提供可靠的交付和吸收流量高峰的能力。

对于无需立即响应即可处理事件的工作负载，Amazon SQS 负责缓冲和负载均衡。Amazon SNS 可以将单个活动同时分发给多个订阅者。 EventBridge 按内容筛选事件并与 SaaS 应用程序集成。Step Functions 协调多步处理，使用 DynamoDB 或 Amazon S3 来存储结果。

要实现异步处理，请 AWS Lambda 用于计算和编排 AWS Step Functions 。使用亚马逊简单通知服务路由消息以实现扇出，使用亚马逊简单队列服务路由消息，实现持久队列。将结果存储在 DynamoDB 和 Amazon S3 中。

例如，当用户将照片上传到 Amazon S3 时，Amazon S3 会发布一个事件，该事件调用 Lambda 函数来生成缩略图。如果您还需要对图像进行分类并通知用户，请使用 Amazon SNS 将单个上传事件分散到多个并行处理的 Lambda 函数。

您需要通过分支逻辑、错误处理、重试和人工批准步骤来协调一系列任务。

标准工作流程可处理运行长达 1 年的流程，仅执行一次并具有完整的审计历史记录。对于大容量、短时长的处理（最多 5 分钟），Express Workflows 以较低的每次执行成本运行。

当您的工作流处于多个状态、需要分支或并行运行任务时，Step Functions 非常有用。Step Functions 服务充当应用程序的状态模型。标准工作流程提供一次性执行以及完整的、可审计的执行历史记录，使其非常适合订单处理、人工审批工作流程和 ETL 管道。Express Workflows 以更高的容量和更低的成本提供至少一次的执行，使其非常适合物联网数据摄取、流式转换和高速事件处理。

您需要近乎实时地提取、处理和分析高速连续数据。Lambda 和 Amazon Kinesis 可以处理实时流媒体数据。用例包括活动跟踪、点击流分析、日志过滤、物联网遥测和计量。

对于原生 AWS 集成，Kinesis 数据流负责数据流摄取。亚马逊 MSK 可以在兼容的情况下采集直播。Apache KafkaLambda 或 Fargate 处理流数据，使用 DynamoDB 或 Amazon S3 来存储结果。

要实现无服务器流式传输，请使用 AWS Lambda 计算和 Amazon Kinesis 来收集和分析实时数据。使用 DynamoDB 和 Amazon S3 存储结果。

例如，当项目写入 DynamoDB 表时，DynamoDB Streams 会发布调用 Lambda 函数来生成实时分析的事件。要从数百万台设备中获取更大容量的数据，例如物联网遥测，请在处理之前使用 Kinesis Data Streams 收集和缓冲数据。

您需要的处理时间超过 Lambda 的 15 分钟限制，需要持久连接或享受自定义容器运行时带来的好处。

对于超过 15 分钟但包含离散步骤的工作流程，Lambda 耐用函数会检查进度并在调用期间继续执行。Step Functions 分布式地图无需预置计算即可并行处理来自 Amazon S3、Athena 或 JSON 的数百万个项目。Fargate 支持持续处理、持久连接和精细控制 CPU/memory 。

例如，处理 1000 万个 Amazon S3 对象的夜间数据管道使用 Step Functions 分布式地图对工作进行并行处理。处理文件超过 30 分钟的视频转码服务使用 Fargate。跨越数天的多步骤贷款批准工作流程使用 Lambda 耐用函数在人工审查步骤之间保持状态。

您需要在隔离的环境中运行用户提供的或 AI-generated 代码，同时保持租户分离和状态保护。

Lambda 微虚拟机提供由 Firecracker 提供支持的 VM-level 隔离，具有完整的操作系统功能、基于快照的快速启动和长达 8 小时的使用寿命。每个 microVM 都有专用 HTTPS 网址支持 HTTP/2、gRPC 和 WebSocket 协议。MicroVM 可以在空闲时暂停，以降低成本，同时保留内存和磁盘状态。与事件函数不同，MicroVM 使用 Dockerfile-based 编程模型，为每个会话分配一个环境，并按基线加突发模型（活动高峰期最多 4 倍基线）计费。每个 microVM 都支持针对 VPC 访问和公共互联网连接的可配置出口网络，无需负载均衡器或入口基础设施。

例如，AI 编码助手为每个用户会话提供自己的 microVM，以安全地执行生成的代码。交互式笔记本平台在隔离的 microVM 中运行每个学生的代码，该微虚拟机在交互之间保持状态。

AWS Lambda

AWS Fargate

Lambda MicroVMs

亚马逊 API 网关 REST API

亚马逊 API 网关 HTTP API

AWS AppSync

Lambda 函数 URL

Amazon Simple Queue Service

Amazon Simple Notification Service

Amazon EventBridge

AWS Step Functions

Amazon DynamoDB

Amazon Simple Storage Service

亚马逊 Aurora 无服务器

AWS Serverless Application Model

AWS Cloud Development Kit (AWS CDK)

Terraform

Amazon CloudWatch

AWS X-Ray