3. 目标架构设计原则

迁移到 Confluent 平台，目标架构不是把旧集群“原样搬过去”，而是借迁移窗口重新确定集群拓扑、网络边界、存储与计算配比，以及安全合规基线。设计原则可以概括为四条：高可用按故障域分层、可扩展按瓶颈点预留、安全合规按数据流闭环、资源估算按峰值与增长双轨。下面按这四条展开，并给出可直接套用的估算方法。

一、集群拓扑：先定故障域，再定集群数量

Confluent 平台的目标拓扑通常由三类角色构成：Kafka Broker（含 KRaft Controller 或 ZooKeeper）、Confluent Schema Registry / Connect / ksqlDB 等组件、以及 Confluent Control Center 与监控栈。拓扑设计的第一步不是选机器，而是确定故障域边界：一个集群至少要跨 3 个可用区（AZ），每个 AZ 内 Broker 数量尽量均等，副本因子设为 3，min.insync.replicas 设为 2。这样单 AZ 故障时仍能读写，且不会因副本不足而阻塞生产。

集群数量取决于隔离需求。若业务线之间要求故障隔离、配额隔离或合规隔离，建议按“生产 / 非生产”至少拆两套，生产内部再按业务域拆分。拆分过多会带来跨集群复制（Cluster Linking 或 Replicator）成本和运维复杂度，拆分过少则单集群爆炸半径过大。一个可操作的判断标准是：当单集群 Topic 数超过 5000、分区数超过 20 万、或日均峰值吞吐超过 1 GB/s 时，应评估拆分。这些是经验阈值，实际需结合 Broker 规格压测确认。

二、网络规划：打通三条路径，收敛一个入口

网络规划要同时满足客户端接入、集群间复制和运维管理三条路径。客户端接入推荐使用 Confluent 的 PrivateLink 或 Transit Gateway，避免暴露 Broker 公网地址；跨集群复制走专线或对等连接，并单独规划复制带宽，不与业务流量争抢。运维管理路径（Control Center、监控采集、Schema Registry）应放在管理网段，与业务数据面隔离。

端口与 DNS 要提前收敛。Kafka 默认 9092（PLAINTEXT/SASL_PLAINTEXT）、9093（SSL/SASL_SSL），KRaft Controller 使用 9093 或自定义端口。建议统一使用 SASL_SSL，并在 DNS 中为每个 Broker 配置可解析的稳定域名，避免迁移后因 IP 变化导致客户端重连失败。下面这张图给出一个跨 3 AZ、含复制链路与管理面的目标拓扑示意。

三、存储与计算资源估算：用峰值和增长双轨推算

资源估算最容易犯的错误是只按当前数据量算，忽略副本、保留期和增长。存储估算公式为：单 Topic 存储 = 日均消息量 × 平均消息大小 × 保留天数 × 副本因子 × (1 + 索引与压缩开销)。索引与压缩开销通常取 10%～20%，若启用 Tiered Storage，热数据保留 3 天、冷数据下沉对象存储，可显著降低 Broker 本地磁盘压力。

计算资源主要看吞吐和分区数。Broker 的瓶颈通常先出现在网络和磁盘 IO，而不是 CPU。经验上，单 Broker 可稳定承载 100～200 MB/s 的入站吞吐（具体取决于磁盘类型和消息大小），分区数建议单 Broker 不超过 4000 个。若目标集群峰值入站为 800 MB/s，按 150 MB/s/Broker 计算，至少需要 6 个 Broker；再考虑 30% 余量和单 AZ 故障，实际部署 9 个 Broker（每 AZ 3 个）较为稳妥。

下面给出一个可直接套用的估算示例表，参数均为教学假设值，实际需以压测为准。

四、安全合规：把控制点嵌入数据流

安全合规不是迁移后补的“外挂”，而应嵌入数据流每个环节。传输层统一 SASL_SSL，禁止 PLAINTEXT；认证使用 mTLS 或 OAuth，授权使用 RBAC + ACL 双层控制；敏感字段在生产者侧加密或脱敏，Schema Registry 启用兼容性检查，防止不合规 schema 进入。审计日志需覆盖认证、授权、Topic 创建删除和配置变更，并保留至少 180 天以满足常见合规要求。

五、设计原则的落地检查

把上述原则落到可执行层面，建议在架构评审时逐项确认：故障域是否跨 3 AZ、副本与 ISR 配置是否满足单 AZ 故障、接入是否收敛到统一入口、复制带宽是否独立、存储估算是否含副本与增长、Broker 数量是否含余量、安全控制是否覆盖传输/认证/授权/审计、合规约束是否在拓扑中体现。任何一项不满足，都应在迁移实施前修正，而不是等到割接窗口再处理。