为什么需要从 CRUD 转向事件溯源架构？

对各种架构格式有深刻的理解，使设计人员能够构建创新、反应式和弹性的应用程序以进行扩展。因此，遵循这些经过行业审查的标准可以节省时间、确保可靠性并推动结果。毕竟，企业为什么要花时间和资源重新发明轮子？

但仅仅熟悉不同的架构，如基于 CRUD 的架构、基于微服务的架构和基于事件源的架构，还不足以做出全面的决策。人们需要深入了解细节并了解它们各自提供的性质、适用性和价值。 

在这篇文章中，我们将研究 CRUD 和事件溯源架构，以了解为什么应该考虑从前者移植到后者。让我们来看看。

什么是 CRUD？

CRUD 是创建、读取、更新和删除的首字母缩写词。它构成了这四个数据库命令，它们本身就很容易解释，被认为是持久存储管理所必需的。这种模式被跨部门和行业的企业广泛用于跟踪客户数据、员工信息、支付记录、账户等。

让我们快速说明在 CRUD 的情况下事件的规则流：

Gary 正在浏览一个电子商务网站。他在购物车中添加了一个游戏机、一个控制器和一个游戏。在那个时间点，购物车数据库看起来有点像这样：

假设他要向购物车中添加另一个物品（例如耳机）。数据库更新为：

如果 Gary 取下耳机，表格将恢复到之前显示的表格。此外，如果他要添加另一个控制器，数据库将如下所示：

本质上，数据库遵循创建-读取-更新-删除的方法来维护表。“更新”和“删除”功能是 CRUD 的特性。

CRUD 方法的局限性

虽然 CRUD 方法因其操作的轻量级和简单性而备受青睐，但它也受到其自身的一系列限制的困扰。这些包括：

• 对 CRUD 的第一个也是最常见的批评是它是原始的和过时的。它不是将其视为架构或设计，而是被视为可以遵循的步骤循环，无论是构建数据库还是API。

• CRUD 依赖于数据库中状态的持久性。然而，鉴于当前环境中围绕数据操作的事件的动态性质，此类信息的存储可能是浪费且资源密集型的。

• 尽管 CRUD 架构很简单，但在初始阶段需要在代码和工作方面进行大量投资。尽管如此，CRUD 在云负载平衡方面表现不佳。

• 虽然 CRUD 代码一开始可能非常简单，但当它开始与其他服务或微服务共享数据时，就会出现与状态同步和处理故障相关的问题。

• CRUD 架构所涉及的复杂性将需要同样复杂的解决方案，这些解决方案可以扩展到故障跟踪、手动状态日志、异步批处理等。这样的考虑将更难以编码和集成。

• 在 CRUD 模型中，实体实例通常以双重形式表示，并作为内存中的可变对象占据关系数据库表中的可变行。这种结构会导致臭名昭著的对象关系阻抗失配。即使试图弥合这种分歧，也会进一步为架构注入复杂性。

什么是事件溯源架构？

事件溯源是一种数据存储技术，被视为 CRUD 的升级。它只关注 Create 和 Read 函数，完全省略了值的更新和删除操作，就像在 CRUD 中的情况一样。简而言之，您不能通过事件溯源来执行破坏性操作。

那么，它是如何克服CRUD面临的挑战的呢？

这就是有趣的地方：与 CRUD 遵循的传统方法不同，事件溯源将记录的单个更改存储为一系列导致当前状态作为时间因素的增量，而不是持久化当前状态本身。通过这种方式，事件溯源赋予了状态变化的可追溯性。在大多数情况下，此功能通常与领域驱动设计 (DDD) 和命令查询职责分离 (CQRS) 设计模式结合使用。

为了更好地理解事件溯源架构，让我们以 Gary 的银行账户为例。假设加里的帐户中有 2,400 美元。他以 499 美元的价格购买了 PS5 游戏机。电子商务网站为他的这次购买提供了 49 美元的现金返还。 

在这种情况下，事件源表将如下所示： 

通过跟踪一段时间内的取款和存款，可以计算出他当前的余额为 1,950 美元。这种状态恢复和事件回放称为重放。

人们可以将事件溯源视为客户活动的日志。 

如果我们从电子商务平台的角度来看 Gary 的活动，控制台的添加将是第一个事件，控制器的添加将是第二个事件，依此类推。事实上，即使是结帐过程也将是一个独立的事件。如果 Gary 无意中将三个控制器添加到购物车（例如，事件 1、2 和 3）然后他移除了一个，则移除也将是一个单独的事件：事件 4！

采用事件溯源架构的好处

从对事件溯源的基本理解来看，它似乎是一种更好、更完善的替代方案，可以克服 CRUD 的缺点。为了强调这一事实，让我们来看看事件溯源的成熟优势。

• 事件溯源遵循事件驱动的架构，并有助于在状态更改时可靠地发布事件。

• 它通过持久化事件而不是域对象来克服对象-关系阻抗不匹配问题，如 CRUD 所见。

• 它维护一系列事件的记录，可以在仅附加状态下进行操作。通过消除跟踪实体之间的状态和关系的需要，事件溯源代码更容易从数据库中写入和读取。

• 由于它记录了实体如何到达其当前事件的日志，事件溯源保持审计数据和事务数据之间的一致性，因为它们都是相同的。此外，它还具有出色的故障安全性，因为可以从事件日志中重建数据。

• 由于所有事件只是附加到现有数据库中，并且取消了更新和删除功能，因此事件溯源架构纯粹专注于写入方面，从而提高了其性能。

• 事件溯源允许对事件流进行分析，这有助于企业从中获取关键信息。因此，他们可以获得所有系统活动的顶级视图，而不会使写入功能复杂化。

• 遵循事件源模型的架构更易于测试和调试，因为可以在引入命令和事件之前对其进行模拟以进行测试。此外，事件日志还可以很好地记录调试活动，如果检测到问题，可以在受控环境中重放事件日志以了解此类异常的来源。

• 它可以存储任何类型的消息，任何消费者只要拥有授权访问权限，就可以访问这些信息。可以提出时间查询来确定任何给定时间实体的状态。因此，它们非常灵活。

• 与单体应用程序相比，基于事件的应用程序更容易迁移，因为它们遵循基于微服务的架构。由于事件交换的业务实体的松散耦合，这是可能的。

随着越来越多的应用程序需要以有序和异步的方式交付实时数据，对事件溯源的需求不断增长。此外，它还是在 Web 规模上使用和管理应用程序日志数据的绝佳媒介。在这种情况下，事件溯源建立了一个单一的事实点，从而提高了应用程序的可靠性。 

那么，您的业务计划何时从 CRUD 迁移到事件溯源？