📚 课程目录第2章 Confluent平台架构解析

2. Confluent平台架构解析

Confluent Platform 并不是一个单一软件，而是围绕 Apache Kafka 构建的一整套企业级数据流平台。理解它的关键，不是记住每个组件的名字，而是看清一条数据从产生、传输、治理、加工到被观测的完整路径上，各个模块分别站在哪个位置、承担什么职责、彼此通过什么接口协作。本节以一条典型的订单事件流为主线，把 Kafka、Schema Registry、Kafka Connect、ksqlDB 和 Control Center 串成一个可理解的协作整体。

一、Kafka：数据中枢与持久化日志

Kafka 是整个平台的地基，它的本质是一个分布式的、可持久化的提交日志（Commit Log）。生产者把消息追加到某个 Topic 的分区末尾，消费者按偏移量（Offset）顺序读取。分区决定了并行度，副本决定了容错能力。以订单场景为例，可以设计 orders 主题，设置 6 个分区、副本因子 3，键为 order_id，这样同一订单的事件会落到同一分区，保证局部有序。

Kafka 只负责“可靠地存和传”，它不理解消息内容的语义，也不做格式校验。这正是其他模块存在的理由：Schema Registry 补上语义约束，Connect 补上系统对接，ksqlDB 补上流式加工，Control Center 补上可观测性。

二、Schema Registry：消息契约的守门人

当生产者写入 JSON 或 Avro 数据时，如果没有统一契约，下游消费者很容易因为字段改名、类型变化而崩溃。Schema Registry 独立于 Broker 运行，为每个 Subject（通常对应 Topic-value 或 Topic-key）维护版本化的 Schema，并分配全局唯一的 Schema ID。

生产者发送消息时，消息体前会附带这个 Schema ID；消费者拉取后，用 ID 向 Registry 反查 Schema 完成反序列化。兼容性策略是这里的核心参数：BACKWARD 允许新增带默认值的字段、删除字段；FORWARD 允许删除字段、新增字段；FULL 则两者都要求。例如订单 Schema 从 v1 增加一个带默认值的 coupon_code 字段，在 BACKWARD 策略下可以顺利注册为 v2，老消费者仍能读取新消息。若把 amount 从 int 改成 string，则会被拒绝注册，从而在写入前就拦截了破坏性变更。

三、Kafka Connect：系统之间的搬运工

Connect 解决的是“Kafka 与外部系统之间如何稳定同步数据”。它分为 Source（外部系统 → Kafka）和 Sink（Kafka → 外部系统）两类连接器，运行时以 Worker 集群方式部署，通过 Converter 与 Schema Registry 协同完成序列化。

例如用 Debezium PostgreSQL Source Connector 捕获订单库的 CDC 变更写入 orders，再用 JDBC Sink Connector 把 orders 写入数据仓库。关键参数包括 tasks.max（并行任务数）、topic.prefix、key.converter 和 value.converter。Connect 的价值在于把大量重复的“读—转换—写”逻辑标准化，避免为每个系统手写生产者消费者代码。

四、ksqlDB：在流上直接做 SQL 加工

ksqlDB 让开发者用 SQL 表达持续计算。它把 Kafka Topic 映射为 STREAM（追加事件流）或 TABLE（变更日志视图），支持过滤、聚合、连接和窗口。例如从 orders 中筛选已支付订单并统计每分钟金额：

CREATE STREAM paid_orders AS
  SELECT order_id, amount, order_time
  FROM orders
  WHERE status = 'PAID'
  EMIT CHANGES;

CREATE TABLE revenue_per_min AS
  SELECT windowstart AS ws, SUM(amount) AS total
  FROM paid_orders
  WINDOW TUMBLING (SIZE 1 MINUTE)
  GROUP BY windowstart
  EMIT CHANGES;

执行后，ksqlDB 会在后台持续运行查询，把结果写入新的 Topic，下游可直接消费。它把原本需要编写流处理程序的逻辑，压缩成声明式 SQL，显著降低了实时加工门槛。

五、Control Center：统一观测与治理入口

Control Center 是运维与治理的图形化入口，它把 Broker、Topic、Consumer Group、Connect 任务、ksqlDB 查询和 Schema 集中展示。通过它可以看到消费滞后（Consumer Lag）、分区分布、连接器状态和 Schema 版本历史。当某个 Sink 任务失败或某消费者组滞后飙升时，Control Center 是定位问题的第一站。

六、模块协作全景

把上述模块放回同一条数据链路，可以看到清晰的分工：外部数据库经 Connect Source 进入 Kafka，Schema Registry 在写入与读取两端校验契约，ksqlDB 对 Topic 做实时加工并产出新 Topic，Connect Sink 再把结果导出到仓库或搜索系统，Control Center 全程观测。下图展示了这一协作关系。

七、协作中的关键判断

理解架构之后，实际落地时还要回答几个问题。第一，Schema 兼容策略选哪种？如果消费者和生产者由不同团队维护、升级节奏不一致，优先选 BACKWARD，让新生产者不破坏老消费者。第二，Connect 任务并行度怎么定？tasks.max 不应超过源表可切分的分片数或目标 Topic 分区数，否则多余任务空转。第三，ksqlDB 的中间 Topic 要不要持久化？默认会创建，若只是临时聚合可考虑缩短保留时间以节省存储。第四，Control Center 的告警阈值应围绕 Consumer Lag 和连接器任务状态设置，而不是只看 Broker 是否存活。

一条经验规则：Kafka 负责“不丢”，Schema Registry 负责“不乱”，Connect 负责“不重写”，ksqlDB 负责“不落地也能算”，Control Center 负责“不瞎猜”。五者各守一段，才构成企业级数据集成闭环。

把这条链路记牢，后续无论是设计 Topic、排查消费滞后，还是新增一个数据源，都能迅速判断该动哪个模块、改哪个参数、看哪个界面。