事件驱动 + 请求-响应混合架构
解决什么问题：纯事件驱动无法满足所有需求—— 混合架构让事件（异步）+ 请求-响应（同步）各司其职。
业务问题
真实场景
场景 1：电商 API 的混合需求
需求：
- 用户实时查询订单状态（同步）
- 后台异步处理订单事件（异步）
- 第三方支付回调（同步）
- 内部库存扣减（异步）
纯事件驱动的问题：
- Web 用户查询需要同步响应
- 第三方支付回调是 HTTP
纯同步的问题：
- 库存扣减要广播给多个下游
- 故障级联Bellemare Ch 13 原话：
"As powerful as event-driven microservice patterns are, they cannot serve all of the business needs of an organization. Request-response endpoints provide the means to serve important data in real time."
失败模式
| 失败模式 | 后果 |
|---|---|
| 纯事件 | Web/API 无法同步响应 |
| 纯同步 | 故障级联、性能差 |
| 混合无纪律 | 行为不一致 |
控制论视角
Ch 4 §4.6："反馈环路" + Ch 15："测量环节"
同步 = 直接反馈环（短链路、实时）
异步 = 事件流反馈环（长链路、解耦）
混合架构 = 多种反馈环并存
- 同步环：用于需要实时响应的场景
- 异步环：用于需要解耦的场景
- 二者通过事件流衔接对位：
- 同步 API = 测量环节（直接读取状态）
- 异步事件 = 控制律输出（处理后的事件）
- API Gateway = 中央控制器（路由）
核心概念
何时用同步 vs 异步
| 场景 | 推荐 | 原因 |
|---|---|---|
| 用户实时查询 | 同步 | 延迟要求 |
| 第三方 API 回调 | 同步 | HTTP 协议 |
| 跨服务事务 | 异步 | 解耦 |
| 状态广播 | 异步 | 多下游 |
| IoT 数据上报 | 异步 | 高并发 |
| 管理操作 | 同步 | 状态确认 |
3 种混合模式
模式 1：事件驱动 + 同步入口
外部请求 → 微服务（处理）→ 同步响应
↓ 副作用
内部事件流
例：下单 API
POST /orders → 创建订单 → 201 Created
→ 发 OrderCreated 事件
模式 2：同步查询 + 事件更新（读写分离）
查询请求 → REST API（读物化状态）
写入事件 → 事件流 → 更新物化状态
例：订单状态查询
GET /orders/123 → 读本地物化状态（快）
模式 3：API Gateway
客户端 → API Gateway → 微服务
↓
事件流（内部）
例：移动 App
App → API Gateway → OrderService / InventoryService
↓
Event Bus实时状态服务（同步 + 异步）
场景：Web 用户实时查询订单状态
方案：
- 订单事件流 → 物化到本地状态 → REST API
- 写：发事件（异步）
- 读：从本地状态读（同步）
- 优点：读写都最优外部 API 调用模式
陷阱：
- 网络不稳定 → 重试 + 超时
- 响应格式变化 → schema 适配
- 速率限制 → 退避策略
处理：
- 异步化（队列 + worker）
- 缓存响应
- Circuit Breaker（熔断器）工程实践
实战 1：电商下单 API（混合）
python
class OrderAPI:
def place_order(self, request):
# 同步部分：接收请求
order = Order.create(request)
# 同步部分：业务校验（快）
if not self.validate(order):
return 400, "Invalid"
# 异步部分：发事件（不等待）
self.event_bus.publish(OrderCreated(order))
# 同步响应（立即返回）
return 201, order.id
def get_order_status(self, order_id):
# 同步查询（读物化状态）
return self.materialized_state.get(order_id)实战 2：避免级联故障
策略：
- Circuit Breaker：失败率超阈值，断路
- 超时：每个调用有上限
- 重试：仅对瞬时错误
- 降级：失败时返回默认值
工具：
- Resilience4j
- Hystrix（已停止维护）
- Istio（service mesh）实战 3：API Gateway 设计
功能：
- 路由（按路径/header）
- 鉴权（统一）
- 限流（统一）
- 监控（统一）
- 协议转换（HTTP → gRPC）
工具：
- Kong
- Ambassador
- Spring Cloud Gateway反模式 vs 正模式
| 反模式 | 正模式 |
|---|---|
| 同步链路过长 | 同步只做必要环节 |
| 异步查询（轮询） | 同步查询 + 异步更新 |
| 无超时 | 每次调用都有超时 |
| 同步调用外部 API | 异步化 + Circuit Breaker |
性能指标
| 指标 | 衡量 | 健康值 |
|---|---|---|
| 同步 API p99 | 99% 请求延迟 | < 200ms |
| 同步/异步比例 | 不同调用类型比例 | 业务决定 |
| Circuit Breaker 触发 | 断路次数 | 低 |
| API Gateway 路由延迟 | 网关增加延迟 | < 10ms |
边界判断
何时用同步（必须）
- 用户实时查询
- 第三方 HTTP 回调
- 管理操作
- 需要立即确认
何时用异步（必须）
- 跨服务事务
- 状态广播
- 高并发写入
- 不需要立即响应
何时用 API Gateway（推荐）
- 多客户端类型
- 多协议支持
- 统一鉴权/限流
关键洞察
- 同步和异步不是对立——是不同反馈环路，各有适用场景。
- API Gateway 是混合架构的关键——它路由不同调用方式。
- 物化状态让读写都最优——同步读状态，异步写事件。
- 外部 API 必须 Circuit Breaker——不可控依赖是故障主因。
- 与 cybernetics 同构——同步 = 直接反馈（Ch 4 §4.6），异步 = 事件流反馈（Ch 15 测量累积）。