消息驱动架构（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

总结

EDA 是微服务解耦的关键手段，但引入了最终一致性复杂度，需权衡使用。