1. 事件驱动架构与Confluent平台导入

在传统请求—响应式系统里，一个业务动作往往由调用方主动发起，被调用方同步返回结果。订单服务调用库存服务扣减库存，库存服务再调用支付服务完成扣款，整条链路被“调用栈”串起来。只要下游某个服务变慢或不可用，上游就会被拖住，扩容也只能按最慢的环节来估算。事件驱动架构（Event-Driven Architecture，EDA）换了一种组织方式：业务动作被表达为“已经发生的事实”，也就是事件，由生产者发布到事件流平台，消费者按自己的节奏订阅和处理。调用方不再等待结果，而是把“发生了什么”交给平台去传播。

理解 EDA，先要区分三个容易混淆的概念。事件（Event）是对已发生事实的不可变记录，例如 OrderPlaced、PaymentCaptured，它描述过去，通常带唯一标识、时间戳和业务载荷。命令（Command）是希望对方做某事的请求，例如 ReserveInventory，它面向未来，可能被拒绝。消息（Message）是传输层的泛称，事件和命令都可以是消息。事件驱动系统强调以事件为中心：生产者只负责如实发布，不关心谁消费；消费者只关心自己订阅的事件类型，不反向依赖生产者。这种“发布—订阅”的解耦带来三个直接收益：时间解耦（消费者可离线后补）、空间解耦（双方互不知道地址）、实现解耦（各自独立选型与部署）。代价是最终一致性、重复投递和顺序问题需要被认真设计，而不是被隐藏。

事件流平台是承载这套机制的底座。它需要具备几项能力：持久化存储事件而不是消费后即删、支持多消费者各自读取同一份数据、按分区保证局部有序、可水平扩展吞吐、能长期保留以便重放。Apache Kafka 是这类平台的事实标准，而 Confluent 是在 Kafka 之上构建的企业级事件流平台。可以把二者关系理解为：Kafka 提供核心的分布式日志与复制协议，Confluent 补齐了让它在企业中可运维、可治理、可连接、可实时计算的部分。

上图把平台分层与课程路径放在一起看：左侧是生产者，中间是 Confluent 平台，右侧是消费者，底部是 30 章的学习推进顺序。需要特别注意的是，Confluent 的价值并不只是“跑一个 Kafka 集群”。Kafka 核心负责 Topic、Partition、副本和偏移量这些底层机制；Connect 负责把数据库、对象存储等外部系统接入事件流；ksqlDB 与 Flink 负责在流上做过滤、聚合和连接；Schema Registry 与治理能力负责契约、权限和可观测性。这四块合起来，才构成企业里真正可用的事件流平台。

用一个具体例子来体会事件驱动与请求响应的差别。假设电商下单场景，请求响应式做法是订单服务依次调用库存、支付、通知三个接口，任一失败都要补偿。事件驱动做法是订单服务只向 orders 主题写入一条 OrderPlaced 事件，库存服务订阅后扣减并发布 InventoryReserved，支付服务订阅后扣款并发布 PaymentCaptured，通知服务订阅这些事件后发短信。订单服务不关心下游有几个、是否在线。如果通知服务临时宕机，事件仍在主题中保留，恢复后从上次偏移量继续消费即可，不会丢单。这就是“持久化 + 偏移量 + 可重放”带来的弹性。

当然，事件驱动不是免费的。同一事件可能被重复投递，消费者必须做幂等处理，例如用事件 ID 去重；跨分区不保证全局顺序，需要按业务键（如订单号）分区来保证同一订单的事件有序；事件结构一旦发布就很难随意修改，因此要用 Schema Registry 管理兼容性。这些正是后续章节要重点解决的问题。

本课程的整体路径按“先建立认知、再动手实现、最后治理与实战”推进。第 1–4 章建立事件驱动概念与 Confluent 平台定位，理解 Kafka 核心模型；第 5–12 章进入主题设计、生产者与消费者的实际编码，掌握分区、偏移量提交、幂等与重试；第 13–20 章学习 Connect 与流处理，把外部系统和实时计算接入；第 21–26 章聚焦 Schema Registry、安全、监控与可靠性治理；第 27–30 章通过综合案例把前面能力串成完整系统。学完本课程，你应当能够独立设计一个主题结构合理、消费者可靠、契约可治理的事件驱动系统，并能在 Confluent 平台上把它跑起来、看清楚、维护好。