当前位置:[首页 > 韩语学习 > 阅读 > 如何理解事件溯源]

如何理解事件溯源

发布: 2018-01-13 17:00 | 来源:www.jptranslate.com | 查 看:

在近期举行的PHPDublin见面会上,来自DynamicRes的架构师Barry Sullivan被问到“什么是事件溯源”,作为对这个问题的回答,他在博客上写下了这篇文章,详细解释了什么是事件溯源以及事件溯源有哪些好处。以下内容翻译自Barry的博客,已获得作者授权。

Web开发的现状

在详细解释事件溯源之前,先让我们来看看Web开发的现状。

当前的Web开发是以数据库作为驱动的,在设计Web应用的时候,我们会自然而然地将系统设计与数据库存储机制联系在一起。如果使用的是MySQL,我们就会把数据结构设计成表,如果使用的是MongoDB,就会把数据结构设计成文档。这样会强制我们只关注事物的当前状态,我们会想“怎样保存这些数据,以便将来可以再把它们拿出来(或者修改它们)”?

如何理解事件溯源

这种方式存在三个问题。

1. 有悖于我们的思维

人类的思考和交流并不是以状态为中心。如果我们在咖啡店相遇,我会问你“最近可好”?如果你只是告诉我一堆状态却指望我从中猜出发生了什么事情,这是非常不合情理的。

“我有一幢房子、一辆汽车、一个冰箱、三个社交媒体账号、一只猫咪,我的右脚有点痛,我不擅长聊天,我还有另一只猫咪……”

看到没有?这样我会疯掉的。你应该告诉我,从上次见面之后都发生了哪些事情,这样我才能知道你现在的状况是什么样子的。简单地说,你应该告诉我一个故事,这个故事是由一连串事件组成的。

2. 单一的数据模型

在上图中,读写操作使用了相同的模型。我们从写数据的角度来设计表,然后基于这样的结构查询数据。这对于小型的应用来说是没有问题的,但用在大型的应用里就会有问题。随着系统的增长,查询会变得越来越复杂,总有一天,一个查询可能会包含10个连接操作,代码有100行那么多。系统很快就会变得脆弱无比,难以维护和变更。

3. 关键业务信息的丢失

这是一个大问题。在以表作为驱动的系统里,你只保存了系统的当前状态,你根本就无法知道系统是如何达到当前状态的。如果我问你“这个用户修改了几次邮件地址”,你有办法回答吗?或者我再问“有多少人把一件商品添加到购物车里,然后又移除掉,直到一个月之后才买了那件商品”,你就更没法回答了。你存储数据的方式丢掉了很多有用的业务信息!

事件溯源

事件溯源与上述的情况恰好相反,它并不关心当前状态,而是关注持续不断的变化事件。

举个例子,假设我们有一个“购物车”,我们可以创建购物车,往里面添加商品或移除商品,然后结账。

购物车的生命周期可以包含如下一系列事件:

创建购物车

往购物车里添加商品

再次往购物车里添加商品

从购物车里移除商品

结账

这些就是一个购物车的生命周期,包含了一系列事件。这就是事件溯源,非常简单吧?

如何理解事件溯源

几乎所有的流程都可以被看成一系列事件。在与领域专家交谈时,他们不会提及“表”和“连接”,他们会将流程描述成一系列事件以及可以应用在这些事件上的规则。

如何实施业务规则?

大部分的业务操作都有硬性约束。对于购物车来说,它的约束就是“一件商品必须先被放进购物车后才能被移除”。如果一件商品没有被添加到购物车里,又怎么能够移除它?这种事件顺序是不可能发生的。在没有状态的情况下,你怎样才能知道“购物车里是否有这件商品”?

很简单,你只要检查之前是否发生过“商品被添加到购物车里”这个事件,这样你就可以知道购物车里是否存在这件商品,然后移除它。

这样不会浪费时间吗?

一点也不。一般来说,要执行约束,只需要获得事件的一个很小子集。通过简单的数据库查询就可以获得有用的历史事件,在加载完这些事件后重放它们,把它们“投射”出来,以此构建你的数据集。这样的操作其实是很快的,因为你使用的是本地的处理器,而不是执行一系列SQL查询(跨域网络的调用要比本地操作慢得多,至少会相差两个数量等级)。

如何展示数据?