基于事件溯源的CQRS设计模式

即使在非微服务架构中,数据管理也可能非常复杂,由于这种复杂性,许多微服务架构的批评者认为,提倡每服务对应一个数据库概念的架构中,数据库的管理和应用复杂度很难降低。

在这个文章中,我们将关注一些最常见和最强大的数据管理模式。因为微服务具有高度可扩展性,所以这些模式支持松散耦合的微服务架构。

1. 什么是 CQRS 模式

CQRS 是关于分离应用程序架构的命令和查询方面的。

  • 命令可以定义为改变对象或实体状态的操作。

  • 查询可以定义为返回对象和实体状态的操作。

因此,查询操作是只读的,永远不能改变对象和实体的状态。CQRS 没有用于读取和写入操作的单一接口,而是将数据的更改和查询作为单独的关注点。

为了更好地理解 CQRS,让我们首先了解如何在传统架构中应用 crud 操作。

基于事件溯源的CQRS设计模式_第1张图片 传统架构

如果我们看一下上面的架构,用户从用户界面执行读取和写入请求到一个 api,该 api 对同一模型执行命令和查询以更新数据库并从数据库读取、最后返回数据。

CQRS 设计模式建议有两个独立的模型,一个用于更新数据库,另一个用于从数据库中读取数据。

基于事件溯源的CQRS设计模式_第2张图片 CQRS

上图是 CQRS 模式的基本示例,其中单个数据库在命令和查询模型之间共享。

用户可以在用户界面中进行更改,这次发送到处理命令模型的 api 的请求将在此处使用。

数据读取将由查询 api 完成,此处将使用查询模型。将模型与读取和更新分离降低了单一模型带来的复杂性。

上述CQRS架构可以进一步优化,有两个数据库,一个专用于写入数据,另一个专用于读取数据。

2. 为什么需要 CQRS

现在我们将了解为什么需要 CQRS。

  • 数据读取比写入更频繁,因此可以通过将读取数据源放置在合适的拓扑位置来减少响应延迟以获得更好的性能(性能)

  • CQRS 允许读写工作负载独立扩展,这会产生更少的锁争用(独立扩展)

  • 读取部分可以使用针对查询优化的模式,写入部分可以使用针对写入优化的模式(优化)。

  • 确保只有正确的域实体对数据执行写入更容易。(安全性)

  • 将写入活动与就绪活动分开允许我们为任务使用最好的数据库技术,例如,用于写入的 SQL 数据库和用于读取的非 SQL 数据库(技术变更)

3. 事件溯源

事件溯源是一种方法,其中对实体或对象所做的所有更改都存储为事件存储的不可变事件序列,而不仅仅存储当前状态。

每当实体的状态发生变化时,都会在事件存储中的事件列表中附加一个新事件。由于保存事件是单个操作,因此它本质上是原子的。

事件是事实,它代表了系统中发生的一些动作。

电子商务系统中的事件:

基于事件溯源的CQRS设计模式_第3张图片

4. 基于CQRS的事件溯源

事件溯源的好处:

  • 事件存储提供每个状态变化的完整日志,有效地创建和审计整个系统的跟踪。

  • 任何对象的状态都可以通过重放事件存储来重新创建。这为我们提供了将系统恢复到任何先前状态的能力。这专门用于调试。

  • 它持久化事件而不是域对象,它避免了对象关系不匹配的问题。

  • 事件存储可以将数据提供给多个数据库读取。

CQRS 是一种独立的设计模式,但它经常与事件溯源结合使用。下面是 CQRS 与 EventSourcing 的架构。

基于事件溯源的CQRS设计模式_第4张图片 带有事件溯源的 CQRS

基于上述架构,用户可以从发送到命令 API 的用户界面发出更改请求。在这种情况下,命令 API 将是处理命令并生成所需事件的命令端处理程序。

然后它将事件保存到事件存储中,并通过事件发布者或生产者将事件发布到消息队列或代理。

在查询方面,我们将有一个事件消费者来监听特定事件。一旦它检测到给定类型的新事件,它将消耗事件有效负载并将读取和查询数据库。然后查询 API 将占用查询处理程序的角色。这意味着当从用户界面发出请求时。它将使用查询模型来查询数据库并返回数据以进行 UI 呈现。

5. 结论

在这篇文章中,我们讨论了事件溯源和 CQRS 设计模式的基础知识。我们了解它们带来的好处,最后,我们了解了为什么以及如何将这两种模式结合到我们的应用程序中。

基于事件溯源的CQRS设计模式_第5张图片

推荐

架构设计说明书究竟应该包含什么

说说常见数据库及中间件的主从设计


原创不易,随手关注或者”在看“,诚挚感谢!

你可能感兴趣的:(数据库,设计模式,java,python,大数据)