摘要：此功能基于Kafka原生消息头部能力构建，并与Confluent Schema Registry深度集成。将模式ID迁移至Kafka消息头部前后的模式处理方式对比（来源：Confluent博客"）Confluent欧洲、中东及非洲地区的CSTA团队负责人Patrick Neff"在LinkedIn发文"，强调模式治理对于流式系统与分析平台数据复用的关键价值：模式是释放数据全部价值的核心基石。它还通过启用跨管道的结构化事件数据一致性重用，改善了与Apache Flink，以及分析或ML系统等工具的互操作性。

Confluent推出了一种Apache Kafka模式（schema）元数据的新管理方案"，支持将模式ID存储在消息头部，而非消息载荷中。该更新旨在简化数据治理，让企业无需改动现有事件格式，即可落地模式的校验能力。此功能基于Kafka原生消息头部能力构建，并与Confluent Schema Registry深度集成。该注册中心被大量企业广泛应用于微服务、分析流水线及数据平台的事件驱动架构治理场景。

在采用Confluent wire格式的传统Kafka部署中，模式ID会直接内嵌在消息载荷里。这种方式虽然能保障消费者正常反序列化事件，但会将模式元数据与业务数据强耦合。长期来看，这种耦合会增加模式演进的复杂度，多团队、多系统共用同一事件流的场景下尤为明显；同时，跨生产者、消费者进行模式变更时，也会大幅提升协同成本。

采用新方案后，模式标识存放于Kafka记录的头部，消息载荷保持原样不变。消费者运行时通过头部中的ID，从Schema Registry拉取对应模式完成解析。该方式兼容Avro"、Protobuf"、JSON Schema等主流格式，同时降低了对强耦合wire格式的依赖。模式解析逻辑与载荷彻底解耦，让事件流更灵活，更易于对接各类下游系统与工具链。

将模式ID迁移至Kafka消息头部前后的模式处理方式对比（来源：Confluent博客"）

Confluent欧洲、中东及非洲地区的CSTA团队负责人Patrick Neff"在LinkedIn发文"，强调模式治理对于流式系统与分析平台数据复用的关键价值：

模式是释放数据全部价值的核心基石。

基于消息头部的方案还支持渐进式落地。企业无需大规模重构代码、也无需协调所有生产者和消费者同步变更，就能逐步引入模式治理。可在现有事件流上附加模式ID，在保持向后兼容的同时，循序渐进落地更严格的模式管理规范。

Confluent的技术专家Gunnar Morling"在发文指出"，该方案大幅提升了与存储系统及下游计算框架的互操作性：

将模式ID从消息载荷移入Kafka消息头部，是一次极大的体验优化：消息载荷变得合规且完整独立。

将模式元数据与有效载荷分离，使生产者和消费者的独立演进成为可能，验证集中在模式注册表中。这减少了协调开销，并在大规模环境简化了模式演进。它还通过启用跨管道的结构化事件数据一致性重用，改善了与Apache Flink，以及分析或ML系统等工具的互操作性。

Confluent产品管理总监David Araujo"阐释了该功能如何实现零停机及客户端无感知的落地模式：

把模式ID迁移至消息头部后，无需改动载荷格式，就可以为Kafka中已有数据绑定模式规范。

迁移过程中，部分默认从载荷读取模式元数据的Kafka连接器和下游工具需要适配升级，生态环境就绪前会进入新旧两种模式并存的过渡期。目前该功能已在Confluent Cloud上线，后续将进入Confluent Platform，搭配Schema Registry提供支持，并沿用现有授权许可体系。

原文链接：

 Confluent Moves Schema IDs to Kafka Headers to Simplify Schema Governance"