Amazon SOA-C02: Serverless 与应用程序集成 — 学习指南
属于 AWS SysOps Administrator Associate SOA-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.
无服务器和应用程序集成涵盖了在不管理服务器的情况下运行事件驱动的应用程序以及可靠地连接各种服务。其运维重要性在于管理规模、延迟、故障模式和最小权限访问，同时保持成本的可预测性。该领域专注于 Lambda 的行为（冷启动、并发）、可靠的事件交付（EventBridge、SNS、SQS）、安全控制（执行角色和权限）以及异步流程的可观察性。
AWS Lambda 运维要点与并发
Lambda 的性能和可用性取决于冷启动、并发限制和节流控制。当 Lambda 必须初始化一个新的执行环境时，就会发生冷启动；对于延迟敏感的路径，可以通过使用预置并发（aws lambda put-provisioned-concurrency-config –function-name MyFn –qualifier 1 –provisioned-concurrent-executions 10）来减少其影响，并优先选择更轻量的运行时或更少的初始化工作。使用预留并发（aws lambda put-function-concurrency –function-name MyFn –reserved-concurrent-executions 50）来预留和限制并发，以保护下游服务并强制执行每个函数的配额；监控 ConcurrentExecutions 和 Throttles CloudWatch 指标。
重试和调用模型因模式而异：同步调用（API Gateway、直接 Invoke）会立即返回错误；异步调用（EventBridge、SNS、S3 异步通知）使用 Lambda 的异步重试策略（两次带退避的重试），并且可以使用 DLQ 或目标（destinations）。对于事件源映射（SQS、Kinesis、DynamoDB 流），Lambda 的轮询器会一直重试，直到消息过期或事件源的重新驱动策略触发死信。保守地配置超时和内存（aws lambda update-function-configuration –function-name MyFn –timeout 30 –memory-size 1024），并将 SQS 可见性超时设置为 > 函数超时（建议可见性 >= 函数超时 * 2），以减少重复处理。
使用 EventBridge 构建事件驱动架构
EventBridge 提供了一个托管的事件总线，具有灵活的路由、Schema 注册表、跨账户交付以及重试/DLQ 设置。使用自定义事件总线进行域分离，使用合作伙伴事件总线进行 SaaS 集成；使用模式创建规则（aws events put-rule –name orderEvents –event-pattern file://order-pattern.json –event-bus-name customBus），并附加带有死信和重试配置的目标（目标的 JSON 支持 DeadLetterConfig 和 RetryPolicy）。使用 Schema 注册表来发现和强制执行事件结构；当生产者定义明确时注册 Schema，并在有帮助时使用代码绑定（Code Bindings）生成类型化模型。
在需要以下功能时选择 EventBridge：
- 使用丰富的事件模式或跨账户/事件总线隔离进行复杂的路由和筛选
- 对多种目标（Lambda、Step Functions、Kinesis、SQS、SNS）的原生支持
- 跨团队的 Schema 发现和治理
在需要更简单的扇出（fan-out）或保证队列语义时选择直接使用 SNS/SQS：
- SNS 用于向许多订阅者进行扇出和推送语义
- SQS 用于具有可见性超时和重新驱动策略的持久、拉取式处理
使用 SNS 和 SQS 进行消息传递（DLQ、可见性超时）
SNS 是一个发布/订阅的推送服务；SQS 是一个具有拉取语义的持久队列。对于高可靠性处理，首选 SNS -> SQS -> Lambda 模式，以将摄入与处理解耦，并获得对重试和可见性的控制。配置 SQS 重新驱动策略（aws sqs set-queue-attributes –queue-url URL –attributes file://redrive.json）以便在达到 maxReceiveCount 后将消息移动到 DLQ，并确保可见性超时足够长以避免过早地重新投递（建议可见性 >= 函数超时 * 2）。对于 FIFO 需求，使用 SQS FIFO 或 SNS FIFO，通过消息组 ID 来保持顺序，通过重复数据删除 ID 来避免重复。
死信处理选项及其使用场景：
- Lambda 异步调用：配置 DeadLetterConfig 或 Destinations (AsyncEventInvokeConfig) 将失败发送到 SQS/SNS 或调用另一个 Lambda。
- SQS：为毒丸消息配置到 SQS DLQ 的重新驱动策略，并设置适当的 maxReceiveCount。
- EventBridge：在规则目标上设置 DeadLetterConfig 和 RetryPolicy 以捕获无法投递的事件。
幂等性至关重要：使用 DynamoDB 条件写入（带有 ConditionExpression attribute_not_exists(pk) 的 PutItem）、存储带有 TTL 的幂等性令牌，或使用 SQS FIFO 的重复数据删除功能来实现幂等处理程序，以确保“恰好一次”的语义。
函数权限、角色和最小权限
对 Lambda 执行角色和函数资源策略应用最小权限原则。从用于 CloudWatch Logs 的 AWSLambdaBasicExecutionRole 开始，然后为服务授予明确的资源 ARN（例如，对 arn:aws:dynamodb:region:acct:table/MyTable 的 dynamodb:PutItem 权限）。当可以使用特定的 ARN 时，避免使用像 Resource: “*” 这样的通配符。使用按操作和资源限定范围的托管策略或自定义策略，并在为服务添加入站调用权限时包含条件（aws:SourceAccount, aws:SourceArn）：
- 为 EventBridge 添加调用权限：aws lambda add-permission –function-name MyFn –principal events.amazonaws.com –statement-id ev1 –action lambda:InvokeFunction –source-arn arn:aws:events:region:acct:rule/MyRule
- 对于 SNS：使用 source-arn 条件来限制哪个主题可以调用该函数
决策标准：
- 使用基于函数资源的策略来允许服务调用（EventBridge、SNS、CloudWatch Events）
- 使用 IAM 执行角色来获取运行时权限（DynamoDB、S3、Secrets Manager）
- 优先使用资源级权限和条件约束来减小爆炸半径
无服务器的可观测性与故障排查
可观测性必须涵盖指标、日志、追踪和异步交付状态。关键的 CloudWatch 指标包括：Invocations、Duration、Errors、Throttles、ConcurrentExecutions、IteratorAge（用于流和 SQS 触发器）。为了获得异步失败的可见性，请监控 “AsyncEventInvoke” 指标，并为 DeadLetterErrors 和 Throttles 设置 CloudWatch Alarms。启用 X-Ray 追踪 (aws lambda update-function-configuration –function-name MyFn –tracing-config Mode=Active) 以获取跨服务的端到端追踪，并可视化冷启动、下游延迟和异常。
使用结构化 JSON 日志和 CloudWatch Logs Insights 查询来快速发现错误模式；在日志中实现幂等性检查并记录关联 ID。对于分布式追踪，如果自动上下文丢失，请在 EventBridge/SNS 流的事件负载中显式传播追踪 ID。对于 SQS 事件源映射，监控 ApproximateAgeOfOldestMessage，如果该值增长，则设置告警，这表明存在背压或节流。捕获 Lambda Throttles 指标并发出告警，并跟踪预置并发的使用情况与成本之间的权衡。
常见陷阱与决策标准
- 未配置 DLQ 或仅依赖默认重试：为异步 Lambda 配置 DLQ 或 Destinations，为队列配置 SQS redrive，以捕获毒丸消息供手动检查。
- SQS 上的可见性超时不正确导致重复处理：将可见性超时设置为 >= 函数超时 * 2，并考虑重试和下游调用以避免重复。
- Lambda 执行角色权限过大：避免使用 Resource: “*” 并在调用策略和资源策略中添加服务/源条件 (aws:SourceArn, aws:SourceAccount)。
- 忽略并发限制导致节流：使用预留并发来限制函数，为延迟敏感的函数使用预置并发，并监控 ConcurrentExecutions/Throttles。
- 缺少跨异步边界的追踪：向事件中添加关联 ID，并启用 X-Ray 或传播追踪标头以重建流程。
- 为满足持久性需求而误用 SNS 直接调用 Lambda：当需要持久化缓冲、可见性控制和更简便的 DLQ 处理时，首选 SNS->SQS->Lambda 模式。
实际问题：用例场景
AcmePayments 通过 EventBridge 接收大量支付事件，并在高峰期遇到间歇性的 Lambda 节流和重复处理问题。他们需要可靠的处理、无数据丢失，并限制对 DynamoDB 的下游负载。
- 创建一个 EventBridge 自定义总线和规则以匹配支付事件；添加一个 SQS FIFO 队列作为持久化目标，并在目标配置中设置 DeadLetterConfig 和 RetryPolicy。
- 配置 Lambda 轮询 SQS 队列（事件源映射），批处理大小根据下游容量进行调整，并将可见性超时设置为 >= 函数超时 * 2。
- 为 Lambda 预留并发 (aws lambda put-function-concurrency …) 以限制对 DynamoDB 的写入突发；如果需要低延迟，则为一小部分池实现预置并发。
- 使用以 payment-id 为键的 DynamoDB 条件写入来实现幂等性，并存储带有 TTL 的幂等性记录以便清理。
- 启用 X-Ray 追踪和结构化日志，在事件中包含关联 ID 以追踪处理过程；在 ApproximateAgeOfOldestMessage、Throttles 和 DLQ 指标上设置 CloudWatch 告警。
理由：将 EventBridge 与 SQS 解耦提供了持久化缓冲和重试语义；预留并发保护下游 DynamoDB 免受突发流量影响，幂等性防止重复处理，而追踪/告警则提供了对故障模式的操作可见性。
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →