Blog:关于Event Sourcing架构

来自WHY42
imported>Riguz2017年6月23日 (五) 00:00的版本 (在微服务实践中,也许一致性是最头疼的问题了,因为跨数据库的事物将变得十分困难。我们让每一个微服务的数据存储都私有化来实现服务之间的解耦,无可避免存在很多业务需要操作多个微服务的数据库,可能不仅仅是跨服务的不同表,还可能是不同的数据库类型。如果我们采用一个数据库可能事情就会简单了,但这就脱离了微服务的真正价值了。)
(差异) ←上一版本 | 最后版本 (差异) | 下一版本→ (差异)

在微服务实践中,也许一致性是最头疼的问题了,因为跨数据库的事物将变得十分困难。我们让每一个微服务的数据存储都私有化来实现服务之间的解耦,无可避免存在很多业务需要操作多个微服务的数据库,可能不仅仅是跨服务的不同表,还可能是不同的数据库类型。如果我们采用一个数据库可能事情就会简单了,但这就脱离了微服务的真正价值了。

现阶段解决分布式事物大致有这些方案:

姑且不论实现的复杂性,以上方案大多数可以实现最终一致性。为什么说大多呢?因为太复杂了,我还没研究清楚...

而Event Sourcing目测是一个更简单的实现最终一致性的方案,采用Event Sourcing + CQRS来实现读写分离,具体是什么关系呢?这里引用一点: >在CQRS中,查询方面,直接通过方法查询数据库,然后通过DTO将数据返回。在操作(Command)方面,是通过发送Command实现,由CommandBus处理特定的Command,然后由Command将特定的Event发布到EventBus上,然后EventBus使用特定的Handler来处理事件,执行一些诸如,修改,删除,更新等操作。这里,所有与Command相关的操作都通过Event实现。这样我们可以通过记录Event来记录系统的运行历史记录,并且能够方便的回滚到某一历史状态。Event Sourcing就是用来进行存储和管理事件的。

再来看一张图:

CQRS

参考文章: