将一个单体系统迁移到分布式系统或微服务系统,通常也是从源于同一数据库的单一数据源(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 所能提供的功能,它非常适用于此类架构之中。
评论