事件驱动架构
事件与命令有什么区别？
- 事件: 对已经发生的状态变化作出记录，例如“订单已支付”，表达事实而不规定每个消费者必须做什么;
- 命令: 请求某个明确接收者执行动作，例如“扣减库存”，表达意图而非已发生事实;
- 建模价值: 明确事实和意图后，消费者才能知道是否可独立反应、是否允许拒绝，以及谁负责决定结果;
事件驱动架构如何传播状态变化？
事件生产者 → 事件路由与过滤 → 消费者 A
→ 消费者 B
- 生产者: 在领域状态改变后发布事件，不需要直接控制所有下游实现;
- 路由器: 按主题或属性把事件送到相关消费者，常由消息基础设施提供;
- 消费者: 根据事件更新自己的状态或触发后续工作，不需要知道其他消费者的存在;
- 解耦效果: 新增分析或通知消费者不一定要求原业务同步改变;
事件驱动适合哪些工作负载？
- 指标与元数据: 多个处理器独立消费采样或业务事件;
- 日志: 把服务器与安全日志传入不同监控和分析管道;
- 异构集成: 不同技术栈通过稳定事件格式交换变化;
- 并行扇出: 同一事实触发多个独立处理，吞吐可按消费者单独扩展;
- 原文示例: NATS、Kafka、EventBridge、SNS、Google Pub/Sub;
异步通信为何仍需要一致性设计？
- 可靠发布: 数据库提交与事件发送之间可能失败，需要明确补发、事务消息或其他可靠发布机制;
- 重复与乱序: 消费者要按协议识别重复事件、版本及处理顺序，不能假设所有事件严格按一次到达;
- 错误处理: 异步失败不能直接返回给最初调用者，需要任务状态、重试、死信和追踪;
- 可观测性: 传播关联 ID 并记录事件进度，否则跨服务故障难以还原;