Amazon DOP-C02: 事件驱动架构和自动化 — 学习指南

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

属于 AWS DevOps Engineer Professional DOP-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

事件驱动架构将生产者与消费者解耦，强调异步通信，并使系统能够从容应对流量高峰和故障。其核心原则是通过事件/消息实现松散耦合、由消费者驱动的扩展、幂等处理程序以及明确的故障处理和可观测性。AWS 为持久化队列、发布/订阅、事件总线、流处理、编排和运维自动化提供了构建模块。掌握 Amazon SQS、Amazon SNS、Amazon EventBridge、AWS Step Functions、Lambda 事件源映射、AWS Systems Manager Automation 和 OpsCenter，以及 Kinesis Data Streams 和 Firehose 之间的相互作用，可以帮助您构建可扩展、容错且可审计的自动化和数据管道。

消息传递与数据采集：SQS、SNS、Kinesis 和 Firehose

Amazon SQS 提供持久、可扩展的队列以实现解耦。标准队列提供至少一次交付和尽力而为的排序，具有几乎无限的吞吐量；它们适用于那些能够通过幂等键和条件写入来容忍重复和乱序消息的并行工作程序。FIFO 队列强制按消息组有序交付，并通过去重（在五分钟窗口内）实现精确一次处理语义。它们保证顺序和单次处理，但牺牲了绝对吞吐量：使用多个消息组在 FIFO 内部实现并行化，或启用高吞吐量 FIFO 以达到每秒数千条消息的处理能力。配置队列或单条消息的可见性超时，使其超过最大处理时间；对于 Lambda 消费者，将可见性超时设置为函数超时的至少六倍，以便在消息重新出现之前允许重试。使用长轮询来减少空接收。当消息超过 maxReceiveCount 时，死信队列 (DLQ) 会捕获“毒丸”消息；之后可以将消息从 DLQ 重放回源队列，以便在修复后重新处理。监控 ApproximateAgeOfOldestMessage 来检测积压，并驱动并发/自动扩展变更。

Amazon SNS 提供托管的、高吞吐量的发布/订阅服务。发布者向一个主题推送一次；SNS 将消息扇出 (fan-out) 到多个订阅（SQS、Lambda、HTTP/S、电子邮件、移动设备）。订阅筛选策略使用消息属性，仅将相关的通知路由到每个订阅者，从而减少下游的成本和负载；可以表达精确匹配、前缀、数值范围、非…、存在等断言。使用 SNS 实现扇出、解耦通知和移动推送。启用重试，并为无法投递的消息考虑每个订阅配置一个 DLQ。对于需要有序扇出的场景，SNS FIFO 主题与 FIFO SQS 订阅的组合可以强制实现排序和去重。

Kinesis Data Streams 提供有序、低延迟的数据流，具备分片级别的并行能力，适用于实时分析和事件处理。生产者使用分区键将记录写入分片；消费者（Lambda、KCL、增强型扇出消费者、Kinesis Data Analytics）通过检查点机制按分片顺序读取记录。对不可预测的负载使用按需容量模式，或对可预测的吞吐量使用预置分片并进行分片调整 (resharding)。调整分区键以平衡热点分片，并监控 IteratorAge 以检测消费者延迟。增强型扇出 (Enhanced Fan-Out) 为每个消费者流提供专用的 2 MB/s 吞吐量，并通过 HTTP/2 实现低延迟推送。

Kinesis Data Firehose 是一项完全托管的交付服务，用于将数据近乎实时地采集到 S3、Amazon OpenSearch Service、Splunk 或 HTTP 终端节点，并提供可选的 Lambda 转换、缓冲（按大小/时间）、压缩和加密功能。它的数据源可以是直接的 PutRecord/PutRecordBatch 调用、Kinesis Data Streams 或 CloudWatch Logs/Events 订阅。当您需要具有转换和批处理功能的托管交付，且不想构建和运维消费者代码时，应使用 Firehose。动态分区功能允许您根据键将记录路由到不同的 S3 前缀，以实现高效的下游处理。

路由、编排与调度：EventBridge 和 Step Functions

Amazon EventBridge 是用于路由、治理以及跨账户/事件域集成的中央事件总线。使用默认总线处理 AWS 服务事件，使用自定义总线来划分域和应用权限，使用合作伙伴总线进行 SaaS 集成。规则通过基于内容的模式匹配事件，并将事件路由到 200 多个 AWS 服务目标。使用输入转换器来塑造负载，并利用归档/重放功能在恢复或新消费者上线期间重新处理历史事件。资源策略支持跨账户事件路由，以便在平台账户中进行集中治理。EventBridge Pipes 提供从事件源（SQS、Kinesis、DynamoDB Streams、Amazon MSK 上的自管理 Apache Kafka 等）到目标的点对点、可配置的流，内置筛选、批处理、转换以及通过 Lambda 或 Step Functions 进行的丰富功能——当您不想管理一个完整的消费者应用程序但需要轻量级中介时，这是理想的选择。EventBridge Scheduler 提供一次性调度和 cron 调度，以调用具有执行角色、时区支持和可选灵活时间窗口的目标，从而减少惊群效应。

AWS Step Functions 使用 Amazon States Language 编排分布式工作流，其状态包括：Task、Choice、Parallel、Map（包括分布式 Map）、Wait、Pass、Succeed/Fail，以及强大的 Retry/Catch 模式。深度的服务集成无需编写胶水代码来调用 AWS API，包括同步 (.sync) 和带任务令牌的回调模式。对于长时间运行、审计密集型的编排，选择标准工作流 (Standard Workflows)，它具有恰好一次的状态转换、长达一年的持续时间以及按状态转换计费的特点；执行历史会被保留，并提供强大的可见性和内置的 X-Ray 跟踪。对于高吞吐量、短生命周期（秒到分钟级）的编排，选择快速工作流 (Express Workflows)，您可以接受按请求+持续时间计费和至少一次的执行语义，以换取大规模扩展能力；它适用于流式摄取丰富、事件路由器和微编排等场景，在这些场景中您可以使任务具有幂等性。应用带有补偿任务的 Saga 等模式和集中式错误处理；将重试/超时逻辑外部化到状态机中，以简化任务代码。

计算触发器与反压：Lambda 事件源映射

Lambda 事件源映射 (ESM) 将基于轮询的源连接到 Lambda，并控制并发、批处理和错误处理。

• SQS：Lambda 通过轮询队列并使用批次（最多 10 条消息；最大批处理窗口长达 300 秒）调用您的函数来实现水平扩展。对于标准队列，扩展会根据队列深度和消息吞吐量积极进行；对于 FIFO 队列，Lambda 会保留每个消息组的顺序，并一次处理一个组的一个批次。在 ESM 上配置最大并发数，以限制工作程序规模并保护下游系统；结合使用预留/预置并发来保证容量。使用部分批次响应功能，只确认成功的记录并将失败的记录重新入队，从而避免重放整个批次。将队列的可见性超时设置为超过最坏情况下的总重试时间。使用死信队列 (DLQ) 和重新驱动策略来隔离毒丸消息。

• Kinesis Data Streams：默认情况下，每个分片一个并发 Lambda 调用，以确保分片内排序。将 ParallelizationFactor 提高到 10，可以在子序列间的排序不重要的情况下，并发处理每个分片的多个批次。批次大小最高可达 10,000 条记录 (6 MB)，最大批处理窗口长达 5 分钟，让您能够摊销成本并提高吞吐量。使用“函数出错时二分” (bisect on function error) 在批次内通过二分查找定位错误记录，并使用“失败时目标” (on-failure destinations) 或最大重试次数/记录存活时间来丢弃或路由无法处理的记录。监控 IteratorAge 以检测消费者延迟，并相应地重新分片或增加并行度。

• DynamoDB Streams：在语义上与 Kinesis 类似；批次大小最高可达 1,000 条记录 (6 MB)，采用每个分区键一个分片的模型。消费者接收有序的项目级变更（INSERT、MODIFY、REMOVE）。应用相同的故障处理（出错时二分、最大重试次数、记录存活时间）和筛选。使用包含消费者所需属性的流视图类型（NewImage、OldImage、NewAndOldImages 或 KeysOnly）来优化负载大小。

ESM 中的事件筛选功能通过在轮询器层面丢弃不相关的事件来减少调用次数。在流上使用 Lambda 的翻滚窗口聚合功能，以随时间聚合记录，实现小批量处理模式。

运维自动化与修复：Systems Manager Automation 和 OpsCenter

AWS Systems Manager Automation 提供使用 JSON/YAML 编写的运行手册（类型为 Automation 的文档），其中包含诸如 aws:runCommand、aws:executeScript、aws:invokeLambda、aws:approve、aws:createStack 和 aws:executeAutomation 等步骤。自动化操作接受参数、发出输出、通过变更历史进行版本控制，并使用专用的 AutomationAssumeRole 运行，以实现最小权限和跨账户/区域操作。您可以控制整个机群的并发性和错误阈值，要求审批和变更日历 (Change Calendar) 窗口，并通过 SNS 与通知集成。可以通过多种方式调用自动化操作：按计划调用、通过 EventBridge 规则调用（用于对 AWS Health、CloudWatch 或 API 事件进行近乎实时的修复）、通过 AWS Config 修复操作调用以强制执行策略（例如，为 EBS 卷应用默认标签或为 EC2 实例附加默认实例配置文件），以及从 OpsCenter 调用。

OpsCenter 将来自 CloudWatch 警报、AWS Config、Health 事件或自定义来源的运维问题聚合成 OpsItems。每个 OpsItem 都会跟踪状态、优先级、去重信息、相关资源和运行手册链接。您可以为标准修复关联一键式运行手册，并通过配置 EventBridge 或 Config 规则来启用自动修复，以便在 OpsItem 被创建或更新到匹配条件（例如，安全组允许 0.0.0.0/0 访问 SSH、补丁合规性偏离或备份失败）时，启动特定的自动化操作。使用 Systems Manager Explorer 可以跨账户和区域可视化机群健康状况和待处理的 OpsItems。这种组合——OpsItems 作为持久化记录，加上 Automation 运行手册作为代码化的修复方案——能够实现可审计、一致的大规模运维。

设计与运营指南

为所有消费者设计幂等性，因为“至少一次交付”很常见。对于低延迟的并行反应，优先选择通过 SNS 或 EventBridge 规则进行事件驱动的扇出；对于缓冲工作负载并保护生产者免受消费者处理缓慢的影响，优先选择 SQS；当分析需要严格的按分片排序和可重放的流时，优先选择 Kinesis。当定制化的消费者显得大材小用时，使用 EventBridge Pipes 在源和目标之间进行轻量级的托管集成；对于基于时间的触发器，使用 EventBridge Scheduler，无需维护 cron 基础设施。

合理设置超时和重试。对于 SQS，可见性超时必须超过最大处理时间加上重试时间；对于流，应限制重试次数并设置 MaximumRecordAgeInSeconds，以避免无休止地重放错误记录。系统地使用死信队列 (DLQ) 或失败目标，并为 SQS 的 ApproximateAgeOfOldestMessage、Lambda 的 ConcurrentExecutions/Throttles/Errors、IteratorAge、Step Functions 的 ExecutionFailed/TimedOut 以及 EventBridge 的 FailedInvocations 添加仪表板和告警。当流量尖峰不可避免且延迟 SLA 要求严格时，使用 Lambda 预置并发来预热容量。在治理方面，优先选择使用带有资源策略的 EventBridge，以实现跨账户路由和归档/重放功能，从而支持消费者的演进和事件恢复。

实际问题场景

Shopify 需要对其秒杀活动的订单处理流程进行现代化改造，同时在下游服务变慢或失败时增加实时分析和自动化修复功能。

1. 摄入并扇出订单事件

• 使用 SNS FIFO 主题从结账处发布 OrderPlaced 事件，确保每个 OrderId 的通知都有序且去重。订阅包括：
  • 一个 SQS FIFO 队列 (Order-Workers) 用于履约，并保持顺序。
  • 一个 EventBridge 自定义事件总线 (CommerceBus) 用于治理和额外的路由。
  • 一个 Kinesis Data Firehose 交付流，用于将订单近实时地交付到 S3，并使用 GZIP 压缩以供分析。 为何选择 SNS FIFO：它提供有序、精确一次的语义，并能可扩展地扇出到多个订阅者，而无需将发布者与消费者耦合。

2. 缓冲并处理履约

• Lambda 通过事件源映射从 SQS FIFO 队列消费消息，批处理大小为 10，启用了部分批次响应功能，并限制了最大并发数以保护下游的仓库 API。队列的可见性超时设置为 Lambda 超时时间的六倍，以适应重试。一个 DLQ 在 maxReceiveCount=3 时捕获毒丸消息；一个重新驱动工作流稍后会重新处理已修复的消息。 为何选择 SQS FIFO + Lambda ESM：它强制执行按订单的顺序，通过缓冲隔离下游服务的缓慢，并提供精细的错误处理。

3. 编排多步 Saga

• 一个 Step Functions Standard 工作流负责编排支付、库存预留、欺诈筛选和发货预订等步骤，并在失败路径上提供重试、超时和补偿任务（退款、重新入库）。第一个任务由 SQS 消费者调用的 Lambda 触发。 为何选择 Standard 工作流：它支持跨外部系统的长期运行、可审计、精确一次的状态推进，并具有丰富的错误处理能力。

4. 将领域事件路由至不同能力

• CommerceBus 通过来自生产者服务的 PutEvents 调用以及 SNS 订阅接收 Order* 事件。EventBridge 规则：
  • 匹配 OrderPlaced 事件，以便在高价值客户下单时通知市场营销部门 (Lambda) 并创建支持案例 (AWS Support API 集成)。
  • 使用资源策略将 OrderFailed 事件转发到中央运营账户的事件总线，以实现跨账户治理。 为何选择 EventBridge：它提供集中的路由、筛选、跨账户交付，并能在不更改生产者的情况下添加新的消费者。

5. 通过管道将合作伙伴源数据用于扩充

• EventBridge Pipes 将一个合作伙伴的 SQS Standard 队列（缺货的 SKU）连接到一个 Step Functions Express 工作流，该工作流通过一个 Lambda 函数扩充商品信息，并将结果推送到一个内部 SQS 队列用于补货。 为何选择 Pipes + Express 工作流：它以高吞吐量和低成本实现了托管的、低开销的集成和轻量级的数据扩充。

6. 实时分析与搜索

• 一个 Kinesis Data Stream 收集点击流和运营事件。Lambda（作为增强型扇出消费者）执行会话化处理，Kinesis Data Analytics 聚合 KPI。Firehose 将转换后的订单和分析数据交付到 S3 数据湖和 Amazon OpenSearch Service，并按日期/市场进行动态分区以实现高效查询。 为何选择 Streams + Firehose：为分析提供有序、低延迟的处理，并为存储和搜索提供托管的交付与转换。

7. 基于时间的自动化

• EventBridge Scheduler 每分钟运行一个 cron 任务，向 CommerceBus 发布 InventorySnapshotRequested 事件，从而触发一个 Step Functions Express 工作流，该工作流汇编来自各个仓库的快照，以实现近乎实时的库存准确性。 为何选择 Scheduler：无需自定义基础设施的原生、有弹性的 cron 功能。

8. 自动化修复与运营

• AWS Config 规则检测履约 VPC 中开放的 SSH 或公有的 S3 ACL。托管的修复措施会调用 Systems Manager Automation 运行手册来纠正配置偏差。针对 SQS ApproximateAgeOfOldestMessage 和 Lambda IteratorAge 的 CloudWatch 告警会在 OpsCenter 中创建 OpsItems；关联的运行手册会扩展特定 Lambda 的预置并发、增加 Step Functions 的预留容量或临时放宽批处理窗口。一个针对 AWS Health EC2 维护事件的 EventBridge 规则，其目标是一个 SSM Automation 文档，用于在维护窗口期间平稳地重启受影响的实例。 为何选择 OpsCenter + Automation：它提供集中的、可审计的问题跟踪，以及可以安全地跨账户/区域运行的一键式或自动化的最小权限修复。

该设计通过缓冲和扇出机制承受秒杀活动的流量尖峰，通过编排保留业务不变量，在数秒内交付分析结果，并通过策略驱动的自动化修复形成闭环。

← 高可用性、弹性和灾难恢复 · 所有领域 · 存储、数据库和数据管理 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →