BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

事件架构和事件流

| 作者 Jan Stenberg 关注 34 他的粉丝 ,译者 盖磊 关注 2 他的粉丝 发布于 2017年9月11日. 估计阅读时间: 3 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT