企业做实时决策，等不起几小时后的批量报表。欺诈检测、支付系统、IoT监控——这些场景里，事件驱动架构（EDA）已经从"时髦方案"变成了基础设施。但问题在于：多数企业把EDA当批处理的替代品，而非互补的另一种架构思维。
批处理没死。历史数据归档、月末财务结算、大规模离线转换，这些仍是批处理的强项。EDA真正的战场，是数据持续流动、决策不能等待、系统必须秒级响应的场景。用错了地方，是技术债；用对了设计错，是灾难。
我见过太多"先开个Kafka Topic，让系统往那儿写"的草率决定。三个月后，Topic无序膨胀、事件归属模糊、数据流向无法追踪、消费者耦合成一团乱麻。流处理没带来实时性，反而带来了实时混乱。
这个系列回答两个核心问题：事件本身如何设计？事件在平台内如何成熟演化？
第一篇聚焦事件本体——事件与命令的边界、Kafka的Topic/Channel模型、Schema契约、分区键选择、生产者-消费者关系，以及那些反复出现的设计陷阱。第二篇将深入事件的生命周期：从原始事件到精选事件的管道、死信队列与告警Topic、重放机制、监控治理，以及与现代Lakehouse架构中Medallion模型的衔接。
先厘清基础概念。事件驱动架构中，系统间不直接调用，而是通过"发生了什么"来通信。一个事件是系统中已发生的、有意义的事实：客户已创建、支付已完成、库存已告急、传感器温度已超限。它是不可变的声明，而非指令。
这与"命令"有本质区别。命令是"去做某事"的请求，可以被拒绝、可以失败、需要确认。事件是"某事已发生"的通知，已经发生，无法撤销。混淆两者，是EDA设计中最昂贵的错误之一——把命令包装成事件发送，系统会陷入"这个事件到底要不要处理、处理失败怎么办"的语义泥潭。
Kafka的Topic是逻辑通道，Partition是物理分片。设计时的一个关键决策：哪些事件进同一个Topic？按业务域聚合，还是按消费者聚合？按前者，生产者解耦，消费者可能收到无关事件；按后者，消费者精准，但每新增消费者就要新建Topic，爆炸式增长。
Schema契约是另一道防线。没有强制Schema的Topic，半年后就是数据沼泽。Avro、Protobuf、JSON Schema——选一种，强制执行，版本兼容规则写进CI流水线。分区键决定事件顺序保证的范围：同一键内有序，跨键无序。选错键，"同一订单的事件乱序到达"会在最糟的时机爆发。
生产者-消费者关系常被忽视。一个事件该有几个生产者？理论上唯一，实践中常因历史遗留打破。消费者端更复杂：独立消费组保证各自进度，但重复处理；共享消费组分担负载，但需处理分区再均衡。这些选择没有标准答案，但必须是有意识的选择，而非默认配置。
下一篇将讨论事件进入平台后的旅程——如何从原始、嘈杂、可能损坏的数据，逐步清洗、验证、丰富，成为可信的 curated 事件，最终流入实时分析或长期存储。这条管道的每个环节，都是失控与可控的分界线。
热门跟贴