📚 课程目录第2章 Confluent平台与DataOps基础

2. Confluent平台与DataOps基础

在持续交付的语境下，Confluent 平台并不是一个单一产品，而是由多个可独立部署、又通过统一元数据与协议协同工作的组件构成。理解这些组件各自“交付什么对象”、运行在什么环境模型中，是设计 DataOps 流水线的前提。本节围绕 Confluent Cloud 与 Confluent Platform 的交付对象、环境模型，以及 Schema Registry、Connect、ksqlDB、Control Center 在持续交付中的角色展开。

一、两种交付形态：Cloud 与 Platform

Confluent Cloud 是托管服务形态，交付对象是“集群资源 + 托管组件”。用户通过 CLI、Terraform Provider 或 REST API 声明式地创建 Kafka 集群、Schema Registry、ksqlDB 应用、Connector 等资源，底层运维由 Confluent 承担。Confluent Platform 是自托管形态，交付对象是“软件包 + 配置 + 运行时进程”，需要用户自行管理节点、存储、网络与升级。两者共享同一套协议与 API，因此流水线中的 Schema、Connector 配置、ksqlDB 语句等制品可以在两种形态间迁移，但环境模型与权限边界不同。

在持续交付中，关键区别在于：Cloud 的“环境”通常对应 Confluent Cloud 的 Environment 与 Cluster 两级，配合 Service Account 与 API Key 做权限隔离；Platform 的环境则对应独立的集群或命名空间，配合 RBAC、ACL 与配置文件管理。流水线需要把“环境差异”抽象为变量，而不是把环境写死在制品里。

二、环境模型与制品晋级

典型的环境模型是 dev → staging → prod 三级。每一级对应一个独立的 Kafka 集群（或 Cloud Environment），并拥有独立的 Schema Registry 与 Connect 集群。制品晋级时，Schema 以 subject 为单位注册，Connector 以配置 JSON 为单位提交，ksqlDB 以 SQL 脚本为单位部署。环境之间的差异通过参数化配置注入，例如 bootstrap.servers、Schema Registry URL、API Key、topic 前缀等。

需要特别注意的是 Schema 的兼容性策略。在 dev 环境可以允许 BACKWARD 或 FULL 兼容，在 prod 环境通常要求 FULL_TRANSITIVE，以防止上游变更破坏下游消费者。流水线在晋级前应调用 Schema Registry 的兼容性检查接口，只有通过才允许注册到下一环境。

三、Schema Registry：契约的版本化交付

Schema Registry 在持续交付中承担“契约仓库”的角色。每个 topic 对应一个 subject，Schema 以版本号递增注册。流水线中，Schema 变更应作为独立制品提交，并附带兼容性检查。例如，新增一个带默认值的可选字段属于 BACKWARD 兼容，可以直接注册；删除必填字段则可能破坏消费者，需要先升级消费者再升级生产者。

实际操作中，可以在 CI 阶段调用兼容性检查接口：

curl -X POST -H "Content-Type: application/vnd.schemaregistry.v1+json" \
  --data '{"schema": "{\"type\":\"record\",\"name\":\"Order\",\"fields\":[{\"name\":\"id\",\"type\":\"string\"},{\"name\":\"amount\",\"type\":\"double\"},{\"name\":\"currency\",\"type\":\"string\",\"default\":\"CNY\"}]}"}' \
  http://schema-registry:8081/compatibility/subjects/orders-value/versions/latest

返回 {"is_compatible":true} 才允许进入注册阶段。这样就把“契约变更”纳入了与代码同等的质量门禁。

四、Connect：数据管道的声明式交付

Connect 集群负责在 Kafka 与外部系统之间搬运数据。持续交付中，Connector 以配置 JSON 为制品，通过 REST API 提交到目标 Connect 集群。配置中通常包含 connector.class、tasks.max、topics、连接器专属参数（如 JDBC URL、S3 桶名）以及转换器配置。环境差异通过变量替换注入，例如 dev 使用 dev-orders，prod 使用 prod-orders。

提交后应轮询 /connectors/{name}/status，确认 state 为 RUNNING 且 tasks 无 FAILED。若失败，流水线应阻断晋级并输出错误日志。

五、ksqlDB：流处理逻辑的版本化部署

ksqlDB 应用由一组 SQL 语句构成，包括 CREATE STREAM、CREATE TABLE、CREATE STREAM AS SELECT 等。持续交付中，SQL 脚本应纳入版本控制，部署时按顺序执行。由于 ksqlDB 不支持原地修改查询，变更通常采用“新建查询 + 迁移消费者 + 删除旧查询”的方式。流水线需要记录每个查询的 ID 与状态，确保部署幂等。

六、Control Center：可观测性与治理入口

Control Center 本身不直接参与制品部署，但它是持续交付的“验证与治理面板”。通过它可以看到 topic 的 Schema 版本、Connector 状态、ksqlDB 查询运行情况、消费者延迟等。在流水线的验证阶段，可以调用 Control Center 或底层 Metrics API 获取这些指标，作为晋级判断的依据。例如，staging 环境运行 10 分钟后，若消费者延迟低于阈值且无 Connector 失败，才允许晋级 prod。

七、环境模型与权限边界

在 Confluent Cloud 中，Environment 是资源隔离单元，Cluster 是计算单元，Service Account 与 API Key 控制访问。流水线应为每个环境使用独立的 Service Account，避免跨环境权限泄漏。在 Confluent Platform 中，则通过 RBAC 角色与 ACL 控制 topic、Schema、Connector 的读写权限。无论哪种形态，流水线都应遵循“最小权限”原则，只授予部署所需的权限。

环境差异应通过参数化配置注入，而不是修改制品本身。Schema 兼容性检查、Connector 状态轮询、ksqlDB 查询状态确认，是三个关键的晋级门禁。

综合来看，Confluent 平台的持续交付对象可以归纳为四类：Schema 契约、Connector 配置、ksqlDB SQL 脚本、环境参数。Schema Registry 负责契约版本化，Connect 负责数据管道声明式交付，ksqlDB 负责流处理逻辑部署，Control Center 负责验证与治理。环境模型则通过 dev/staging/prod 三级隔离，配合参数化配置与权限边界，实现制品的安全晋级。