2. Confluent平台架构与核心组件
Confluent Platform 与 Confluent Cloud 虽然交付形态不同，但共享同一套逻辑架构。理解这套架构的关键，不是记住组件名称，而是看清一条事件从产生到被消费、被治理、被查询的完整路径上，每个组件站在什么位置、承担什么职责、彼此通过什么接口协作。本节先建立分层视角，再逐层拆解核心组件，最后用一张组件协作图把数据流与控制流串起来。
一、分层视角：从存储内核到治理平面
Confluent 的架构可以自上而下分为四层，每层解决不同问题：
- 存储与复制层：由 Broker 组成，负责分区日志的持久化、副本同步与读写服务，是整个平台的“事实来源”。
- 集群控制层：由 Controller（KRaft 模式）承担元数据管理、分区领导者选举与集群成员协调，替代了早期 ZooKeeper 的角色。
- 数据集成与处理层：Connect 负责系统间数据搬运，ksqlDB 负责流式 SQL 处理，二者都直接读写 Broker 中的 Topic。
- 治理与元数据层：Schema Registry 管理数据契约，Stream Governance 提供血缘、目录、质量与策略控制，横跨所有层。
这四层不是简单的调用栈，而是“数据面”与“控制面”的交织：Broker 与 Connect、ksqlDB 之间流动的是真实事件数据；Controller、Schema Registry、Stream Governance 之间流动的是元数据、契约与策略。区分这两类流，是排查问题时定位方向的第一步。
二、Broker：分区日志的持有者
Broker 是 Kafka 的存储与读写服务进程。每个 Topic 被切分为若干 Partition，每个 Partition 是一个追加写的有序日志，分布在多个 Broker 上。以三节点集群、Topic orders 设置 6 个分区、副本因子 3 为例：6 个分区领导者会尽量均匀分散到 3 台 Broker，每个分区另有 2 个跟随副本。生产者写入时只与领导者交互，跟随副本持续拉取并确认，只有进入 ISR（同步副本集合）的副本才有资格在领导者故障时被选为新领导者。
Broker 的关键参数直接影响可用性与吞吐：num.partitions 决定默认分区数，default.replication.factor 决定默认副本数，min.insync.replicas 与生产者 acks=all 配合决定写入耐久性。例如设置 min.insync.replicas=2 且 acks=all，意味着至少 2 个副本确认才算写入成功；若可用副本不足 2 个，写入会被拒绝而不是静默降级，这是防止数据丢失的重要保护。
三、Controller：集群的大脑
在 KRaft 模式下，一部分节点同时充当 Controller 角色，通过 Raft 协议维护一份集群元数据日志。它负责：分区领导者选举、Broker 上下线感知、Topic 创建与删除、配置变更。Controller 不参与实际消息读写，因此它的负载与数据面吞吐无关，但与集群变更频率强相关。生产环境中，Controller 节点应使用独立、稳定的硬件，避免与高吞吐 Broker 混部导致元数据操作延迟。
四、Connect：把外部系统接入事件流
Connect 是一个分布式集成框架，通过 Source Connector 把外部系统数据写入 Kafka，通过 Sink Connector 把 Kafka 数据写出到外部系统。它自身也是 Kafka 的客户端：连接器配置、偏移量、状态都存储在内部 Topic 中（如 connect-configs、connect-offsets、connect-status），因此 Connect 集群可以水平扩展并具备故障恢复能力。
以 MySQL 到 Kafka 的同步为例，使用 Debezium MySQL Source Connector，关键配置包括：
{
"name": "mysql-orders-source",
"config": {
"connector.class": "io.debezium.connector.mysql.MySqlConnector",
"database.hostname": "mysql.internal",
"database.port": "3306",
"database.user": "debezium",
"database.password": "******",
"database.server.name": "mysql-prod",
"table.include.list": "shop.orders,shop.order_items",
"topic.prefix": "cdc",
"tasks.max": "2",
"key.converter": "io.confluent.connect.avro.AvroConverter",
"value.converter": "io.confluent.connect.avro.AvroConverter",
"value.converter.schema.registry.url": "http://schema-registry:8081"
}
}这里 tasks.max=2 表示最多并行 2 个任务；table.include.list 限定捕获范围；转换器指向 Schema Registry，使写入的 Avro 消息自动注册并携带 schema ID。运行后可通过 GET /connectors/mysql-orders-source/status 查看连接器与任务状态，若任务 state 为 RUNNING 且 trace 为空，说明同步正常。
五、Schema Registry：数据契约的守门人
Schema Registry 为 Avro、Protobuf、JSON Schema 提供集中式 schema 存储与兼容性检查。生产者发送消息时，序列化器向 Registry 注册 schema 并获得全局唯一 ID，消息体中只携带该 ID；消费者反序列化时用 ID 取回 schema。兼容性策略（BACKWARD、FORWARD、FULL、NONE）决定新 schema 能否注册。例如默认 BACKWARD 策略下，新增带默认值的字段是允许的，删除无默认值字段则会被拒绝。这保证了消费者升级前生产者不会破坏其解析能力。
六、ksqlDB 与 Stream Governance
ksqlDB 提供流式 SQL 引擎，把 Kafka Topic 抽象为 STREAM 与 TABLE，支持持续查询、聚合、连接与物化视图。它内部以 Kafka Streams 为执行引擎，查询结果可写回新 Topic。Stream Governance 则包含 Schema Registry、Stream Catalog、Stream Lineage 与 Stream Quality：Catalog 让用户搜索与发现数据资产，Lineage 追踪字段级血缘，Quality 基于规则检测数据异常。它们共同把“能跑通”升级为“可管理、可审计、可信任”。
七、协作关系与排障切入点
把上述组件放回一条真实链路：MySQL 业务库产生订单变更，Debezium Source Connector 捕获 binlog 并写入 cdc.shop.orders；写入前 Avro 序列化器向 Schema Registry 注册 schema；Broker 按分区持久化并同步副本；ksqlDB 订阅该 Topic 做实时聚合，结果写入 orders_summary；Sink Connector 再把汇总结果写入 Elasticsearch 供看板查询；Stream Lineage 记录从 MySQL 字段到 ES 索引的完整血缘。
当链路异常时，分层视角能快速缩小范围：消费者报 schema 不兼容，先查 Schema Registry 的兼容性策略与最近注册记录；写入超时且 NotEnoughReplicas，查 ISR 是否低于 min.insync.replicas；分区领导者频繁切换，查 Controller 日志与 Broker 网络；连接器任务反复重启，查 Connect 状态接口中的 trace 字段。先判断问题属于数据面、控制面还是治理面，再进入对应组件，比盲目重启高效得多。