单Kafka Topic发布多属性员工旅程事件的方案可行性及替代方案咨询

核心优势分析 #

• 类继承+Jackson序列化的适配性
  父类Journey封装公共字段（id、name、type、date），子类LMSEvent等扩展专属字段，结合Jackson的@JsonTypeInfo和@JsonSubTypes注解，能基于type字段自动完成序列化/反序列化。Spring Boot环境下只需简单配置就能实现消息的正确类型转换，完全满足“保留对象自身属性”的需求。

• 策略模式消费的合理性
  消费者端用策略模式按type分发处理逻辑，代码解耦性强。后续新增事件类型时，只需添加对应的策略实现类，无需修改原有消费逻辑，符合开闭原则，适配你当前“事件新增属性有限”的场景，维护成本极低。

• 单Topic选型的适配性
  同属一个项目的员工旅程事件用单Topic管理完全合理，当前消息规模不大的情况下不会出现性能瓶颈，反而能简化Topic运维，避免多Topic带来的管理复杂度。

优化建议 #

• 序列化时明确配置@JsonTypeInfo：用use = JsonTypeInfo.Id.NAME、property = "type"，同时通过@JsonSubTypes绑定type值与对应子类，比如@JsonSubTypes.Type(value = LMSEvent.class, name = "LMS_EVENT")，避免后续扩展出现类型匹配混乱。
• 消费者端策略类自动注册：结合Spring的@Component注解和Map注入，让所有策略类自动被加载到策略容器中，减少手动配置工作量。
• 统一type字段枚举：定义EventType枚举类，包含所有事件类型的标准值（如LMS_EVENT），序列化时用枚举值作为type字段内容，避免拼写错误导致的消费异常。

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