使用数据库 CDC 的事件溯源是否被认为是好的架构？

Question

当我们谈论采购事件时，我们有一个简单的双写架构，我们可以写入数据库，然后将事件写入队列，如 Kafka。其他下游系统可以读取这些事件并相应地对它们采取行动/使用它们。

但是当试图使数据库和事件同步时会出现问题，因为需要对这些事件进行排序才能使其有意义。

为了解决这个问题，人们鼓励使用数据库提交日志作为事件源，并且有围绕它构建的工具，例如 Airbnb 的 Spinal Tap、Redhat 的 Debezium、Oracle 的 Golden Gate 等……它解决了一致性、排序保证和所有这些。

但是使用数据库提交日志作为事件源的问题是我们与数据库模式紧密耦合。微服务的数据库架构是公开的，数据库架构中的任何破坏性更改，如数据类型更改或列名更改，实际上都可能破坏下游系统。

那么使用 DB CDC 作为事件源是个好主意吗？

关于这个问题和使用 Debezium 进行事件溯源的讨论

Answer 1

如果您使用事件源：

那么耦合就不应该存在。事件存储是通用的，它不关心聚合的内部状态。最坏的情况是与事件存储本身的内部结构相结合，但这并不是特定于特定的微服务。

如果您不使用事件源：

在这种情况下，聚合的内部结构和 CDC 组件（捕获数据更改并将事件发布到消息队列或类似组件）之间存在耦合。为了限制这种耦合对微服务本身的影响，CDC 组件应该是其中的一部分。这样，当微服务中聚合的内部结构发生变化时，CDC组件也会发生变化，而外界不会注意到。两项更改同时部署。