SQS 到 Lambda 与 API
发布: (2026年1月9日 GMT+8 13:38)
6 分钟阅读
原文: Dev.to
Source: Dev.to
（未提供需要翻译的文本内容。如需翻译，请粘贴完整的文章或段落。）
概述
我正在评估是否让 API 服务直接处理 DynamoDB 流事件，而不是使用 Lambda 函数作为代理。目标是减少我们需要构建和维护的“glue” Lambda 数量。
当前架构
- 客户端请求 –
DELETE /account/:accountId被发送到accounts-resource-api。 - API 写入 DynamoDB。
- DynamoDB 流通过 EventBridge 触发 Lambda。
- Lambda 将消息推送到 SQS 队列。
- 工作器（另一个 Lambda）从队列读取并为每个子账户调用
DELETE /account/:accountId。
建议的架构
- 删除中间的 Lambda。
- 让
accounts-resource-api订阅 DynamoDB 流（EventBridge → SQS），并自行处理删除操作。 - 在 API 中使用 npm 库，例如 sqs‑consumer（Node.js），来处理 SQS 轮询和消息处理。
优缺点
| Aspect | Lambda‑based Worker | API‑direct Processing |
|---|---|---|
| Operational overhead | 独立的部署单元；额外的 IAM 权限；额外的监控。 | 更少的 Lambda 函数；更少的“胶水”代码。 |
| Scalability | Lambda 会随 SQS 队列积压自动扩展；每次调用相互隔离。 | API 必须处理轮询和并发处理；扩展取决于 API 的自动扩缩配置。 |
| Cold start latency | 首次调用可能会增加延迟，但对短任务通常可以忽略不计。 | API 本身没有冷启动，但轮询循环持续运行，可能会保持资源处于热状态。 |
| Error handling & DLQ | 通过 SQS → Lambda 集成，内置对死信队列和重试策略的支持。 | 必须在 API 代码中手动实现死信队列处理、重试以及退避逻辑。 |
| Resource consumption | Lambda 仅在有消息时运行；费用按调用计费。 | API 实例在轮询时可能处于空闲状态，即使没有工作也会产生计算成本。 |
| Observability | 每次 Lambda 调用都有 CloudWatch 日志；易于追踪。 | 需要在 API 的消费者循环中添加日志、指标和追踪。 |
| Security surface | 为 Lambda 配置最小权限的独立角色。 | API 服务需要额外权限来读取 SQS，可能还需要写入 DLQ 的权限。 |
具体关注点
死信队列（DLQ）管理
- Lambda：您可以配置 Lambda 触发器，在可配置的重试次数后自动将失败的消息移动到 DLQ。
- API：您必须编写代码来捕获处理错误，决定何时重新入队，并显式地将消息发送到 DLQ。这会增加复杂性并可能导致错误。
对 API 的额外负载（轮询）
- 在 API 中轮询 SQS 意味着服务将保持与 SQS 的长连接。
- 如果轮询间隔设置得很紧凑，这会增加 CPU 和内存使用。
- 自动伸缩策略需要考虑消费者循环的基线负载，而不仅仅是请求流量。
维护开销
- 简单转发到 API 端点的 Lambda 体积轻量，但仍需部署、版本管理和监控。
- 将逻辑合并到 API 中可以减少可部署单元的数量，但会把可靠性、伸缩和错误处理的责任转移到 API 代码库上。
建议
-
如果需要，请从 Lambda 开始：
- 简单、开箱即用的死信队列（DLQ）处理。
- 基于队列深度的自动扩展。
- 明确的职责分离（API 处理 HTTP 请求；Lambda 处理后台处理）。
-
仅在以下情况下考虑直接 API 处理：
- 您的 API 已经运行在能够水平扩展的平台上（例如 ECS、EKS、Fargate），并且能够轻松应对额外的轮询负载。
- 您已准备好在服务中实现可靠的重试、退避以及死信队列逻辑。
- 减少 Lambda 函数数量能够带来可衡量的运营收益（例如成本、部署复杂度）。
-
混合方案 —— 保留一个轻量的 Lambda，将请求转发给专用的工作者服务（例如容器化的消费者），而不是直接调用公共 API。这样既能获得独立工作者的扩展优势，又避免了调用相同 API 端点的“胶水” Lambda。
要点
- 使用 Lambda 作为 DynamoDB 流和 SQS 之间的桥梁是一个成熟的模式，具备强大的内置可靠性特性。
- 在 API 中直接嵌入 SQS 消费是可行的，但需要仔细处理死信队列（DLQ）、重试和扩展。
- 在评估时要结合团队的运维成熟度、成本模型以及预期的子账户删除量，权衡利弊。
欢迎分享您在任一模式下的经验，特别是关于长时间轮询、DLQ 处理以及整体系统可靠性方面的体会。