构建下一代万亿级云原生消息架构：Apache Pulsar 在 vivo 的探索与实践作者|陈建波、全利民本文整理

作者|陈建波、全利民
本文整理自vivo互联网大数据工程师陈建波与全利民在ApachePulsarMeetup上的演讲《ApachePulsar在vivo的探索与实践》，介绍vivo在集群管理与监控上应用Pulsar的实践。
vivo移动互联网为全球4亿+智能手机用户提供互联网产品与服务。其中， vivo分布式消息中间件团队主要为vivo所有内外销实时计算业务提供高吞吐、低延时的数据接入、消息队列等服务，覆盖应用商店、短视频、广告等业务。业务集群已达每天十万亿级的数据规模。

文章图片
图1.vivo分布式消息中间件系统架构
上图为系统的整体架构，其中数据接入层包括数据接入、数据采集服务，支持SDK直连；消息中间件由Kafka和Pulsar共同承担，其中Pulsar的承载量达到千亿级别；数据处理部分使用Flink、Spark等组件。
目前， Kafka采用多集群方式，根据不同的业务量级、重要性分别使用不同的集群提供服务，比如计费集群、搜索集群、日志集群。在Kafka集群的内部，则采用物理隔离的方式，根据不同业务的重要性，将不同业务的Topic控制在不同的资源组内，避免业务之间相互影响。

文章图片
图2.Kafka集群资源隔离

文章图片
图3.Kafka集群流量均衡
资源组内部则会针对Topic流量、分区分布、磁盘容量、机器机架等指标生成迁移计划进行流量均衡，以此增强Kafka可靠性。目前Kafka已在多集群部署、资源隔离、流量均衡三个方面保障了基本的稳定性和资源利用率，但是在此之外，系统仍存在一些问题。
1应对业务流量数十倍增长，引入ApachePulsar
过去几年来， Kafka集群承载的业务量迅速增长，流量上涨数十倍，带来诸多问题：Topic及Topic分区总量不断增加，集群性能受到影响：Kafka高性能依赖于磁盘的顺序读写，磁盘上大量分区导致随机读写加重；业务流量增加迅速，存量集群变大，需要将老的业务进行资源组隔离迁移或者集群拆分。无论是资源组隔离还是集群的隔离的方式，由于集群不可以进行动态扩缩容，机器不能够进行灵活调配，都存在利用率不高、运维成本增加的问题；机器扩容慢，需要做长时间流量均衡，难以应对突发流量。集群规模越大，问题越突出；消费端性能扩展太依赖分区扩容，导致集群元数据疯狂增长；集群数量对应的机器基数大，硬件故障概率高，出现硬件故障时影响会直接传导到客户端，缺少中间层容错。
面对庞大的集群、流量和多样化的业务场景，综合考虑集群的稳定性和维护成本等因素， vivo需要一个功能更丰富、适用更多场景、扩展能力更强的消息组件。
Pulsar如何解决vivo存在的问题，可以首先看一下Pulsar的架构设计。 Pulsar采用计算存储层分离架构。计算层的Broker节点是对等且无状态的，可以快速扩展；存储层使用BookKeeper作为节点，同样节点对等。这种分离架构支持计算和存储层各自独立扩展。

文章图片
图4.Pulsar存储计算分离
其次， Pulsar的各个节点都是轻量化的，在出现故障和宕机时可以快速恢复。一般情况下可以通过快速上下线来解决某个节点机器的问题。同时Broker层可以作为BookKeeper层的容错层，可以防止故障直接传导至用户端。
Pulsar扩容时无需长时间的数据迁移，且支持实时均衡。 Broker层抽象了Bundle概念，可以用有限的Bundle映射海量Topic ， Topic可以随着Bundle迁移，通过动态迁移Bundle可以更好地应对流量突发场景。 BookKeeper分层分片的架构让数据分布均匀，在Broker层有一个选择机制，在扩容时可以将数据写入存储量小的节点，扩容时无需数据迁移，提供更好的流量高峰应对能力。 Bookie进行数据刷盘时会对批量数据自动进行数据排序，可以避免Kafka中的随机读写。