基于Kafka Streams实现CQRS/事件溯源POC的技术咨询

最近我正在尝试用Kafka Streams搭建一个CQRS+事件溯源的概念验证项目，梳理了一套基础的组件架构，跟大家分享下我的规划：

核心组件规划 #

• Commands Topic：将聚合ID作为消息的键，这样Kafka会把同一聚合实例的所有命令路由到同一个分区，保证命令按顺序被处理，避免同一聚合的命令乱序执行引发状态不一致的问题。
• Events Topic：同样以聚合ID为键，所有聚合状态的变更操作都会被发布到这个主题中。我给这个主题设置了永不删除的保留策略——毕竟事件溯源的核心就是依赖完整的历史事件流来重建状态，任何历史事件都不能随意丢失。
• 聚合状态KTable：通过消费Events Topic的事件流，利用Kafka Streams的reduce操作实时归约计算每个聚合实例的最新状态。这个KTable相当于CQRS架构中查询端的“单一事实源”，后续可以基于它构建各种面向查询的读模型（比如供前端展示的视图）。
• 命令处理流（Command Processing Stream）：作为衔接Commands和Events的核心环节，它消费Commands Topic中的命令，先基于KTable里的当前聚合状态做合法性校验（比如拒绝针对已终止聚合的操作命令），校验通过后生成对应的事件并发送到Events Topic，同时触发KTable的状态更新。

关键设计细节 #

• 所有与聚合相关的消息（命令、事件）都绑定聚合ID作为键，确保同一聚合的消息落在Kafka的同一个分区内，从底层保障顺序性。
• Events Topic除了设置永久保留策略外，也可以开启日志压缩来优化存储成本，但必须确保不会丢失任何历史事件记录。
• KTable的状态会持久化到Kafka的状态存储中，即使应用重启也能快速恢复到最新状态，无需从头全量消费事件（当然如果需要全量重建状态，也可以重置消费位点从头消费）。

内容的提问来源于stack exchange，提问作者amitayh