事件驱动架构

Serverless 的默认姿势不是「前端一直调一个常驻 API」，而是 某处发生事实（对象上传、表变更、队列消息）→ 自动触发函数。这与 kafka-intro 的异步解耦同源，差别在 托管事件总线 vs 自建 Kafka 集群。

学习目标

• 列举 AWS 上常见 Lambda 事件源
• 理解同步 vs 异步触发与失败重试语义
• 对照 Kafka 消费者组与 SQS 触发的异同

常见事件源

事件源	典型场景	投递特点
API Gateway	HTTP API	同步，客户端等响应
S3	文件上传后处理	异步，至少一次
SQS	削峰、解耦	批处理、可见性超时
DynamoDB Streams	表变更捕获	有序分区流，见 ddb-streams
EventBridge	跨服务路由、定时	规则匹配、schema 注册

用户上传 PDF → S3 PutObject
            → S3 通知 → Lambda 转码/写索引
            → 失败 → DLQ（死信队列）供人工或告警

与 Kafka 的对照

维度	Kafka	SQS + Lambda
运维	自建 Broker、分区、ISR	全托管
消费模型	Consumer Group、offset	隐式，按消息拉取
顺序	分区内有序	标准队列不保证全局顺序
适用	高吞吐日志、流处理	AWS 原生、与 Lambda 深度集成

kafka-consumer 讲的 rebalance 与 at-least-once，在 Lambda 里体现为 重复 invocation——Handler 必须 幂等（见 kafka-delivery）。

设计原则

1. 事件即事实：payload 带 eventId、时间戳、来源
2. 小 Handler：重逻辑拆成多函数或写回队列
3. 失败可观测：DLQ + CloudWatch Alarm，不要静默丢消息
4. 避免环状触发：A 改表触发 B，B 又写表触发 A

练习

• 设计「订单支付成功」事件：用 EventBridge 还是 Kafka 更合适？写三条理由