基本信息
| 字段 | 内容 |
|---|---|
| 英文 | Decoupling & Event-Driven Architecture |
| 全称 | Decoupling & Event-Driven Architecture |
| 中文释义 | 解耦与事件驱动架构 |
| 日文释义 | 疎結合とイベント駆動 |
| 考试频率 | ⭐⭐⭐⭐⭐ |
| 易混淆 | 同步调用 |
一句话理解
用队列和事件降低组件之间的直接依赖。
核心作用
- 降低生产者与消费者之间的直接依赖。
- 缓冲突发流量，让上下游按各自速度工作。
- 隔离局部故障，避免一个组件变慢拖垮整条链路。
- 让服务可以独立部署、扩缩和重试。
紧耦合与松耦合
| 维度 | 紧耦合 | 松耦合 |
|---|---|---|
| 调用关系 | 组件直接依赖对方地址与可用性 | 通过队列、事件或中间层交互 |
| 失败影响 | 容易级联失败 | 可通过缓冲、重试与隔离缩小影响 |
| 扩缩 | 上下游往往需要同步扩缩 | 生产端与消费端可独立扩缩 |
| 一致性 | 较容易立即返回结果 | 通常需要接受异步与最终一致性 |
同步与异步
- 同步调用：调用方等待结果，适合需要立即响应的短链路。
- 异步调用：调用方提交任务后继续工作，适合耗时、可重试、突发或无需立即返回的处理。
- 解耦不等于所有场景都必须异步；应根据响应时效、一致性与故障边界选择。
常见 AWS 模式
- SQS：队列、缓冲、削峰、消费者 Pull。
- SNS：Topic、Push、Pub/Sub、Fan-out。
- EventBridge：Event Bus 按事件内容和规则路由。
- Step Functions：显式编排多步骤工作流与状态。
可靠处理要点
- 至少一次投递场景需要消费者具备幂等性。
- Visibility Timeout 应覆盖处理时间；失败消息通过重试和 DLQ 隔离。
- 监控队列积压、最旧消息年龄、失败率与处理延迟。
- 设计 Backpressure，避免上游无限制地产生下游无法消费的任务。
工作中的应用场景
- 下单接口先写入 SQS，订单 Worker 按自己的吞吐处理。
- SNS Fan-out 把同一业务事件送入多个独立 SQS 队列。
- EventBridge 根据事件类型路由到 Lambda、SQS 或 Step Functions。
- SQS 触发 Lambda 批量处理消息；成功后删除，失败后重试。
工作原理
Producer 发布消息或事件 → 中间服务保存或路由 → Consumer 独立拉取 / 接收并处理 → 成功确认，失败重试或进入 DLQ。
Cloud Practitioner 考点
- SQS = 排队与缓冲；SNS = 广播；EventBridge = 规则路由。
- 松耦合可以提高弹性与故障隔离。
- 队列能削峰，但不会自动修复消费者逻辑。
SAA-C03 考点
- 根据 Backlog、Fan-out、Event Pattern 等关键词选服务。
- SQS Standard 可能重复投递，消费者需幂等。
- Visibility Timeout、DLQ、Redrive Policy、Long Polling。
- 同步改异步时考虑最终一致性、重试和顺序。
常见误区
- 松耦合不等于“没有依赖”，而是让依赖通过稳定契约和中间层管理。
- SQS 不是广播；SNS 不是传统持久队列；EventBridge 不主要解决积压缓冲。
- 重试次数越多并不一定越可靠，必须防止重试风暴与毒消息。
易混淆服务
SQS vs SNS vs EventBridge；编排（Step Functions）vs 事件路由（EventBridge）；同步请求 vs 异步任务。
面试高频问题
- 为什么在两个服务之间增加队列？
- 如何保证重复消息不会重复扣款或重复创建订单？
- 队列积压持续上升时如何定位瓶颈？
- 什么时候直接同步调用比事件驱动更合适？
重点记忆
解耦 = 独立变化 + 故障隔离 + 独立扩缩；可靠异步 = 幂等 + 重试 + DLQ + 监控。
关联服务
Amazon SQS、Amazon SNS、Amazon EventBridge、AWS Lambda、AWS Step Functions、Amazon CloudWatch。