为什么要从 CRUD 转向事件源架构？作者｜SavanKharod译者

作者｜SavanKharod
译者｜平川
如果对各种架构风格都有个透彻的理解，设计者就能够构建新型的、反应性的、有弹性的大型应用。因此，遵循这些经过行业检验的标准可以节省时间、保证可靠性，并推动目标实现。毕竟，企业有什么理由要花时间和资源来重新发明轮子？
但仅仅了解不同的架构，如基于CRUD的架构、基于微服务的架构和基于事件源的架构，并不足以做出全面的决策。我们需要深入了解细节，并理解它们各自的特性、适用性和所提供的价值。在这篇文章中，我们将看一下CRUD和事件源架构，思考为什么应该考虑从前者迁移到后者。
什么是CRUD？
CRUD是创建、读取、更新和删除的缩写。它构成了数据库的四个命令，四个不言自明的命令，这些命令被认为是持久性存储管理的必备要素。这种模式被各行各业的企业广泛用于跟踪客户数据、员工信息、支付记录、账户等。
让我们快速说明一下CRUD的常规事件流。 Gary正在浏览一个电子商务网站。他把一个游戏机、一个控制器和一个游戏添加到购物车中。此时，购物车的数据库看起来大概是这样：

文章图片
假如我们添加另外一个物品（如耳机），则数据库会变成下面这样：

文章图片
如果Gary删除了耳机，则表就会变回之前的样子。此外，如果他另外添加一个控制器，则数据库会变成下面这样：

文章图片
本质上，数据库遵循创建-读取-更新-删除的方法来维护表。 “更新”和“删除”功能是CRUD的特点。
CRUD方法的局限性
虽然CRUD方法由于其操作的轻量化和简单性而备受青睐，但它也有自己的一系列局限，这包括：
对于CRUD ，最常见的批评是原始、过时。与其说它是一种架构或设计，不如说它是一个可供遵循的循环步骤，不管是构建一个数据库还是一个API 。
CRUD依赖于数据库中状态的持久性。然而，考虑到当前数据操作事件的动态性，这种信息的存储可能是浪费和资源密集型的。
尽管CRUD架构很简单，但在开始阶段，它需要人们花费大量的精力编写大量的代码。尽管如此，当涉及到云负载均衡时， CRUD却无法胜任。
【为什么要从 CRUD 转向事件源架构？】虽然CRUD代码开始时可能很简单，但当它开始与其他服务或微服务共享数据时，就会出现与状态同步和故障处理有关的问题。
CRUD架构所涉及的复杂性将需要同样复杂的解决方案，这可能会延伸到故障跟踪、手动状态记录、异步批处理等。这方面的考虑在编码和整合上都会比较艰难。
在CRUD模型中，实体实例通常是双重表示，一是内存中的可变对象，二是关系数据库表中的一个可变行。这样的结构导致了臭名昭著的对象-关系阻抗不匹配。试图弥合这种鸿沟的努力却进一步增加了这一架构的复杂性。
什么是事件源架构？
事件源是一种数据存储技术，被认为是CRUD的升级版。它只关注创建和读取功能，而完全省略了CRUD中更新和删除值的操作。更简单地说，你不能通过事件源执行破坏性的操作。
那么，它是如何克服CRUD面临的挑战的？
这里有个有趣的地方：与CRUD遵循的传统方法不同，事件源将变化逐个记录下来，作为当前状态随时间变化的一系列增量，而不是持久化当前状态本身。通过这种方式，事件源赋予了状态变化可追溯性。在大多数情况下，这种设计通常与领域驱动设计（DDD）和命令查询责任分离（CQRS）设计模式相结合。