Debezium 博客

当我开始研究 Debezium 时,我脑海中浮现出两个问题:能否构建 Debezium 的原生版本?我能否在不依赖额外基础设施的情况下,直接在我的微服务中接收变更数据捕获 (CDC) 事件?

这促使我们开发了一个新的 Debezium 流:我很高兴地宣布 **Debezium Extensions for Quarkus** 的第一个版本!

变更数据捕获(CDC)在各种场景中被广泛使用,例如微服务通信、遗留系统现代化和缓存失效。此模式的核心思想是检测和跟踪数据源(例如数据库)中的更改,并将其实时或近实时地传播到其他系统。Debezium 是一个 CDC 平台,为大多数数据源提供了广泛的连接器。除了捕获更改之外,它还通过... 提供转换功能。

Kafka Streams 是一个用于开发基于 Apache Kafka 的流处理应用程序的库。引用其文档,“Kafka Streams 应用程序通过拓扑实时处理记录流,以逐条记录的方式持续、并发地处理数据”。Kafka Streams DSL 提供了一系列流处理操作,例如 map、filter、join 和 aggregate。

Kafka Streams 中的非键连接

Debezium 的 CDC 源连接器可以轻松地捕获数据库中的数据变更,并近乎实时地将其推送到 Elasticsearch 等接收系统。默认情况下,这会在源数据库的表、相应的 Kafka 主题以及接收端的数据表示(例如 Elasticsearch 中的搜索索引)之间产生一对一的关系。

在 1:n 关系的情况下,例如客户表和地址表之间,消费者通常对一种数据视图感兴趣,该视图是单个、嵌套的数据结构,例如表示客户及其所有地址的单个 Elasticsearch 文档。

这就是 KIP-213(“Kafka 改进提案”)及其外键连接能力的作用所在:它是在 Apache Kafka 2.4 中引入的,“以弥合 Streams 中的 KTables 与关系数据库中的表之间的语义差距”。在 KIP-213 之前,为了连接两个 Debezium 变更事件主题的消息,您通常需要手动重新键入至少一个主题,以确保连接的双方使用相同的键。

得益于 KIP-213,这不再需要了,因为它允许在从 Kafka 消息值中提取的字段上连接两个 Kafka 主题,以完全透明的方式自动处理所需的重新键入。与之前的方法相比,这大大减少了从 Debezium 的 CDC 事件创建聚合事件的工作量。

Debezium 的一个典型用例是使用变更数据捕获将一个遗留系统与组织中的其他系统集成。有多种方法可以实现此目标

  • 使用 Debezium 将数据写入 Kafka,然后通过 Kafka Streams 流水线和 Kafka Connect 连接器的组合将变更传递到其他系统

  • 在 Java 独立应用程序中使用Debezium Embedded engine,并使用纯 Java 编写集成代码;这通常用于将变更事件发送到其他消息基础设施,例如 Amazon Kinesis、Google Pub/Sub 等。

  • 使用现有的集成框架或服务总线来表达流水线逻辑

本文重点介绍第三种选择——专用的集成框架。

尽早发布,频繁发布!在早些时候的 1.1 Beta1 和 1.0.1 Final 版本之后,我今天很高兴地分享 Debezium 1.1.0.Beta2 发布的消息!

Beta2 的主要新增功能是对使用 Testcontainers 集成测试您的变更数据捕获 (CDC) 设置的支持。此外,用于实现 outbox 模式的 Quarkus 扩展以及用于提取变更事件的 after 状态的 SMT 已经过重新设计,现在提供了更多的配置灵活性。

本文将深入探讨事件溯源、CQRS(命令查询责任分离)、CDC(变更数据捕获)和 Outbox 模式。将清晰地阐述这些解决方案的价值。此外,还将详细解释两种不同的设计,并分析它们的优缺点。

那么,为什么所有这些解决方案都很重要呢?它们很重要,因为许多团队正在构建微服务并将数据分布在多个数据存储中。一个微服务系统可能涉及关系数据库、对象存储、内存缓存,甚至可搜索的数据索引。数据很容易丢失、不同步甚至损坏,从而对关键任务系统造成灾难性后果。

对于许多组织来说,有助于避免这些严重问题的解决方案至关重要。不幸的是,许多重要的解决方案有些难以理解;事件溯源、CQRS、CDC 和 Outbox 也不例外。请将这些解决方案视为学习和理解如何将其应用于您特定用例的机会。

正如您将在本文结尾处发现的那样,我将建议其中四个解决方案中有三个具有很高的价值,而另一个应尽可能避免使用,除非在极少数情况下。本文提供的建议应根据您的具体需求进行评估,因为在某些情况下,这四个解决方案都不适合。

Outbox,就像我电子邮件客户端中的那个文件夹一样?不,不完全是,但有一些相似之处!

Outbox 这个术语描述了一种模式,它允许独立组件或服务执行读取您自己的写入语义,同时在组件或服务边界之间提供对这些写入的可靠、最终一致的视图。

您可以在我们的博客文章《使用 Outbox 模式实现可靠的微服务数据交换》中阅读有关 Outbox 模式及其在微服务中的应用的更多信息。

那么,Outbox 事件路由器到底是什么?

在 Debezium 版本 0.9.3.Final 中,我们引入了一个即用型单消息转换 (SMT),它构建在 Outbox 模式之上,用于通过 Debezium 和 Kafka 传播数据变更事件。有关如何使用此转换的详细信息,请参阅文档

上周宣布Quarkus 以来,在 Java 社区引起了极大的兴趣:它由最优秀的 Java 库和标准构建而成,支持构建基于 GraalVM 和 OpenJDK HotSpot 的 Kubernetes 原生应用程序。在这篇博文中,我们将演示基于 Quarkus 的微服务如何通过 Apache Kafka 消费 Debezium 的数据变更事件。为此,我们将看看如何将我们最近关于Outbox 模式的帖子中的运输微服务转换为基于 Quarkus 的服务。

版权所有 © Debezium 及其作者。保留所有权利。有关我们的商标详情,请访问我们的 商标政策商标列表。第三方商标属于其各自所有者,在此提及并不表示任何认可或关联。
×