公司正越来越多地转向云计算，经历的转型往往是一个跨越增量阶段的多年旅程。在这个过程中，许多公司暂时或永久地接受了混合云架构，即一些应用程序在企业内部运行，一些在云中运行。然而，统一企业内部和云环境中的数据是巨大的挑战，因为大多数传统的应用程序并不适合云计算，而且与现有的企业内部基础设施有许多依赖性和集成性。
随着Confluent Platform 7.0的发布，我们很高兴地宣布Cluster Linking的全面上市，以提供一个易于使用、安全和具有成本效益的数据迁移和地理复制解决方案，在你的混合架构中无缝和可靠地连接应用程序和数据系统。Cluster Linking提供了三个主要优势，将您的数据实时转移到适合您业务的地方。
- 通过安全、可靠和毫不费力地在云和内部环境之间建立一座桥梁，加速企业的云计算之旅
- 通过全球连接的集群，实现整个企业对数据的实时自助访问，这些集群可以完美而可靠地反映所有环境中的数据。
- 通过在任何地方的Kafka集群之间进行无缝和具有成本效益的数据地理复制，降低总拥有成本（TCO）和运营负担。
在这篇博文中，我们将逐一探讨集群链接的这些好处，以及该版本中的其他增强功能，这些增强功能通过扩大API驱动的操作来加速您的流媒体基础设施的价值实现时间，通过将监控卸载到基于云的解决方案来降低基础设施成本，并加快流处理应用程序的开发。和以前的Confluent平台版本一样，你总能在发布说明和下面的视频中找到更多关于这些功能的细节。
继续阅读以了解Confluent Platform 7.0所包含的内容，如果你已经准备好开始使用，请立即下载Confluent Platform。
加速混合架构的云端之旅
将企业内部的数据纳入云端是一项挑战。传统的方法通常需要手动数据传输或环境之间脆弱的点对点连接，这造成了架构的复杂性，增加了运营开销，并延迟了价值实现时间。诸如此类的过时的流程阻碍了企业实现云计算的全部好处，成本不断上升，风险不断增加，安全漏洞也不断增加。
一些企业已经转向Kafka，为每个环境将数据聚集到集群中，然后使用MirrorMaker 2等地理复制工具连接这些集群。这种模式加速了许多企业向云计算的转移，他们利用Kafka的可扩展性和丰富的连接器和数据集成生态系统，将单体的传统平台分解为可单独迁移的微服务。
然而，这种方法并非没有挑战。在操作上，需要为每一对连接的Kafka集群部署和管理一个单独的Connect集群来运行MirrorMaker 2，这增加了管理的开销和复杂性。而当应用程序迁移到云端时，他们需要处理复杂的主题偏移翻译以确保数据的一致性。
Cluster Linking通过全局一致的地理复制解决了这些挑战，这种复制直接内置于Confluent集群中，开箱即用。这使得在内部环境中的Confluent平台集群与云环境中的Confluent云集群之间可以轻松创建一个持久的、无缝的桥梁。您可以在多个环境之间创建一个单一的集群链接，而不是有许多点对点的连接，这可以被数百个不同的应用程序和数据系统使用。
拥有单一的混合数据主干，可以加快混合云的交付时间，并消除混合云架构的风险和安全漏洞。它为每个应用团队提供了灵活性，可以轻松地将工作负载迁移到最适合你业务的地方。此外，对于那些依靠模式注册中心来管理元数据的企业来说，集群链接是由模式链接（Schema Linking）--在7.0的预览状态--来补充的，可以快速地将你的模式从企业内部的模式注册中心迁移到Confluent云中完全管理的模式注册中心。Confluent支持所有主流公有云的混合架构，无论你是在AWS、Azure还是Google Cloud上操作。
另外，由于集群链接可以源自源集群，您可以在Confluent平台和Confluent云之间安全地发送数据，而不需要向Confluent云的IP地址开放内部防火墙。这是安全数据迁移和地理复制的最佳实践，它简化了信息安全审查过程，提高了混合云工作负载和内部向云迁移的交付时间。
源头发起的链接确保安全的数据迁移和复制
而在有计划的迁移中，消费者从一个环境中的主题读取时，可以从不同环境中的同一主题开始读取，没有任何重新处理重复数据或错过关键信息的风险。这使运营商能够灵活地使用动态API将主题和应用逐步推广到云端--而不是手动改变配置和重启连接器--促进更平稳的迁移，没有数据损失，将停机时间和业务中断降到最低。
对所有环境中的数据进行自助式访问
使用现有的数据集成解决方案，很难创建一个一致的数据层，因为不同环境中的数据蔓延，每个来源都有自己的数据模式和数据共享的要求。最终，这导致了数据被锁在静止的孤岛上，限制了开发人员的灵活性和对关键业务信息的实时访问。这也导致了不同的和不相关的客户体验和低效的后端操作。
Cluster Linking通过全球数据共享和集群间数据的完美镜像地理复制，简化了对不同地区、云、环境和团队数据的实时访问。它在Confluent平台和Confluent云之间提供高效和简单的双向连接。
通过一个镜像命令，您可以创建一个字节对字节的只读主题副本，并将其从内部环境复制到不同的云区域或其他内部环境。同样地，任何相关的云主题也可以在内部导入。使用一次写入、多次读取的范式--也称为 "扇出"--镜像主题可以安全、经济地被尽可能多的消费者消费，而不会增加原始源集群的负载或产生额外的网络费用。这确保了关键任务的应用程序可以轻松和可靠地访问他们需要的所有数据，以运行你的业务。通过这种方式，你可以打破数据孤岛，在你的整个架构中实时创建一个全球一致的数据层。
集群链接实现了一个跨环境的实时桥梁
通过几个简单的命令，数据就可以在整个企业中随时使用。这使跨自主领域的团队和开发人员能够在他们想要的环境中实时访问他们需要的数据。
降低总拥有成本和运营负担
使用MirrorMaker 2等基于连接的方法来管理地理复制，会增加基础设施成本、运营负担和架构复杂性。这在很大程度上是因为你需要管理额外的基础设施组件，运行额外的虚拟机或服务器，并使用复杂的客户端代码或手动流程进行偏移保存。另一方面，非Kafka方法需要定制的、点对点的连接，这造成了技术债务，并且在管理、安全、维护和扩展方面都很昂贵。
在这个最新的版本中，Cluster Linking在你的混合环境中提供了低成本的数据地理复制。Cluster Linking消除了部署一个单独的基于Connect的系统来管理地理复制或灾难恢复的需要，这意味着操作和维护的软件更少，建立连接所需的基础设施组件更少。这降低了基础设施成本、运营负担和架构的复杂性。
你不需要多次部署MirrorMaker 2来建立集群之间的双向数据流，而是可以轻松创建集群链接，直接在集群之间安全、双向、一致地复制数据，节省成本。架构复杂性的降低也意味着需要更少的资源来维持系统的运行，这意味着整体TCO的降低。
这对于拥有大型多区域Kafka部署的组织来说尤其如此。因为MirrorMaker 2的单一部署只能在两个集群之间单向复制数据，在三个不同的集群之间的每个方向的地理复制数据将需要六个不同的MirrorMaker 2部署。因此，你在全球事件网中拥有的集群越多，集群链接的TCO节约就越多。
简化你的架构以降低成本和消除技术债务
Cluster Linking允许你创建一个单一的连接，而不是像非Kafka方法那样有许多点对点的连接，该连接可以被保护、监控和审计。随着你的混合云足迹的扩大，这也意味着减少了网络成本和一个更可扩展的平台，以支持你的公司的所有流和实时需求。
额外的增强功能
除了集群连接，Confluent平台7.0还包括其他一些重要的增强功能，将Confluent Cloud的一些云原生体验带到您的自我管理环境中，并将其作为一个更完整的平台来支持端到端的关键任务用例。以下是一些亮点。
Confluent平台7.0加强了我们的关键产品支柱
Confluent for Kubernetes 2.2
今年5月，我们发布了Confluent for Kubernetes，它允许你使用一个完整的、声明式的API来部署和操作Confluent，建立自己的私有云Kafka服务。我们支持企业级Kubernetes发行版，如VMware Tanzu Kubernetes Grid（TKG）和红帽OpenShift或任何符合云原生计算基金会（CNCF）一致性标准的发行版。
Confluent for Kubernetes支持所有主要的企业级Kubernetes发行版
在这个最新版本中，我们通过增加连接器、模式和集群链接的云原生管理来完成声明式API。这意味着，你可以声明性地定义平台的这些组件所需的高层次状态，而不是管理所有的低层次细节。这减少了操作负担，实现了更快的价值实现时间，因为你可以通过API为这些组件提供、配置、更新、删除和进行管理任务，而不是通过手动和容易出错的过程。
使用Confluent for Kubernetes的声明式集群链接管理
企业普遍面临的另一个运营挑战是扩展Kafka集群，这是一个手动、耗时和容易出错的过程，会分散工程团队对更重要战略项目的注意力。团队往往不得不在过度配置基础设施以避免这一痛点或承担持续的运营风险和负担之间做出决定。Confluent for Kubernetes通过Shrink API加强弹性扩展，帮助消除这种权衡。有了单命令缩减，企业现在可以完全抽象出这个缩减过程，同时减少其对业务的相关成本。
使用Confluent for Kubernetes的单命令集群缩减和自动重新平衡
仓库
Confluent平台7.0提供了Apache Kafka® Raft元数据模式（KRaft）的预览，这是一个现代的高性能共识协议。作为KIP-500的一部分，KRaft的推出是为了消除Apache Kafka在元数据管理方面对ZooKeeper的依赖。用KRaft取代外部元数据管理，将元数据的责任整合到Kafka本身，而不是在两个不同的系统之间分割，从而大大简化了Kafka的架构。ZooKeeper和Kafka。
这提高了稳定性，简化了软件，使其更容易监控、管理和支持Kafka。它还允许Kafka在整个系统中拥有一个单一的安全模型，同时使集群能够扩展到数百万个分区，实现恢复时间的10倍改善。
支持数以百万计的分区而不明显影响恢复时间
要试用KRaft与Confluent Platform 7.0 Docker镜像，请看cp-all-in-one-kraft。请注意，该功能处于预览阶段，还不支持生产工作负载。
减少控制中心的基础设施模式
在Confluent Platform 6.2中，我们引入了Health+，它提供智能警报和基于云的监控工具，以减少停机风险，简化故障排除，浮现关键指标，并加速问题解决。Health+是对Control Center的补充，为Confluent Platform的运行提供了一套全面的GUI工具；Health+可用于集群监控，Control Center可用于集群部署和管理。
Confluent Platform 7.0现在为那些想严格使用GUI工具进行管理和部署的人提供了Control Center的Reduced Infrastructure Mode。这使您能够通过将对内部集群的监控卸载到Health+中可扩展的、基于云的解决方案中，从而大大降低总拥有成本，使您的监控基础设施成本减少70%。
减少控制中心的基础设施模式
通过Health+，您可以使用Confluent经过专家测试的规则和算法库，在集群问题导致昂贵的停机时间之前识别和避免这些问题，这些规则和算法是在Confluent云中运行成千上万个符合我们99.95%正常运行时间SLA的集群后开发的。您还可以在一个基于云的仪表盘中轻松查看所有的关键指标，并通过Confluent支持团队的专家加速诊断和支持来加快问题的解决。如果你对Health+感兴趣，你可以免费注册。
ksqlDB 0.21
Confluent平台7.0还配备了ksqlDB 0.21，其中包括一些新的增强功能，使开发者更容易建立利用运动中的数据的实时应用程序。
最大的增强之一是对外键表连接的支持。在以前的ksqlDB版本中，用户被限制只能根据每个表的主键来连接表。围绕这一限制开展工作可能会给开发人员带来额外的代码复杂性，以及在应用程序运行时的低效资源使用。
在现有的表对表的连接中，行是根据它们的键来匹配的。
在Confluent平台7.0中，ksqlDB现在支持1:N的连接，或表的外键连接。通过外键连接，只有连接的一边必须引用行键，而连接的另一边可以引用目标表中的任何列。这意味着开发人员不再需要借助于增加额外步骤和容易出错的连接流的变通方法。相反，它为开发者提供了更大的便利和灵活性，可以根据他们的需要组合和充实数据。
通过外键连接，只有连接的一方必须引用行键
此外，ksqlDB现在支持DATE 、TIME 和BYTES 数据类型，以及处理这些数据类型的功能。DATE 类型表示一个日历日期，TIME 类型表示一个精确到毫秒的一天的时间。它们对于表示不太具体的时间值是很有用的，比如生日或重复发生的警报时间，这些值不会像TIMESTAMP 那样有意义。这也意味着你可以摄取流数据，并与源保持一致，而不必转换数据类型或失去数据的保真度。
表示日期和时间值而不必转换数据类型
BYTES 数据类型使你能够表示不适合其他类型的数据，如来自其他数据库的图像或BLOB数据。你可以使用面向字符串的函数对存储在BYTES 列中的二进制字符串进行操作，例如，操作它们的值，解码文本，或根据字节数组的部分过滤行等。
在Confluent平台7.0中，ksqlDB还包括一些额外的增强功能，以简化实时流处理应用程序的开发。
SHOW CONNECTOR PLUGINS列出所有已安装的可供使用的连接器的命令- 支持在Java客户端管理连接器
- 推送查询的空闲超时
支持Apache Kafka 3.0
按照Confluent每个版本的标准，Confluent平台7.0是建立在Apache Kafka的最新版本上的，在这种情况下是3.0版本。除了上面提到的KRaft预览外，Kafka 3.0还简化了KIP-745中通过单个REST API调用重启Connector 和Task 实例的过程，并通过KIP-695改进了Kafka Streams的时间戳同步性。
关于Apache Kafka 3.0的更多细节，请阅读Konstantine Karantasis的博文。
想了解更多？
请看Tim Berglund的视频和播客，了解Confluent Platform 7.0的新内容，今天就下载Confluent Platform 7.0，开始使用这个由Apache Kafka原创作者打造的完整运动数据平台。
Hasan Jilani是Confluent的产品营销经理，负责Confluent Platform和Core Kafka的营销。在加入Confluent之前，Hasan在DXC Technology负责云和平台服务的营销。
