事件溯源是一种通过保存状态变化事件而非最终状态来管理数据的模式，事件存储则是支持该模式的专用技术，用于可靠存储和管理不可变事件流。
事件溯源（Event Sourcing）和事件存储（Event Store）在微服务架构中紧密相关，但职责不同。事件溯源是一种设计模式，而事件存储是支撑该模式的技术实现。
事件溯源是什么？
在微服务中，传统方式通过直接更新数据库中的当前状态来记录数据变化。而事件溯源的核心思想是：不保存最终状态，而是保存引发状态变化的每一个事件。
例如，一个账户余额的变化不是直接写入“余额=100”，而是记录“存款100元”、“取款50元”等事件。服务在需要时重放这些事件，还原出当前状态。
这种模式的好处包括：
- 完整审计日志：所有变更都有据可查
- 易于调试和回溯问题
- 支持时间点查询（如“三天前的状态”）
- 天然支持事件驱动架构，便于与其他服务集成
事件存储的作用
事件存储是专门用于持久化事件流的数据库或组件，它是事件溯源得以实现的基础。
它负责安全、有序地存储事件，保证事件不可变、按发生顺序写入，并支持高效的读取和重放。
典型事件存储的特性包括：
- 追加写入：只允许新增事件，不能修改或删除已有事件
- 按聚合根（Aggregate Root）组织事件流
- 提供事件版本控制和并发检查机制
- 支持订阅机制，让其他服务实时响应新事件
常见实现有 EventStoreDB、Kafka（配合日志压缩）、自研基于数据库的事件表等。
两者的关系
事件溯源依赖事件存储来落地。没有可靠的事件存储，事件溯源无法保证数据一致性与可靠性。
可以理解为：事件溯源是“怎么建模业务逻辑”，事件存储是“把事件存好并管理好”。
在微服务中，一个服务采用事件溯源模式后，其状态变更都会转化为事件，由事件存储统一保存。其他服务可通过订阅事件流实现解耦通信。
实际使用中的注意事项
虽然事件溯源+事件存储提供了强大能力，但也带来复杂性：
- 查询性能可能下降，需引入CQRS分离读写模型
- 事件结构变更（升级）需要兼容处理
- 事件存储的运维和容量规划需提前考虑
适合对数据一致性、可追溯性要求高的场景，如金融交易、订单系统等。
基本上就这些。事件溯源定义了“做什么”，事件存储解决“怎么做”。两者结合，让微服务具备更强的可维护性和扩展性。
