分享你存储在Confluent集群中的数据的元数据，对于在整个企业中有效地分享这些数据来说是最重要的。随着实时数据使用量的增加，将这些数据作为企业内外的产品进行服务是一种常见的演变做法。这种演变通常被称为 "数据网"。
Confluent的Schema Registry允许企业在启动其数据和运营数据网时，确保高数据质量和安全的数据演进。
Schema Registry确保该产品的创建者和消费者之间有一个适当的数据合同；然而，并非一个业务部门的所有数据产品都一定是整个组织的所有可能的消费者所需要的。
为了隔离他们自己的数据需求，团队通常会部署多个Schema Registry集群来服务他们自己的合同。然后，与整个业务部门共享这些合同对于数据产品的成功是最重要的。当拥有自己的Confluent部署的多个业务实体合并时也会出现这种情况。
资源。模式注册概述
模式注册和管理
Confluent的模式注册处通过使用 "模式ID "来唯一地识别Apache Kafka®记录的模式。这些ID被单独包含在每条消息中，以便消费者（如Kafka客户端、连接器和ksqlDB查询）了解要参考的模式，以便理解所消费的数据。
在内部，这些单调增长的ID是由模式注册中心分配的，默认情况下，从 "0 "开始。允许这些合同在多个Schema Registry部署中共存涉及到。
- 确保ID是不重叠的
- 确保模式定义是唯一的
- 确保主题命名的唯一性
有多种方法来解决这些保证，我们将在下面的模式中讨论。
- 枢纽到辐条
- 辐条到中心
- 灾难恢复
枢纽到辐条。数据共享
枢纽到辐条 "模式涉及到在一个组织中全球使用一个单一的模式注册表。数据共享部分包括只复制 "辐条 "所需要的模式（或全部），或希望通过使用特定数据合同进行消费的个别业务部门。
全球ID空间
通过这种设计，我们实现了。
- **单一真理源：**所有的模式注册都发生在 "中心"，所以不用担心模式ID重叠或主题命名冲突，因为模式注册处为新模式提供了一个不断增加的ID，并防止主题碰撞。
- 预注册检查。枢纽模式注册处确保，如果试图注册的两个模式是相同的，那么将为这两个模式分配相同的模式ID。
为了使用这种模式，我们推荐使用模式注册授权器，以防止参与模式注册的任何人破坏 "枢纽 "注册表。这种模式特别允许 "枢纽 "读/写，但 "辐条 "是只读的。拥有一个全局ID空间可以促进整个组织内模式ID的重复使用。这也使得模式注册中心的元数据具有高度的冗余性，这种做法可能有助于组织内的灾难恢复工作。
我们建议在开始为你的运动中的数据平台建立强大的数据合同的旅程时，要考虑到这种模式，因为事后可能很难迁移。
辐条到枢纽。数据聚合
"从辐条到枢纽 "模式允许业务部门执行他们自己的合同，并对他们的模式注册表部署进行控制。数据聚合部分涉及复制数据产品所需的（或全部）模式，以呈现给 "枢纽 "或希望成为该数据产品消费者的任何其他业务部门。
通过这种设计，我们需要建立。
- **ID命名间距。**模式注册处允许 "碰撞 "模式注册的起点，允许每个模式注册处保留一个 "ID命名空间 "用于注册他们的本地数据合同。这种策略包括在模式注册处启用可变性，并导入一个具有预定义ID的假主体。在成功导入后，预定义的ID将作为单调增加的模式ID的起点，模式注册处将为所有后续的注册和修改生成这些ID。有一个样本脚本用于自动碰撞模式注册表的ID。
- 模式碰撞预防。当两个辐条具有相同的模式时，不可能允许它们指向两个不同的ID。在聚合模式注册表时，必须采取预防措施，不要在多个来源中使用相同的模式，这与维护核心域中共享对象的数据网标准一致。
- 模式命名标准。当辐条中注册的模式希望回馈给聚合模式注册中心时，通过为其设定命名标准来避免未来的冲突。
值得注意的是，这种策略允许 "辐条 "是读/写的，但 "枢纽 "是只读的。这种模式允许每个 "辐条 "实施他们自己的安全措施，并选择向整个企业公开哪些模式。关于这种模式的注意点是，应该围绕模式容量进行规划，因为注册表允许设置起点，但不允许设置终点，而且你受到INT_MAX on-prem（2147483647）的限制。
我们建议在旅程的早期考虑这种模式，同时为你的移动数据平台建立强大的数据合同，因为如果多个租户的身份发生冲突，可能很难将其纳入核心。
灾难恢复数据复制
灾难恢复（DR）"模式允许业务部门对模式注册处的故障有一个灾难恢复选项。这允许DR集群作为一个只读站点，同时不被故障覆盖，并且可以安全地用于共享数据。
有了这种设计，以前的限制就不存在了，因为灾难恢复的模式注册表是业务单位使用的模式注册表的完全复制。这种设计要求所有的模式数据都被复制到DR模式注册中心集群，不允许有选择地暴露数据合同。
支持前面提出的模式需要在模式注册中心之间进行强大而有效的数据复制。Confluent和Kafka社区已经开发了多种选项，可以提供帮助。
Confluent模式链接和语境
Confluent的Schema Linking现在可以在Confluent Cloud和Confluent Platform 7.0中进行预览。Schema Linking允许无缝地处理聚合和灾难恢复模式，当成为GA时，应该被认为是事实上的标准。
在中心到辐条模式中，中心确保所有注册的模式都是唯一的命名和识别，从而防止在与辐条模式注册中心共享时出现挑战。此外，模式链接允许 "出口商"，当模式被注册到一个特定的环境中时，它提供了将模式从中心持续同步到辐条的能力。
在辐条到中心的模式中，辐条可以利用上下文和出口器的力量，将在辐条上注册的模式同步回中心，而不必担心在中心的单独上下文中注册模式而发生碰撞。这消除了对ID命名的需要。
此外，模式链接实现了独立于数据共享机制的模式聚合，并解决了在Confluent Platform和Confluent Cloud集群内部和之间的模式聚合、备份、暂存和迁移的现有差距。
Confluent的Replicator是经过战斗考验的执行数据复制的方式。它带有模式转换功能，可以从源模式注册中心复制所有模式。
Confluent Replicator不允许对模式进行选择性复制，任何架构都需要主动/被动复制设置。
在中心到辐条的模式中，所有辐条都需要存储来自中心的所有模式，任何安全问题都可以通过在辐条中启用模式注册授权器来缓解。
在辐条到中心的模式中，每个辐条的所有模式都必须回到中心，并且必须采取适当的预防措施来避免ID、模式命名和模式定义的碰撞。
此外，Confluent Replicator不能在两个Confluent Cloud模式注册中心之间进行复制。
Apache Kafka MirrorMaker 1和2
Kafka提供了一种开源的复制方法，称为MirrorMaker（注意：MirrorMaker 1在Apache Kafka的最新版本中已被废弃）。
MirrorMaker允许复制底层的"_schemas "主题，使其他模式注册中心能够读取这个复制的主题并使模式可用。
MirrorMaker受到与Confluent Replicator相同的限制，但它没有确保目标的注册约束，这可能导致模式的损坏。
对于模式复制，有几个可用的工具选项。
- 架构师--出口
- 优点。这个操作系统工具支持模式的选择性迁移，并与Confluent Cloud Schema Registry一起工作。
- 局限性。这个工具是作为一个纯粹的REST端点解决方案实现的，不允许它复制源模式注册表中的主体的单一兼容性。这个工具没有企业支持。
- 模式注册中心-转移-SMT
摘要
这篇博文介绍了在组织内创建数据共享文化时使用的不同架构模式。可以通过多种工具和模式来合并模式数据，以便在创建业务部门和消费团队之间保持数据契约。
要开始使用Confluent Schema Registry，请尝试在Confluent Cloud上进行完全管理，它现在包括全新的Confluent流治理功能。从Confluent Cloud的免费试用开始，使用代码CL60BLOG ，可以获得额外60美元的免费使用权。*
Arvind是客户成功技术架构团队的一员，在企业寻求基础设施现代化的过程中，帮助他们完成运动中的数据之旅，实现实时化。
Abraham是专业服务团队的一员，专门负责协助Confluent在公司的神经系统中的整合，以解锁运动中的数据。他喜欢在公园里长时间散步，在德州不热的时候打网球。
