消息驱动架构（EDA）

消息驱动架构（EDA）

事件驱动架构（Event-Driven Architecture）通过事件的发布与订阅实现服务解耦，是微服务异步协作的核心模式。

1. 核心模式

事件通知

Service A ──(Event)──→ Event Bus ──(Fan-out)──→ Service B
                                           ──→ Service C
                                           ──→ Service D

A 不感知 B/C/D，仅声明"发生了什么"

事件驱动状态转移（Event-Carried State Transfer）

事件携带完整状态数据，消费者无需回查生产者。

{
  "event_type": "OrderCreated",
  "order_id": "ORD-123",
  "customer_id": "C-456",
  "items": [...],
  "total": 299.00,
  "timestamp": "2026-08-13T10:00:00Z"
}

2. 消息队列选型

Kafka 核心设计

Topic: events
├── Partition 0 → [E1][E2][E3] → Consumer Group A (C1, C2)
├── Partition 1 → [E4][E5][E6] → Consumer Group B
└── Partition 2 → [E7][E8]

Key Hash → Partition → 相同 Key 保证顺序
Offset → 消费者自行维护消费位点

3. 事件契约设计

Schema 管理

{
  "type": "record",
  "name": "OrderCreated",
  "namespace": "com.example.events",
  "fields": [
    { "name": "order_id", "type": "string" },
    { "name": "customer_id", "type": "string" },
    { "name": "total_amount", "type": "decimal", "precision": 10, "scale": 2 }
  ]
}

Schema 演进规则

Kafka Schema Registry（Confluent）

# 注册 Schema
curl -X POST http://schema-registry:8081/subjects/events-value/versions \
  -H "Content-Type: application/vnd.schemaregistry.v1+json" \
  -d '{"schema": "{...}"}'

# 序列化时自动注册/校验 Schema
producer.send(new ProducerRecord<>("events", avroRecord));

4. 幂等性设计

消息消费可能重复，消费者必须保证幂等。

幂等策略

示例

@Transactional
public void onPaymentCompleted(PaymentCompletedEvent event) {
    // 方法一：唯一键
    try {
        orderRepository.markPaid(event.getOrderId(), event.getTransactionId());
    } catch (DuplicateKeyException e) {
        log.info("Duplicate payment event, ignored");
        return;
    }
    
    // 方法二：状态机
    Order order = orderRepository.findById(event.getOrderId());
    if (order.getStatus() != OrderStatus.PENDING_PAYMENT) {
        return; // 已处理过
    }
    order.pay(event.getTransactionId());
}

5. 事件溯源结合

┌──────────┐     Event          ┌──────────────┐
│ Command  │ ─────────────────→ │ Event Store  │
│ Handler  │                    │ (Event Log)  │
└──────────┘                    └──────┬───────┘
                                       │
                    Projections        │
                    ┌──────────────┐   │
                    │ Read Model   │ ←─┘
                    │ (CQRS)       │
                    └──────────────┘

6. 最佳实践

1. 事件总线独立：核心业务事件与审计日志分开 Topic
2. 至少一次投递：消息队列保证，消费者做幂等
3. 死信队列：消费失败移至 DLQ，避免阻塞主队列
4. 监控告警：堆积量、消费延迟、重试次数
5. 事件版本：v1.order.created → v2.order.created

7. EDA 成熟度模型

企业落地事件驱动架构可参照以下成熟度阶梯：

8. 常见反模式与避坑指南

8.1 分布式大事务

❌ 反模式：在事件消费者中串行调用多个下游服务，形成"分布式大事务"。

// ❌ 错误：消费者中同步调用多个服务
@KafkaListener(topics = "order-created")
public void onOrderCreated(OrderEvent event) {
    inventoryService.deduct(event);      // 同步 RPC
    paymentService.charge(event);        // 同步 RPC
    shippingService.createOrder(event);  // 同步 RPC
    // 任一失败导致整体回滚困难
}

✅ 正解：每个服务独立监听事件， Saga 模式编排补偿。

OrderCreated Event ──→ Inventory Service（扣库存）
                   ──→ Payment Service（扣款）
                   ──→ Shipping Service（创建物流单）
                   
各服务独立消费，失败时发送补偿事件：
PaymentFailed ──→ InventoryCompensation（恢复库存）

8.2 共享数据库反模式

❌ 反模式：多个服务直接读写同一数据库表，然后通过事件通知变更。

✅ 正解：每个服务拥有独立的数据存储，通过领域事件传递状态变更。

8.3 事件滥用

延伸阅读

• 事件驱动架构与域事件 — 域事件建模与 Saga 分布式事务
• 消息队列深度解析 — 分布式消息队列原理与选型
• CQRS 与事件溯源实践 — 读模型分离与事件重放