这是我参与11月更文挑战的第8天，活动详情查看：2021最后一次更文挑战
Event sourcing 事件溯源是借鉴数据库事件日志的一种数据持久方式，在事件日志中记录导致状态变化的一系列领域事件。通过持久化记录改变状态的事件，通过重新播放获得状态改变的历史。 事件回放可以返回系统到任何状态。
在 ES 中，事务单元变得更细粒度，使用一系列有序的事件来代表存储在数据库中的领域模型状态，一旦一个事件被加入事件日志，它就不能被移走或重新排序，事件被认为是不可变的，事件序列只能被追加方式存储。
由于事件流本身具有逻辑上严格次序性，因此使用统一的事件流（事件日志）能够很自然实现事务机制，无需额外 ACID 机制或 2PC 之类同步强硬方式。
1、关于事件溯源
事件溯源由 DDD 理论提出的。
在不同的界限上下文中，共享成员的含义、用法以及他们的对象属性都会有些不同，DDD 建议这些共享成员在各自的界限上下文中都分别建自己的类（包括数据库表），而不是共享。可以通过数据同步的手段来保持数据的一致性。
2、事件溯源是什么？
事件溯源是微服务的一种存储方式，它是微服务的内部实现细节。
通常整个应用程序只有一个 Event Store， 不同的微服务都通过向 Event Store 发送和接受消息而互相通信。
Event Store 内部可以分成不同的 stream（相当于消息队列中的 Topic）， 供不同的微服务中的领域实体（Domain Entity）使用。
3、事件溯源与传统数据库存储
数据库存储方式只能保存当前状态，而事件溯源则存储了所有的历史状态，因而能根据需要回放到历史上任何一点的状态，具有很大优势。
由此带来的问题主要包括：
1）程序比较复杂，因为事件是一等公民，你必须把业务逻辑按照事件的方式整理出来，然后用事件来驱动程序。
2）如果你要想修改事件或事件的格式就比较麻烦，因为旧的事件已经存储在 Event Store 里了（事件就像日志，是只读的），没有办法再改。
4、事件溯源与事件通知
两者表面上看起来很像。
事件通知只是微服务的集成方式，程序内部是不使用事件溯源的，内部实现仍然是传统的数据库方式。只有当要与其他微服务集成时才会发消息。而在事件溯源中，事件是一等公民，可以不要数据库，全部数据都是按照事件的方式存储的。
5、事件溯源的落地
常用于记账和源代码库变更记录，区块链也是其重点应用场景。
- END -
作者：架构精进之路，十年研发风雨路，大厂架构师，CSDN 博客专家，专注架构技术沉淀学习及分享，职业与认知升级，坚持分享接地气儿的干货文章，期待与你一起成长。
关注并私信我回复“01”，送你一份程序员成长进阶大礼包，欢迎勾搭。
Thanks for reading!
