2. 事件驱动架构基础

在银行核心系统向分布式、实时化演进的过程中，事件驱动架构（Event-Driven Architecture，EDA）常被误解为“发消息就是事件驱动”。要真正掌握EDA，第一步必须厘清四个基础概念：事件、消息、命令、查询。它们看似都在“传递数据”，但在语义、时序、耦合度和责任归属上截然不同。

一、核心原理：四种交互语义的本质差异

事件（Event）是对“已经发生的事实”的不可变描述，例如“账户A于10:00向账户B转账500元已完成”。事件用过去时命名，发布者不关心谁消费、消费后做什么，因此天然低耦合、可多播、可重放。

命令（Command）是“要求某个接收者执行动作”的意图，例如“冻结账户A”。命令有明确的唯一目标，可能被拒绝，具有强指向性和责任绑定。

查询（Query）是“读取当前状态”的请求，例如“查询账户A余额”。查询不改变状态，强调一致性读与响应时效。

消息（Message）是传输载体，是事件、命令、查询在中间件上的封装形式。消息是“信封”，事件/命令/查询是“信的内容”。把消息等同于事件，是初学者最常见的概念混淆。

二、方法流程：从业务动作到事件发布的判断路径

在银行场景中，设计一个交互前应先做语义判断，而不是直接选中间件。推荐流程如下：

1. 识别业务意图：是“记录已发生”“要求执行”还是“读取状态”？
2. 确定责任归属：事件无接收者责任，命令有明确执行者，查询有明确数据源。
3. 选择交互模式：事件走发布订阅，命令走点对点，查询走同步API或CQRS读模型。
4. 封装为消息：统一信封结构，携带事件ID、聚合根ID、版本号、发生时间。
5. 定义契约与版本策略：事件Schema需向后兼容，命令需明确拒绝语义。

// 事件信封示例（JSON）
{
  "eventId": "evt-20240612-0001",
  "eventType": "AccountDebited",
  "aggregateId": "ACC-889900",
  "version": 3,
  "occurredAt": "2024-06-12T10:00:03+08:00",
  "payload": { "amount": 500.00, "currency": "CNY", "counterparty": "ACC-112233" }
}
// 命令信封示例
{
  "commandId": "cmd-20240612-0007",
  "commandType": "FreezeAccount",
  "targetId": "ACC-889900",
  "requestedBy": "risk-service",
  "reason": "suspected_fraud"
}

三、案例/场景：银行转账中的四类交互

以“手机银行转账500元”为例：客户端发起命令“TransferMoney”；转账服务校验后执行扣款，发布事件“AccountDebited”；风控服务订阅该事件进行实时评分；账务查询服务通过查询接口返回余额；上述所有内容都以消息形式在Kafka中传输。可以看到，一次业务动作同时涉及四种语义，但各自职责清晰。

四、架构对比：EDA vs SOA vs 微服务 vs 批处理

这四种架构并非互斥，而是不同维度的组织方式。SOA强调服务复用与企业服务总线（ESB）编排，通常是同步请求-响应；微服务强调按业务能力拆分、独立部署，通信可以是同步也可以是异步；批处理强调定时、大批量、离线处理，如日终跑批；EDA强调以事件为第一类公民，通过发布订阅实现时间解耦与空间解耦。

• 耦合方式：SOA偏中心化编排，微服务偏接口契约，EDA偏事件契约，批处理偏文件/表依赖。
• 时序特征：SOA与微服务多为同步，EDA为异步流式，批处理为周期性。
• 扩展性：EDA可通过增加消费者水平扩展，批处理靠分片与并行度。
• 银行典型场景：SOA用于渠道整合，微服务用于账户/支付拆分，EDA用于实时风控与通知，批处理用于计息与对账。

五、误区与复盘