事件架构和事件流

架构&设计

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

作者： Jan Stenberg

正文：

将一个单体系统迁移到分布式系统或微服务系统，通常也是从源于同一数据库的单一数据源（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