|
张洋，来自金融科技部软件研发中心基础平台开发域，致力于分布式消息、分布式缓存和应用可观察性方面的研发，目前主要进行诊断分析平台和分布式消息平台的建设工作。 Pulsar是目前消息系统的典型代表，具备计算存储分离、节点对等、独立扩展、灵活扩容、快速容错等功能，并且是天然适配云原生的。Pulsar同时支持大集群、多租户、百万topic。并且原生具备跨地域复制的功能，使用者完全不必去担心集群之间数据的复制问题，这个痛点Kafka用户绝对深有体会。Pulsar的设计和实现具有很好的前瞻性，并且借鉴一些优秀的中间件框架的设计，解决了当下主流消息中间件的痛点，取其精华去其糟粕，Pulsar的未来势不可挡。 Pulsar 组成Pulsar 主要由五个方面组成：
Pulsar 的优秀设计3.1 Pulsar 存储3.1.1 计算存储分离Pulsar采用了计算存储分离的多层架构。计算存储分离的架构，使得存储层和计算层完全解耦，并且可以各自动态扩展。 在Pulsar中数据的分发和保存分别由Broker 和 BookKeeper进行处理。Producer 发送数据到Broker。Consumer从Broker中消费数据，但是具体的数据保存在BookKeeper 中。Broker不存储数据，所以Broker是无状态的。 无状态的好处：节点对等、独立扩展、快速扩容、天然适配云原生等。相对于Kafka的Broker计算存储分离的架构，Pulsar的架构更加职责分明、灵活。 3.1.2 分区存储 vs 分片分区存储分区存储 Kafka采用分区存储的方式。 如下图所示为Topic采用一分区两副本的方式进行存储。Kafka数据的读写都是在主分区上的。副本仅仅负责同步数据，当主分区宕机后才会提供服务。通过分区数提升了系统的并发能力。副本的存在提升了系统的可用性。 计算存储一体架构存在的隐患： 1.存储和计算耦合，Broker是一个有状态的节点，不方便上云。 2.分区存储数据的容量受限，分区大小取决于主机上最大的单个磁盘大小。如果当前分区存储满了，需要增加分区数，并且将数据重新分配数据到各个分区，数据的大量复制工作是不可避免的。
分区分片存储 Pulsar采用分区分片存储的方式，先将数据分区，然后每个分区又对应着不同的分片。如下图所示： Partition-0 对应 Segment-0 Segment-1，Partition-1 对应 Segment2，Partition-2 对应 Segment-3。 每个分区都可以设置多个分片，并且均衡的分布在Bookie节点上。当Partition-0分区存储满了后，扩容仅仅需要两步： 1.新增分区0的分片数量。 2.新增Bookie节点，并且将新增的分片路由到新增的Bookie节点上即可。 分区分片存储的优势：完全没有数据复制的工作。Pulsar的存储更加灵活、扩展性、容错能力也更强。
3.2 多种消息消费模型3.2.1独占消费模型在任何时间，当前的topic只能由一个消费者进行订阅。如下图所示当ConsumerA-0 正在订阅当前Topic的时候，其他的Consumer去订阅当前Topic是不允许的。 使用场景：严格要求队列的顺序性的场景。
3.2.2 故障切换模型故障切换模型，多个消费者可以附加到一个订阅中，但是一个订阅中的所有消费者，同一时刻，只能有一个消费者被选为主消费者。组内其他的消费者都为故障转移消费者。 主消费者断开连接的时候，会在故障转移消费者中重新选取一个主消费者，之前没有ack的消息，也都将重新进行消费。可以把故障切换模型看做独占消费模型的高可用版本。 使用场景：严格要求队列的顺序性并且对消费者的可用性要求很高的场景。
3.2.3 共享订阅模型消息将以轮询的方式发送到不同的消费者中。并且一个消息仅仅能被一个消费者消费，当其他的消费者故障的时候，没有ack的消息会在其他的消费者中重新消费。与kafka不同的是如果想提高消费能力，不需要新增分区，仅仅增加消费者的数量即可。 使用场景：不需要保证消息顺序性的任意场景。
3.3 多种消息系统代理RoP、AoP、KoPRoP、AoP、KoP 分别是将RocketMQ、AMAP消息系统、Kafka协议处理插件引入到Pulsar broker的代理，这样Pulsar 就能支持原生各种消息队列的协议了。用户无需修改代码，便能将现有的RocketMQ 、Kafka、Rabbitmq等应用程序和服务迁移到Pulsar，同时还能使用Pulsar的强大功能。 3.3.1 RoP在Client与Broker的交互中，Pulsar基于Protobuf 的二进制协议，提供更高的性能和更低的延迟。RocketMQ 由于使用的消息处理协议和Pulsar不同，如果Pulsar想要兼容RocketMQ协议，为了将RocketMQ 的协议适配到Pulsar的消息协议层中，用户需要重写整个协议层，这给用户的迁移和切换带来了很大的成本。为了解决这个问题，给用户提供一个开箱即用的迁移策略和方案并且用户无需做任何代码修改，诞生了RoP项。RoP实现架构如下图：
3.3.2 AoPAoP同RoP类似，也是一个可插拔的协议处理插件，可以通过使用Pulsar的topics、cursors等特性在Pulsar上支持原生AMQP 。AMQP Proxy服务和AMQP处理插件都与Pulsar broker一起运行。目前，AoP是基于AMQP 0.9.1进行开发，在考虑增加对 AMQP1.0协议的支持。 AoP实现架构如下图：
3.3.3 KoPKoP 旨在利用 Pulsar 和 BookKeeper 的事件流存储架构和 Pulsar 的可插拔协议处理插件框架来提供一种精简而全面的解决方案。KoP 是一个协议名称为「kafka」的协议处理插件。KoP 绑定在 Pulsar broker上，并与 Pulsar broker 一起运行。 KoP实现架构如下图（摘自streamnative/kop github项目介绍）
3.4 多集群多租户Pulsar的Topic的组成：domain://tenant/namespaces/topic 主要由四部分组成： 1.domain: 分为nonpersistent和persistent，对应非持久化和持久化存储； 2.tenant: 表示租户名称； 3.namespaces: 命名空间 4.Topic：主题名称 这样做的目的就是为了支持多租户的场景。Pulsar的多租户机制包含了两种资源：资产（property）和命名空间（namespace）。资产代表系统里的租户。假设有一个Pulsar集群用于支持多个应用程序（就像Yahoo那样），集群里的每个资产可以代表一个组织的团队、一个核心的功能或一个产品线。一个资产可以包含多个命名空间，一个命名空间可以包含任意个主题。
3.5 批流一体Pulsar 是下一代的新型消息系统，将批流处理集于一身，并且致力于克服一些主流消息系统的弱点。并且提供了各种代理，主流的消息系统可以快速的迁移到Pulsar上。为了有更好的运行效率、可扩展性和灵活性，Pulsar 从架构上就是分层架构。这样的分层架构相比以往的单体架构更加灵活，可以根据需要来进行配置存储层和处理层，更加容易维护和扩容。 Pulsar作为新一代云原生消息平台，与传统消息队列主要有以下优势： 1.天生支持云原生，它采用计算与存储分离架构设计，天生适配云原生环境，逻辑组件broker和存储组件bookie都是无状态的，可借助kubernetes的动态伸缩能力，更好的管理资源。而传统的消息队列都是有状态，若适配云原生环境，需要投入研发很多工作量进行改造。 2.可以兼容目前所有主流消息队列，pulsar作为一个融合的消息系统，除了自己的通信协议外，通过插件兼容RabbitMQ,RocketMQ,Kafka等主流消息队列。 3.分区分片的思想，分区下边又加了一层分片，完美解决了Kafka、RokcetMq 单点存储满后，扩容和数据迁移的问题的问题。计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。 4.批流一体的架构，不仅仅具备流处理平台的能力，还支持标准的消息模式。 中原银行分布式消息平台建设于2019年，目前已服务于全行28套业务系统，日均消息承载量成几何倍数增长。 下一步中原银行中间件小组将参考Pulsar的分层结构，深耕消息的proxy层建设，提升proxy层在消息追踪，消息补偿等方面的能力。一方面，轻SDK端，使SDK端只保留消息的连接、连接的断线重连、消息的生产、消息的消费等能力，消息补偿、消息去重等能力迁移到Proxy层处理；另一方面，重Proxy层，在SDK迁移到proxy层的部分能力基础上，着重建设消息追踪，消息路由等能力。构建“轻SDK，重Proxy”的机制，减少业务系统对SDK的依赖，同时降低SDK对业务系统的影响，为业务系统更好的提供消息能力。 同时，将参考pulsar的云原生能力，结合中原银行消息使用场景，吸收pulsar的多交付保证策略、跨地域复制等先进功能，持续加强消息平台云原生能力的建设，实现消息集群的弹性伸缩和自动化部署，为业务系统提供更智能、更稳定的高性能消息服务！ |
|
|
来自： 刘振东 > 《Pulsar实践》
