消息队列跨区域协同方案的演进

导读：本文从 Apache Pulsar 的特性出发，介绍了消息队列在跨区域协同演进上的一些技术方案，以及与算力网络技术的结合点，供大家参考。

跨区域协同的背景

随着大数据技术的快速发展，集群规模的逐步增大，以及受地域特性的业务，数据的影响，大数据集群需要分地域搭建，数据处理也从集中化向 1+N 转变，形成中心 - 边缘大数据平台，在各个边缘区域搭建独立的大数据集群，负责采集区域内的数据并提供实时性要求高的计算能力，然后借助消息队列的跨区域复制能力，将边缘平台上的数据异步汇总到中心集群，进行时效要求低的离线计算和分析。

今年全面启动的国家级东数西算工程，则在中心-边缘架构的基础上更进一步，通过构建一体化的新型算力网络体系，将东部算力需求有序引导到西部，优化数据中心建设布局，促进东西部协同。东数，指的是在东部生产或采集的大量数据，西算，指的是用西部低碳、低成本的算力资源对数据进行处理。当然东数西算工程并不意味着所有东部的数据都要交给西部的算力去处理，由于东西部之间网络延迟的存在，对于一些对计算实时性要求非常高的业务，仍然需要先在东部进行更为及时的实时处理，同时再交由西部去做实时性较低的处理。

那么要建设东数西算工程，非常重要的一个环节就是将东部的数据准确，高效的搬运到西部，并且将西部的运算结果及时的反馈给东部。作为大数据平台中的数据管道和消息总线的消息队列，在这个过程中就起到了关键的跨区域协同作用。

我们来具体看一下消息队列在中心-边缘大数据平台里的作用。在边缘集群中采集的实时数据，缓存到消息队列集群后，一方面在边缘集群内进行实时计算的处理，另一方面将数据异步复制到中心集群的消息队列，在中心集群进行非实时性的处理。

那么在这种场景下，需要消息队列具备动态扩缩容以及负载均衡能力，来应对不同边缘集群产生数据量的波动；以及跨区域传输的协同能力，来确保边缘集群和中心集群之间的数据能准确无误的进行传输。

基于消息队列 Pulsar 构建跨区域数据管道

在大数据领域，Kafka 由于其高性能的设计一直是首选的消息队列之一。但随着业务的不断扩大，尤其是在构建跨区域数据管道的业务场景下，Kafka 的痛点也逐渐暴露出来，那就是计算存储耦合的设计。Kafka 的节点不仅是服务节点，也是存储节点，由此引发一系列运维上的问题，比如集群难以扩缩容等等。而新一代云原生消息队列 Pulsar，采用了计算存储分离的架构，broker 只负责提供服务，底层存储使用 BookKeeper 集群，使消息队列集群在保证性能的前提下，具备了动态扩缩容的能力。

对于分布式消息队列集群来说，为了保证 topic 数据的一致性，一个 topic 的数据收发业务只能由一个 broker 节点来处理，在 Kafka 中由 topic 的 leader broker 负责，在 Pulsar 中由 topic 的 owner broker 负责。当然可以给 topic 设置多个分区 topic 来提高 topic 吞吐量。对于 Pulsar 的 broker 来说，除了处理消息的生产消费，还根据设置的副本数把数据分发给多个 BookKeeper 节点持久化。

基于这个计算存储分离的架构，Pulsar 可以很轻松的实现动态扩缩容。这里涉及到 Pulsar 的计算节点调度和负载均衡策略，当需要给一个 topic 调度一个计算节点来作为这个 topic 的 owner 时，会基于集群中各个节点的 CPU，内存，带宽等资源使用率，来选择一个综合使用率低的节点进行分配。当我们给 Pulsar 集群扩容，加入新的计算节点时，Pulsar 的负载均衡策略会发现新加入的节点上没有负载，就会从集群中负载较高的节点上卸载部分 topic，将他们重新调度到新加的计算节点上。

而对于存储节点的调度，在 broker 选择 BookKeeper 节点来存储数据时，也会基于存储节点的磁盘使用率以及配置的区域信息来选择存储数据的节点。

Pulsar 和 Kafka 都具备跨区域的消息传输能力。对于 Kafka 来说，要在两个集群之间同步数据，需要借助第三方工具如 MirrorMaker，从一个集群中消费数据，然后推送到另一个集群，这种方式无论是效率还是一致性都不能得到保障。对于 Pulsar 来说，跨集群的复制是内置的功能，负责处理 topic 的 broker 在接受到数据之后就会以异步的方式将数据直接推送到另一个集群，免去了由于数据中转带来的性能和带宽损失。然而，Pulsar 和 Kafka 都无法保证在远距离网络带宽、网络延迟受限的情况下，跨集群之间数据同步的一致性和完整性。

消息队列的远距分布式架构演进

随着东数西算等工程布局的推进和算力网络等技术方案的演进，数据传输和计算将出现异地分割的局面，需要将“热数据”和“冷数据”区别对待。同时，应用架构需要分布式改造，由单体或近程分布式架构改造为远距分布式架构。

将一个分布式消息队列集群的节点分别部署到不同的区域上，就可以避免跨集群之间数据同步的一致性和完整性，以及跨区域配置繁琐等一系列问题。但随之而来的是由于集群内的节点分布于不同的区域，节点之间的网络延迟所带来的一致性和性能问题。目前业界只用在同城双中心这种区域之间网络延迟很低的场景，来实现消息队列的机房级容灾。如果区域覆盖到东西部之间较长的距离，节点之间的网络延迟达到几十毫秒以上，对性能的影响就非常大。

对于远距离消息队列来说，需要实现生产端和消费端能够就近连接 broker 节点，保证客户端和 broker 之间的低延迟和大带宽。消息队列本身需要保证内部不同区域节点之间的数据同步。对于不同区域之间生产消费数据的场景，由于跨区域之间的网络延迟不可避免，可以接受端到端的消费延迟。

对于一个分布式消息队列集群来说，一个 topic 的数据只能由一个 broker 来处理。当需要进行数据异地传输时，生产端和消费端处于异地，只能做到让生产端连接到一个就近的 broker 节点生产数据，这个 broker 就是这个 topic 的 owner，远端的消费端需要接收该 topic 的数据时，仍需要连接到这个处于异地的 broker 上，无法连接就近的 broker 接收数据。

Apache Pulsar 社区正在开发 shadow topic 的特性，计划在未来的版本中发布。该特性允许消费端可以不用连到 topic 的 owner broker 上也能消费数据。Shadow topic 与原始 topic 绑定，共享存储层的数据，但无法直接向 shadow topic 生产数据。Shadow topic 可以归属于另一个 broker，使这个 broker 成为原始 topic 的 read only broker，那么在远距消息队列的场景下，就可以实现数据异地传输时，生产端和消费端都可以各自连接到就近的 broker 上发送和接收数据。

有了这个特性后，还需要消息队列集群具备根据客户端的区域位置进行 broker 的负载均衡调度的能力。目前 Pulsar 的负载均衡调度策略，只是关注各个 broker 节点上的 cpu 内存等计算资源的均衡。在构建远距离消息队列时，需要将 broker 节点与客户端的区域位置作为负载均衡调度策略的一个重要指标，对客户端也具备区域感知能力，能够动态的将 topic owner 调度到离生产端距离最近的 broker 节点，并将 shadow topic owner 调度到离消费端距离近的节点。实现这样的调度能力的难点，在于调度器不仅需要关注算力（CPU，内存等），也需要关注网络（与客户端之间的网络距离，延迟，带宽），将算力与网络融合后进行统一编排和智能调度。

算力网络正是作为解决算力资源与网络资源并存情况下资源统一供给和调度问题的一种新型网络技术方案，通过网络控制面（如集中式网络控制器、分布式路由协议等）分发服务节点的算力、存储等资源信息，并结合网络信息和用户需求，提供计算、存储、网络等资源的 分发、关联、交易与调配，从而实现整网资源的最优化配置和使用。

然而，在算力网络资源分布情况复杂，设备复杂，算力感知度量复杂的情况下，进行算力网络的智能调度并不简单，需要能够兼顾算力与网络的智能算法。首先需要解决算力感知与评估，将算力资源（CPU，内存）和网络资源（时延，带宽）指标化，然后通过算力调度与编排，形成统一的算力网络地图，将资源的加入与减少定义为地图的修正。最后通过算力地图导航，结合客户端接入需求与 AI 算法，实现算力资源的最优调度导航。有了算力网络的智能调度，就可以帮助 Pulsar 将 topic 和 shadow topic 调度到最优的 broker 节点上，使整个 Pulsar 集群的资源得到最优化的配置和使用。

总结

提到消息队列的跨区域部署，一般讲的都是容灾。随着大数据技术的快速发展，跨区域协同逐渐成为跨区域场景的演进方向。容灾是指当一整个机房不可用的情况下，能确保服务可用，数据可用。那么协同，讲的是当数据和应用分布在不同区域的情况下，能把服务当为一个整体。

这意味着应用可以在任何地方投递数据，在任何地方获取数据。光看这一点的话其实是理所当然的，只要网络通就行。但是加上第二点，保证应用和服务之间的低延迟，大带宽，那就是个难题了。应用端和服务端如果分隔在远端，就无法做到低延迟和大带宽，这就需要服务端具备远距离分布式架构。要做到这点，真正要解决的技术难题，是在远距离网络带宽、网络延迟受限的情况下，让一个分布式系统能高效且准确的运行。

随着算网原生，算网融合编排，算力交易等关键技术的攻关，以“算为中心，网为总线，算网融合”为导向的算力网络架构或将成为跨区域应用协同与治理的下一个演进方向。