事件架构和事件流

将一个单体系统迁移到分布式系统或微服务系统，通常也是从源于同一数据库的单一数据源（SSOT，Single Source Of Truth）转变为源自多数据库的多个数据源。如果使用事件架构（Event Architecture）并将所有事件持久化为数据流，那么就我们可以转回到单一数据源上。这是 Ben Stopford 在他撰写的博客文章中提出的，此篇博客是他关于如何在 Kafka 中使用事件的系列博文之一。

Stopford 是 Confluent 公司的一名工程师他在博文中指出，传统的消息系统中，事件是短暂存在的，已消费的事件并没有历史信息。持久化所有的事件不仅会创建单一数据源，而且可以回溯和重放事件，使得对数据可执行似于版本管理系统中那样的操作。这使得恢复崩溃的系统以及在修复软件故障后重放事件成为可能。

对于一个典型的基于事件的系统，它会对事件进行监听，更新事件在数据库中的状态并做持久化，进而发出新的事件。在 Stopford 看来，这一架构具有两个挑战。首先，如何在同时写入数据和事件日志时维护一致性。其次，因为存在不同的代码路径等原因，在数据库中的和事件中的数据会出现一些偏差，这可能会导致系统中的不一致问题。解决问题的最好方法是类似于在事件溯源系统中那样，将事件作为头等实体并仅使用事件。

要着手实现事件流，一个途径是使用“变更数据捕获 ”（Change Data Capture）技术。采纳了这一技术的数据库正在不断增加。使用CDC，对数据库的写入将在后台转换为事件流。Stopford 在文章中提及，CDC 的一个优点就是提供了一致点。我们可以对数据库做读写操作，无需分布式事务就让事件流保持数据库和数据流的同步。

Stopford 提供了一个 CDC 的重要用例，就是实现旧架构的迁移。通过使用 CDC 连接到遗留系统的数据库，他们抽取出了事件流，并从使用遗留系统逐步迁移到使用事件流的系统。

在使用事件溯源和事件流中，一个非常有用的模式就是对事件的两次持有。其中一次在基于保留（Retention）的消息类（Topic）中。此类消息按时间顺序保留了每次更改，用于事件溯源视图中。另一次是在压缩消息类（Compacted Topic）中，该类消息类仅提供实体的最新视图，因此规模更小，速度更快。

文末 Stopford 做了总结，指出基于流的事件架构的最显著特性是可不断进化的能力。一旦有新的需求出现，系统就能构建出新的服务，进而轻易地进行部署，并通过从头开始重放所有的事件而维持更新状态。他相信，考虑到 Kafka 所能提供的功能，它非常适用于此类架构之中。

查看英文原文： Event Architectures and Event Streaming