快速回顾一下，事件溯源和变更数据捕获是可用于构建响应式分布式系统（即微服务）的解决方案。微服务应通过弹性、可伸缩性来应对不断变化的环境（即云）。实现这些能力的关键在于消息驱动和事件驱动。想了解更多，我建议您阅读《响应式宣言》。

本文介绍的两个核心解决方案是事件溯源和变更数据捕获。在正式介绍这两个解决方案之前，需要知道它们服务于相似的目标，即：

事件溯源使用其自身的日志作为事实来源，而变更数据捕获依赖于底层数据库事务日志作为事实来源。这一差异对软件的设计和实现有着重大影响，将在本文稍后介绍。

在深入研究之前，区分事件溯源和变更数据捕获所关心的事件类型很重要。

领域事件和变更事件没有关联，除非某个变更事件碰巧包含一个领域事件，这是稍后将在文章中介绍的 Outbox 模式的前提。

既然我们已经确定了事件溯源和变更数据捕获的一些共同点，就可以更深入地探讨了。

事件溯源是一种解决方案，它允许软件将其状态维护为领域事件的日志。因此，取走整个日志就代表了应用程序的当前状态。拥有此日志还能够方便地审计历史记录，并能够“时光倒流”并重现由先前状态引起的问题。

事件溯源实现通常具有这些特征：

此外，事件溯源实现通常具有这些特征：

事件溯源模仿数据库的工作方式，但发生在应用程序级别。根据图 2，该图可以更新以表示具有大致相同设计的数据库，如图 3 所示。

当我们深入探讨事件溯源和变更数据捕获如何相互比较时，图 2 和图 3 之间的比较将变得更加相关。

变更数据捕获 (CDC) 是一种解决方案，它从数据库事务日志（或等效机制）捕获变更事件，并将这些事件转发给下游消费者。CDC 最终允许应用程序状态被外部化并与外部数据同步。

变更数据捕获实现通常具有这些特征：

如您所见，CDC 是一个相对简单的概念，范围非常狭窄。它只是将数据库的事务日志外部化为发送给感兴趣的消费者的事件流。

CDC 也为您提供了事件消费方式的灵活性。根据图 4：

最后，CDC 实现通常具有这些特征：

CDC 在多种用例中都非常灵活且适应性强。CDC 的早期采用者选择选项 1/A，但随着 CDC 的势头增长，选项 1/B 和选项 2 也越来越受欢迎。

Outbox 模式的主要目标是确保应用程序状态（存储在表中）的更新和相应领域事件的发布在单个事务中完成。这涉及到在数据库中创建一个 Outbox 表，在事务中收集这些领域事件。对领域事件及其通过 Outbox 的传播进行事务保证对于跨系统的数据一致性很重要。

事务完成后，领域事件将被 CDC 连接器捕获，并通过可靠的消息代理转发给感兴趣的消费者（参见图 5）。然后，这些消费者可以使用领域事件来具体化自己的聚合（参见上面关于事件溯源的部分）。

Outbox 的目的是从应用程序中抽象出来，因为它只是一个短暂的传出事件数据存储，不供应用程序读取或查询。事实上，Outbox 中的领域事件可能在插入后立即被删除！

现在我们可以仔细看看事件溯源日志和 CDC 与 Outbox 在设计上的重叠。通过比较日志的属性和 Outbox 表，相似之处就变得很清楚了。Aggregate（再次来自 DDD）是 Outbox 和事件溯源中数据存储和消费的核心。

以下是事件溯源日志和 Outbox 之间存在的共同属性：

Outbox 表和事件溯源日志在数据格式上基本相同。主要区别在于，事件溯源日志旨在成为永久且不可变的领域事件存储，而 Outbox 则旨在高度短暂，仅作为捕获领域事件并将其转发给下游消费者的变更事件的落地区域。

命令查询责任分离模式，简称 CQRS，通常与事件溯源相关联。但是，事件溯源并非使用 CQRS 的必要条件。例如，CQRS 模式也可以使用 Outbox 模式来实现。

那么 CQRS 到底是什么？它是一种创建数据替代表示（称为 projection，即视图）的模式，其主要目的是为了创建只读、可查询的视图。对于同一数据集，可能存在多个供不同客户端使用的视图。

CQRS 的命令方面适用于处理动作（Commands）并最终生成领域事件的应用程序，这些领域事件可用于为 projection 创建状态。这也是 CQRS 经常与事件溯源关联的原因之一。

CQRS 与事件溯源搭配良好的另一个原因是因为日志本身是不可查询的。在事件溯源系统中查询数据的唯一可行方法是通过 projections。请注意，这些 projections 是最终一致的。这带来了灵活性，但也带来了复杂性，并偏离了开发者可能熟悉的强一致性视图。

正如您在图 6 和图 7 中所见，这是基于事件溯源的 CQRS 模式的两种截然不同的解释，但最终结果是相同的：源自事件的可查询数据 projection。

如前所述，CQRS 也可以与 Outbox 模式搭配使用，如图 8 所示。这种设计的优势在于应用程序数据库内部仍保持强一致性，而 CQRS projections 保持最终一致性。

虽然本文非常侧重于跨系统分发数据，但将领域事件用于应用程序内部同样重要。出于各种原因，内部处理领域事件是必要的，包括在事件源自的同一个微服务上下文中执行业务逻辑。这是构建事件驱动应用程序的常见做法。

无论使用事件溯源还是 CDC，内部处理领域事件都需要一个分发机制来在内存中传递事件。一些例子包括 Vert.x EventBus、Akka Actor System 或 Spring Application Events。在 Outbox 模式的情况下，事件将在初始 Outbox 事务成功完成后才会被分发。

本文信息量很大，因此总结一下到目前为止所介绍内容的表格可能会有所帮助。

现在我们对事件溯源和 CQRS 有了更好的理解，让我们来检查一下事件溯源与 CQRS 搭配使用的一些优缺点。这些优缺点考虑了当前可用的实现以及我自己和其他专业人士在构建分布式系统方面的经验和记录。

Debezium 是红帽公司支持的一个开源 CDC 项目，近年来逐渐受到欢迎。最近，Debezium 通过 Quarkus Java 微服务运行时的一个扩展，增加了对 Outbox 模式的全面支持。

Debezium、Quarkus 和 Outbox 提供了一个全面的解决方案，该方案避免了双重写入缺陷，与事件溯源解决方案相比，对于普通开发团队来说通常是更实用的解决方案。

构建分布式系统（即使是微服务）也可能非常具有挑战性。这就是为什么像事件溯源这样的新颖解决方案具有吸引力。然而，使用 Debezium 的 CDC 和 Outbox 通常是事件溯源的更好替代方案，并且还可以与 CQRS 模式兼容。虽然事件溯源在某些用例中可能仍有价值，但我鼓励您首先尝试 Debezium 和 Outbox。