Appearance
事件驱动架构：先定义交付与一致性边界
修订于 2026-10-12。本文不引用未经证实的业务案例或性能数据。
事件表示已经发生的业务事实，例如“订单已创建”。发布者把事件发出，消费者分别处理后续动作。这样可以减少同步调用链，但也引入延迟、重复投递、乱序和故障排查成本。
设计事件契约
事件应有稳定的名称、唯一标识、发生时间、业务实体标识、schema 版本和必要的上下文。只传业务事实，不把消费者的内部实现塞进事件。敏感字段应最小化，且消费者权限要独立管理。
发布事件与更新本地数据库若分成两个无保护的操作，可能出现“数据已提交、事件未发布”。需要结合事务性发件箱等方案处理该窗口；可参考分布式事务文章。
消费端面对的现实
不同消息产品的投递和顺序保证不同，不能笼统假设“恰好一次”或全局有序。消费者应按业务键实现幂等，记录处理结果，并明确重试、死信与人工补偿。事件成功投递不等于业务动作成功完成。
对于需要强同步反馈的业务步骤，直接请求可能更清楚。事件适合后续任务独立、可异步完成的流程；关键一致性要求仍需显式建模。
上线检查
- 写清事件 schema、兼容规则和所有权。
- 验证重复、乱序、延迟、消费者停机和积压恢复。
- 监控发布失败、消费延迟、重试与死信数量。
- 让事件 ID 和业务 ID 贯穿日志与追踪。
- 对消费者的权限与数据保留建立边界。