cqrs - 使用事件溯源和 CQRS 的缺点是什么？

Question

事件溯源和 CQRS 很棒，因为它使开发人员摆脱了一个预先建模的数据库的困扰，除非有大数据迁移项目，否则开发人员必须在应用程序的整个生命周期中使用该数据库。 CQRS 和 ES 还具有其他好处，例如扩展事件存储、审计日志等，这些已经遍布互联网。

但缺点是什么？

以下是我在研究和编写小型演示应用程序后能想到的一些缺点

复杂:有人说ES很复杂。但我想说，拥有复杂的应用程序比复杂的数据库模型要好，在复杂的数据库模型上，您只能使用查询语言(多个连接、索引等)运行非常受限的查询。我的意思是像 Scala 这样的一些编程语言拥有非常丰富的集合库，可以非常灵活地生成一些非常复杂的聚合，还有 Apache Spark 可以轻松查询分布式集合。但是数据库总是受限于它的查询语言功能，并且分布式数据库比分布式应用程序代码更难(只需在另一台机器上部署另一个实例!)。

磁盘空间使用率高 :事件存储最终可能会使用大量磁盘空间来存储事件。但是我们可以安排每隔几周清理一次并创建快照，也许我们可以将历史事件本地存储在外部 HD 上，以防我们将来需要旧事件？

内存占用高 :每个域对象的状态都存储在内存中，这可能会增加 RAM 使用量，而且我们都知道 RAM 是多么昂贵。 大问题!! 因为我穷!有什么解决办法吗？可以使用 Sqlite 而不是在内存中存储状态？通过在我的应用程序中引入多个 Sqlite 实例，我是否让事情变得更加复杂？

更长的启动时间 :失败或软件升级启动缓慢，具体取决于事件数量。但是我们可以使用快照来解决这个问题吗？

最终一致性 : 某些应用程序的问题。想象一下，如果 Facebook 使用事件溯源和 CQRS 来存储帖子并考虑到 facebook 的系统有多忙，如果我发布了一个帖子，我会在第二天看到我的 Facebook 帖子:)

事件存储中的序列化事件 :事件存储将事件存储为序列化对象，这意味着我们不能在事件存储中查询事件的内容，这无论如何都是不鼓励的。将来我们将无法向事件添加另一个属性。解决方案是将事件存储为 JSON 对象而不是序列化事件？但这是个好主意吗？或者添加更多事件来支持对原始事件对象的更改？

有人可以评论我在这里提出的缺点并纠正我，如果我错了，并建议我可能错过的其他任何东西吗？

Answer 1

这是我对此的看法。

通过拥有丰富的域对象、简单的数据模型、历史跟踪、对并发问题的更多可见性、可扩展性等，CQRS + ES 可以使复杂软件系统中的事情变得更简单。它确实需要以不同的方式思考系统，因此可能很难找到合格的开发人员。但是 CQRS 使开发人员之间的职责分离变得更加简单。例如，初级开发人员可以纯粹使用读取端工作，而无需接触业务逻辑。

数据副本肯定需要更多的磁盘空间。但是现在存储相对便宜。它可能需要 IT 支持团队进行更多备份并计划在出现​​问题时如何恢复系统。然而，如今的服务器虚拟化使其工作流程更加简化。此外，在没有单一数据库的情况下在系统中创建冗余要容易得多。

我不认为更高的内存使用是一个问题。业务对象水合应该按需进行。对象不应保留对已经持久化的事件的引用。事件水化应该只在持久化数据时发生。在读取方面，您没有通常在分层系统中发生的实体 -> DTO -> ViewModel 转换，并且您不会有任何类型的对象更改跟踪，而全功能 ORM 通常会这样做。大多数系统执行的读操作明显多于写操作。

如果由于各种数据上下文的初始化而使用多个异构数据库，则较长的启动时间可能是一个小问题。但是，如果您使用 ADO .NET 之类的简单工具与事件存储和读取端的微 ORM 进行交互，则系统将比任何功能齐全的 ORM 更快地“冷启动”。这里重要的是不要使访问数据的方式过于复杂。这实际上是 CQRS 应该解决的问题。正如我之前所说，读取端应该为 View 建模，并且没有任何重新映射数据的开销。

根据我的经验，两阶段提交适用于不需要为数千用户扩展的系统。您需要选择与分布式事务协调器配合良好的数据库。例如，PostgreSQL 可以很好地读取和写入单独的模型。如果系统需要针对大量并发用户进行扩展，则必须在设计时考虑最终一致性。在某些情况下，您将拥有不使用 CQRS 的聚合根或上下文边界以避免最终一致性。这对于域的非协作部分是有意义的。

如果您为事件存储选择了正确的数据库，您可以以序列化格式(如 JSON 或 XML)查询事件。这应该仅用于分析目的。除了聚合根 ID 和事件类型之外，系统内的任何内容都不应查询事件存储。该数据将被索引并存在于序列化事件之外。