什么是模式注册表？

模式注册表是一种集中式服务，用于存储、管理和验证通过 Apache Kafka 交换的数据在序列化和反序列化时所使用的模式。模式注册表不让各个生产者和消费者应用各行其是地定义消息格式，而是为事件数据的结构提供一个共享的唯一可信来源。

在 Kafka 中，事件通常使用 Apache Avro、JSON Schema 或 Protocol Buffers（通常简写为 protobuf）等格式进行序列化。模式注册表存储这些格式的定义，并为每个模式分配一个唯一标识符。这就是模式 ID。

当生产者向 Kafka 主题写入消息时，通常会在序列化数据旁边附带模式 ID，而不是在每条消息中都嵌入完整的模式。消息消费者随后从注册表中检索相应的模式，并用它来正确反序列化和解读数据。

模式注册表在基于事件的系统中很重要，因为它有助于确保生产者和消费者对所交换数据的结构达成一致。这有助于保障数据质量和数据完整性。

如果没有集中式注册表，各个应用就必须各自管理消息模式。这会增加不兼容变更的风险，可能导致事件消费者出错或误读数据。

模式注册表还支持所谓的模式演变。这让开发人员能够随时间调整事件结构，同时保持与现有应用的兼容性。

例如，通常可以新增一个可选字段，而不会破坏现有 Kafka 消费者所期望的格式。兼容性规则有助于在部署之前强制落实安全的模式变更。

另一个重要收益是数据治理得到改善。模式集中存放在一个存储库中，这意味着组织可以对事件数据的结构进行记录、审阅、版本化和审计

这种做法让开发团队更容易做到以下几点：

• 了解可用的事件类型
• 了解数据格式
• 查看模式版本
• 保持分布式系统间的一致性。

在现代数据平台中，模式注册表还可以还可以支撑 Kafka 生产者与 Kafka 消费者之间的数据契约。这些契约不仅定义了数据的结构，还定义了数据应随时间如何演进的预期。

通过在模式变更发布前进行验证，模式注册表可以帮助防止破坏性变更进入生产环境，并提升事件驱动架构的可靠性。

模式注册表提供了一套集中机制，用于管理事件模式、强制这些模式之间的兼容性，并支持对它们的变更。

注册表还可以让开发人员在旧模式的基础上构建新模式，在模式中实现结构化组合，并通过主题命名策略来规范事件名称。

这些方法能帮助应用在系统与需求变化时继续交换数据。

模式注册表的工作原理是：存储并管理那些定义了生产者与使用者之间交换的事件数据结构的模式。当生产者向 Kafka 主题发送数据时，它会按已注册的模式对消息进行序列化，并附带可用于识别相应模式的信息。消费者随后可以用该模式来反序列化并正确解读消息。由于模式会随时间变化，注册表还可以在新模式版本注册之前对其进行兼容性检查，帮助生产者和消费者继续适配不断演进的数据结构。

设想一家大型在线零售商，它有多个系统在生产和使用数据：电商网站、移动应用程序、推荐引擎、库存管理系统、物流平台以及客户分析平台。这些系统通过使用 Confluent Cloud 的 Apache Kafka 集群发布和消费事件来进行通信，并在其数据管道中使用 Kafka Connect 将这些事件流式传输到数据仓库。

网站上的每个操作都会在零售商的整个系统中生成多个事件。每当客户下单时，网站都会向 Kafka 主题发布一条 OrderCreated 事件。

多个下游应用程序消费同一事件。库存系统预留已购商品，支付系统确认交易，仓库开始履行订单。推荐引擎更新客户偏好，分析平台记录这笔销售，客户通知服务发送电子邮件确认。

最初，OrderCreated 事件包含 order_id、customer_id、product_id、quantity 和 total_price 等字段。所有消费这些事件的应用在构建时都假定是这一结构。

现在设想一下：几个月后，企业决定支持国际销售。开发人员更新了网站，让每个订单都包含 currency 和 exchange_rate 两个新字段。

如果没有模式注册表，就没有集中机制来协调这一变更。一部分事件数据消费者会期待新字段，另一部分则不会。如果开发人员不小心将把 total_price 重命名为 order_total，或者把它的数据类型从十进制改成字符串，下游服务可能会突然开始出错。仓库可能会停止接收订单，分析仪表板可能会生成错误的报告，客户通知也可能因为无法解析该事件而失败。

那么，如果使用 Confluent Schema Registry 来做模式管理，同样的场景会是什么样子？

在部署更新后的生产者之前，开发团队会注册一个新版本的 OrderCreated 模式。这会生成一个与该模式关联的新模式 ID。模式注册表会根据组织的兼容性设置，检查提议的变更。

如果提议的变更符合这些兼容性规则，就可以注册新的模式版本。如果某项变更违反了配置的兼容性策略，注册表可以在应用开始使用不兼容的模式之前就将其驳回。

这意味着开发人员可以在开发阶段而非部署之后，就发现破坏性的模式变更。现有消费者可以继续兼容地运行，而开发团队可以在准备就绪后逐步更新自己的应用，去使用新的字段。

随着公司规模扩大，模式注册表的收益会变得更加显著。由数十个工程团队开发的数百个应用，可能会通过数千种不同的事件类型交换数据。

如果没有模式注册表，每个团队都只能依靠手写文档、开会或反复试错来人工协调模式变更。这种人工流程会拖慢开发进度，并增加不兼容变更流入生产环境的可能性。

有了模式注册表，事件模式就成了集中管理的资产。生产者可以按已注册的模式发布数据，消费者可以借助这些模式定义来解读传入的事件，而兼容性检查则能识别出彼此不兼容的模式变更。

新团队还可以直接查阅已有的事件定义，而不必逆向推导消息格式，从而更容易构建新应用、集成新系统。

随着零售商规模扩大，模式注册表提供了一种集中方式，来管理生产者和使用者之间不断演进的事件模式。

模式兼容性决定了：当模式演进时，使用不同版本模式的应用能否继续正确交换和解读数据。主要的兼容模式有向后兼容、向前兼容和完全兼容。

• 向后兼容意味着较新的消费者可以读取用较旧模式写入的数据。当消费者在生产者之后才更新，或者应用必须继续处理用早期模式版本写入的历史数据时，这一点非常有用。
• 向前兼容意味着较旧的使用者可以读取用较新模式写入的数据。当生产者在所有消费者之前先更新、而较旧的应用必须继续处理新产生的事件时，这一点可能很重要。
• 完全兼容同时具备向后兼容和向前兼容，因此模式变更必须在两个方向上都保持兼容。

一些模式注册表还支持这些兼容模式的传递版本。传递兼容性检查不是只把新模式版本与紧邻的前一个版本比较，而是把它与所有相关的早期版本逐一比较。具体的兼容性规则和允许的模式变更，取决于模式格式以及注册表的兼容性设置。

当较旧的生产者必须持续运行、而较新的消费者需要不间断地处理来自这些旧生产者的数据时，向前兼容就很有用。在这种情况下，当务之急是确保新部署的应用，与仍由旧版本生产者软件生成的消息保持兼容。

设想一家运营智能电网的全国性公用事业公司。该电网由安装在家庭和企业中的数百万台智能电表组成。每台智能电表都会向 Apache Kafka 发布用电事件。这些电表的服役期长达数年，而且只能在预定的维护窗口内接收固件更新。这意味着，即便软件的新版本早已发布，许多电表仍会长期继续使用旧模式生成事件。

与此同时，这家公用事业公司会定期升级其集中监控与分析应用。新版分析平台新增了对更多信息的支持，例如电能质量指标和可再生能源发电量。这些新字段在有数据时很有用，但平台必须继续处理那些不发送这些字段的旧电表数据。

在这种场景下，向前兼容比与早期版本兼容更重要，因为消费者先更新，而许多生产者仍停留在旧的模式版本上。新的消费者软件必须能够正确读取用旧模式写入的事件，即便这些事件缺少新引入的字段。应用可以把缺失的字段当作可选字段，或为其指定默认值，同时继续执行其主要功能。

如果主要关注的是向后兼容，开发人员就会把重点放在确保较新的消费者能读取用较旧的生产者模式写入的数据上。然而，该组织眼下真正的挑战是：在对中央处理系统进行现代化改造的同时，还要维护大量长期服役的旧设备。

使用带有适当兼容性规则的模式注册表，这家公用事业公司就能逐步演进其事件模式，而无需对数百万台已部署的电表同步升级固件。这使得生产者和消费者可以在不同时间分别更新，同时仍然满足组织所配置的兼容性要求。

模式注册表还能支持涉及数据隐私法规的合规工作，例如《通用数据保护条例》(GDPR) 和《加州消费者隐私法》(CCPA)。

尽管模式注册表本身并不能带来合规，但它可以帮助组织落实用于满足监管要求的数据治理、一致性和审计实践。

一项关键收益是提升了对所处理数据的可见性。

每个事件模式都存放在集中式存储库中，其中记录了模式所包含的字段。这就提供了一个信息来源，说明存在哪些数据、各个字段代表什么，以及应用如何组织自己生产或消费的数据。

它可以帮助组织识别出包含个人身份信息 (PII) 的模式，例如姓名、电子邮件地址或账户号码。

模式注册表还可以支持数据最小化，这是 GDPR 的一项原则。

在模式获批之前，开发人员和数据治理团队可以逐一审查：每个字段是否都为预期业务目的所必需。这一审查流程有助于防止应用收集或共享不必要的个人信息。

模式验证还有助于防止未经授权的或意外的变更把新的敏感数据引入生产系统。

例如，如果开发人员试图把客户的社会保障号或驾驶证号添加到现有的 Kafka 事件中，那么可以在部署之前先对提议的模式进行审查。

这种做法在常规的应用测试之外，又增加了一道治理检查。

版本控制与模式历史提供了审计能力。

每一次模式演进都会被记录，组织据此可以确定各个字段是在何时被添加、修改或删除的。

在合规审计中，这些历史记录有助于证明：数据结构是以受控且可追溯的方式管理的。

模式注册表还可以提高多个系统之间的一致性。

由于生产者和消费者依赖共享的模式定义，应用可以按照共同的结构定义来解读字段。

这可以减少各应用之间数据处理不一致的情况。

许多组织把模式注册表作为落地数据契约的一部分。

这些契约不仅定义事件的结构，还定义了它所含数据的元数据。

• 一份数据契约可以标明：
• 哪些字段包含 PII
• 特定字段是否有安全要求
• 谁有权消费特定数据
• 数据应该保留多长时间？

随后可以使用自动化验证，检查新的模式版本是否仍然满足既定的要求。

模式注册表还可以与更广泛的数据治理和安全工具集成。

随模式一起存储的元数据，可供以下系统使用：

• 数据目录
• 访问控制系统
• 沿袭跟踪工具
• 合规平台

因此，模式注册表可以构成更广泛治理架构中的一个组件。

结合加密、访问控制、数据保留策略和审计日志记录，模式管理可以帮助组织管控个人数据的收集、处理和共享方式。

有多个平台为 Kafka 及相关数据系统提供模式注册表能力。

Confluent Schema Registry是一个被广泛使用的 Kafka 专用模式注册表。

它是 Confluent 体系的一部分，既可作为 Confluent Platform 的自管理组件使用，也可作为 Confluent Cloud 中的托管服务使用。

它支持 Avro、Protobuf 和 JSON Schema，并提供模式版本控制、兼容性规则、验证，以及与 Kafka 生产者和消费者的集成。

Amazon Web Services 提供 AWS Glue Schema Registry。

这是一个托管式模式注册表，与 Apache Kafka、Amazon Managed Streaming for Apache Kafka (MSK)、Amazon Kinesis、Amazon Managed Service for Apache Flink 和 AWS Lambda 集成。

它支持 Avro、JSON Schema 和 Protobuf。

Apicurio Registry 是一个可与 Kafka 配合使用的开源模式和 API 工件注册表。

它支持 Avro、JSON Schema 和 Protobuf 等格式，并可部署在 Kubernetes 等环境中。

Apicurio 还提供与 Confluent Schema Registry API 的兼容性，这让围绕 Confluent 模式注册表接口设计的 Kafka 应用更容易与之配合。

Redpanda 也内置了一个兼容 Schema Registry 的服务，作为其与 Kafka 兼容的流式数据平台的一部分。

当组织使用 Redpanda 而不是直接使用 Apache Kafka 时，这种方式会很有用，因为模式管理可以作为流式数据平台自身的一部分来提供。

Redpanda 注册表更紧密地集成在这个 Kafka 兼容的流式数据平台中。

不是的，模式注册表并不属于 Apache Kafka 核心软件。Kafka 负责存储和传输记录。模式注册表则是一项独立的服务，用于存储和管理这些记录所含数据的模式。模式注册表通常与 Kafka 搭配使用，帮助生产者和消费者一致地解读结构化事件数据。

模式 ID 是某个特定模式定义的标识符。模式版本则表示该模式在某个模式或主题所维护的版本序列中所处的位置。具体实现因注册表而异。例如，在 Confluent Schema Registry 中，模式 ID 在注册表内唯一标识某个模式，而版本则从属于某个主题。因此，同一个模式可以拥有相同的模式 ID，同时又在不同主题下关联到不同的版本。

模式注册表主要存储和管理机器可读的模式，供应用用来理解数据的结构。它还可以提供模式版本控制、兼容性检查等能力。

数据目录的关注面更广，旨在帮助人员和系统发现、理解并治理整个组织的数据资产。目录可以包含业务描述、所有权信息、分类，以及关于数据集和数据系统的其他元数据。因此，模式注册表和数据目录可以互为补充。注册表管理应用所使用的模式，而目录则提供关于组织数据资产的更广泛信息。

模式定义数据的结构，包括字段、数据类型等要素。数据契约可以包含模式，但同时也会定义数据生产者与消费者之间更广泛的预期。模式可以作为数据契约的一部分，与完整性约束、元数据和策略并列。

合适的模式注册表取决于组织的技术要求和现有的数据架构。需要考虑的因素包括：注册表支持的模式格式、它的兼容性规则、与 Apache Kafka 及其他数据系统的集成、API 与客户端支持、安全与身份验证能力，以及该服务是托管式还是自管理式。

组织还可以考察该注册表如何支持模式演进、数据治理、元数据和数据契约，以及它与现有生产者、消费者和数据管道的兼容性。不同的注册表产品提供这些能力的不同组合，因此选型通常取决于注册表需要支撑的系统和需求。