作者：vivo 互联网存储技术团队-Luo Mingbo、中间件团队- Liu Runyun
本文依据“2022 vivo开发者大会"现场演讲内容整顿而成。
本文次要介绍超大数据规模场景下分布式消息中间件在vivo的利用实际。
在线业务侧次要从RocketMQ集群部署架构、平台零碎架构、日常运维操作平台、监控告警一体化实际以及vivo如何通过建设AMQP音讯网关的形式实现所有在线业务服务从RabbitMQ到RocketMQ的业务无感迁徙，实现了在线业务消息中间件组件的对立。
大数据侧次要从资源隔离、流量平衡、智能动静限流、集群治理四个维度介绍Kafka在vivo的最佳实际以及Kafka核心技术架构在超大数据规模场景下的缺点以及将来对Pulsar组件的长线布局和建设。
一、分布式消息中间件在vivo的经营现状
1.1 技术选型
在技术选型上，咱们从吞吐量、性能个性、生态集成、开源沉闷等多个维度比照了以后支流的分布式消息中间件，最终在线业务侧咱们抉择基于RocketMQ构建音讯平台，依靠RocketMQ丰盛的性能个性满足业务间削峰、解耦、异步化的需要。
大数据侧咱们抉择具备高并发、高可用、低提早、高吞吐能力的分布式消息中间件Kafka。构建超大数据规模解决能力的对立数据接入服务和实时数仓服务。Kafka组件作为对立数据接入服务，是大数据全链路中的咽喉要道，是大数据生态体系建设中不可或缺的重要组件之一。
1.2 规模现状
经营指标方面目前大数据业务侧Kafka集群接入我的项目数百、接入规模方面Topic数量达到数万、集群日均解决音讯达数十万亿条、可用性保障99.99%、单机日均解决音讯达数百亿条。
在线业务侧RocketMQ集群接入我的项目数百、接入规模方面接入数千服务、集群日均解决音讯达数百亿条、可用性保障100%，发送均匀耗时<1ms。
二、大数据侧消息中间件最佳实际
2.1 Kafka简介
首先咱们看下Kafka的官网定义及倒退历史，Kafka是由Apache软件基金会开源的一个流解决平台，是一种高吞吐量的分布式公布订阅音讯零碎。具备高吞吐、低提早、高并发、高可用、高可扩等个性。
Kafka是由LinkedIn公司在2010年开源，2011年交由Apache软件基金会进行孵化，2012年成为Apache软件基金会的顶级开源我的项目。
2.2 Kafka在超大数据规模场景下面临的挑战
在超大数据规模场景下咱们会面临以下几个问题？
- 如何布局资源隔离保障外围业务、高优业务、个别业务之间互相不受影响？
- 如何保障集群外部节点间流量平衡，升高单节点或局部节点流量差别太大带来的资源节约？
- 超大数据规模场景下如何进行限流保障集群的稳定性并尽可能升高对业务可用性的影响？
- 集群长期运行，客户端版本多样，如何继续保障集群的高可用性？
上面我将从资源隔离、流量平衡、智能动静限流、集群治理四个维度和大家一起交换Kafka在vivo的最佳实际。
2.3 资源隔离
资源隔离的核心作用在于防止业务与业务之间的相互影响，但隔离粒度、资源利用率、运维老本之间如何进行衡量，是咱们须要思考的重点。隔离粒度太粗会导致隔离成果不佳，隔离粒度太细会导致资源利用率较低、运维成本增加。
那vivo在Kafka集群资源隔离上是如何均衡三者关系的呢？
首先咱们依据业务属性、业务线两个维度进行集群维度的隔离，例如咱们在集群划分上分为了商业化专用集群，监控专用集群，日志专用集群等。在集群维度做了机器资源的物理隔离。
同时咱们在集群外部引入了资源组的概念。同一个集群外部能够蕴含多个资源组。每个资源组能够为多个业务提供服务。资源组与资源组之间互相独立。
上图中右上图是咱们没有引入资源组概念时集群外部不同业务Topic分区的扩散状况，大家能够看到业务A和业务B的Topic分区扩散到集群内的所有broker上，若业务A的流量突增可能会造成业务B受到影响，右下图是咱们引入资源组概念后不同业务Topic分区的扩散状况，能够看到不同业务的topic分区只会调配到本人业务所属的资源组内，即便业务A的流量突增导致机器不可用也不会对业务B造成影响。
引入资源组概念后让咱们能在集群外部实现机器资源的逻辑隔离。所以咱们在资源隔离方面采纳了物理隔离和逻辑隔离两种形式相结合，实现了在超大数据规模场景下Kafka集群的资源隔离计划。
2.4 流量平衡
流量平衡的核心作用在于充分利用集群外部资源，晋升资源利用率。Kafka服务作为一个有状态的服务，Kafka在技术架构设计上Topic分区与节点绑定，不反对分区同一正本数据在磁盘和节点维度扩散存储。对分区的读写申请都由分区Leader所在节点进行解决。所以Kafka集群流量平衡的实质是Topic分区的扩散平衡。
在流量平衡方面咱们做两期的建设，第一期咱们在分区扩散平衡算法上引入机器的实时出入流量、cpu负载、磁盘存储等指标作为负载因子生成分区迁徙打算。执行分区迁徙后达到流量平衡的目标。流量平衡一期性能上线后咱们将资源组内节点间流量差别从数百兆/s升高到数十兆/s。随着集群数据规模的继续减少，咱们发现数十兆/s的流量差别仍然会造成资源节约。
所以在流量平衡二期性能建设上咱们减少了分区扩散平衡、Leader扩散平衡、正本扩散平衡、磁盘平衡等Kafka元数据指标作为负载因子生成Kafka分区迁徙打算，并在分区迁徙执行上减少了多种迁徙提交策略。流量平衡二期性能上线后咱们将资源组内节点间流量差别从数十兆/s升高到十兆以内/s。
上图是咱们流量平衡一期性能上线前后资源组内节点的流量监控面板，能够看到一期性能上线前资源组内节点间的流量偏差在数百兆/s。一期性能上线后资源组内节点间流量偏差在数十兆/s以内，资源组内节点间流量偏差升高75%。极大晋升了服务端的资源利用率。
上图是咱们流量平衡二期性能上线前后资源组内节点的入出流量监控面板，能够看到节点间入出流量偏差从数十兆/s升高到十兆以内/s，资源组内节点间流量偏差升高80%。成果也是非常明显。
2.5 智能动静限流
限流的实质是限度客户端的流量突增以确保服务端的可用性。防止客户端的流量突增导致服务端整体不可用。限流的粒度，限流阈值的设定，资源利用率、服务端稳定性之间应该如何做衡量呢？是咱们须要思考的重点。限流粒度太粗会导致限流成果不佳，当大部分业务同时流量突增会对服务端的稳定性带来危险。限流粒度太细服务端应答客服端流量突增能力有余，限流阈值设置太大会给服务端稳定性带来危险，限流阈值设置太小会导致服务端资源利用率较低。
限流方面，
- 首先咱们采纳多平台联结诊断机制依据我的项目理论生产数据状况判断是否须要进行流量调整，计算调整后的限流阈值。其中多平台蕴含（JMX对立指标采集平台，对立监控平台、对立告警平台、Kafka集群治理平台等）。
- 第二、智能剖析Kafka集群服务资源负载状况，计算各资源残余状况。确定是否能够进行阈值调整并联合客户端理论生产数据状况计算阈值调整到多少适合。
- 第三、主动实时调整限流阈值。
通过以上三步实现智能动静限流计划。解决了限流粒度、限流阈值设定、资源利用率、Kafka集群可用性四者之间的均衡关系。
实现智能动静限流后给咱们带来以下几点显著的收益。
- 大大晋升Kafka集群服务端应答客户端流量突增的能力。
- 利用我的项目错峰的形式进一步晋升Kafka集群的资源利用率。
- 智能化主动调整我的项目限流阈值无需人工染指，大大降低Kafka集群在超大数据规模场景下的运维老本。
- 动静依据服务端负载状况调整我的项目限流阈值，尽可能减小限流对业务可用性的影响。
2.6 集群治理
Kafka集群元数据对立由ZooKeeper集群治理，元数据信息永恒无效永不过期，元数据的下发由Kafka Controller节点对立下发，随着业务的一直倒退，数据规模的一直减少，集群外部Topic的数量达到万级，分区数量达到数十万级。元数据治理能无效防止元数规模给Kafka集群稳定性带来的影响。随着接入的服务、Kafka用户越来越多，正确的应用Kafka 客户端也能大大晋升Kafka服务端的稳定性和资源利用率。Kafka分区与磁盘目录绑定，创立Topic、Topic分区扩容时依据Topic流量正当设置Topic分区数能无效防止单机或单盘性能瓶颈成为集群整体的性能瓶颈。
vivo在Kafka集群治理方面实现了节点流量偏差治理、Topic元数据治理、Topic分区数据歪斜治理、Topic超大分区治理、Topic生产提早治理等计划为Kafka集群的高可用性保驾护航。
2.7 实践经验积淀
vivo Kafka消息中间件团队在三年工夫内，依据理论的业务场景和生产数据规模积淀了较多的实践经验。例如在高可用/高可扩方面实现了机架感知、弹性伸缩、数据压缩等能力建设，在监控告警方面提供了用户限流告警、Topic流量突增告警、生产提早告警、Leader实时监控告警，多平台联结故障感知告警等能力建设。咱们为Kafka集群做了很多的扩大能力建设，那解决了Kafka集群在超大数据规模场景下的所有问题了吗？答案是否定的。
接下来咱们一起看看Kafka集群在超大数据规模场景下面临的新挑战。
2.8 Kafka在超大数据规模场景下由技术架构带来的缺点
由Kafka架构设计所带来的一些痛点无奈通过扩大能力解决，并且Kafka架构设计上分区同一正本数据与磁盘强绑定不反对扩散存储、不反对存储与运算拆散、不反对冷热数据分层存储等设计缺点在超大数据规模场景下显得尤为显著。所以在超大数据规模场景下Kafka集群面临了以下几个痛点。
- 资源利用率低。
- 无奈疾速响应业务增长。
- 故障复原工夫长。
- 历史数据生产故障率高（次要体现在磁盘io性能上）。
2.9 大数据侧分布式消息中间件将来布局
基于以上Kafka在架构设计上的缺点，vivo Kafka团队于2021年开始对另一款开源分布式消息中间件Pulsar进行调研。
2.9.1 Pulsar简介
咱们看下Pulsar的官网定义及发展史：Pulsar 是 Apache软件基金会的顶级开源我的项目，是集音讯、存储、轻量化函数式计算为一体的下一代云原生分布式音讯流组件，采纳了计算与存储拆散的架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备高并发、高吞吐、低延时、高可扩，高可用等个性。
Pulsar 诞生于2012 雅虎公司外部，2016年开源交由Apache软件基金会进行孵化，2018年成为Apache软件基金会顶级开源我的项目。
2.9.2 Pulsar外围劣势
基于Pulsar反对存算拆散，分区数据扩散存储、冷热数据分层存储、Broker无状态等架构设计，让Pulsar在超大数据规模场景下具备了资源利用率较高、疾速响应业务增长、秒级故障复原、实时流量平衡、反对海量数据存储等显著劣势。
2.9.3 Pulsar将来布局
咱们对Pulsar组件的布局分为四个阶段，蕴含我的项目启动、稳定性建设、能力进阶、稳固经营。
目前咱们处在Pulsar组件稳定性建设阶段。
2022年咱们的指标是打造反对日均万亿级音讯解决能力的Pulsar集群，实现分层存储，监控告警一体化、KoP性能平台化等扩大能力建设。
打算2023年打造具备日均十万亿级音讯解决能力的Pulsar集群，达到行业一流水准。并实现Pulsar broker容器化部署、Pulsar生态体系建设、Pulsar Sql和Pulsar Function的利用调研等扩大能力建设。
将在2024年实现日均数十万亿级音讯解决能力的Pulsar集群，达到行业超一流的水准。
三、在线业务侧消息中间件最佳实际
3.1 RocketMQ简介
RocketMQ是阿里巴巴于2012年开源的低延时、高并发、高可用、高牢靠的分布式消息中间件，具备海量音讯沉积、高吞吐、牢靠重试等个性。
RocketMQ于2012年开源，2016年进入Apache孵化，于2017年成为Apache顶级我的项目。
3.2 RocketMQ在vivo外部应用现状
vivo中间件团队在2021年引入RocketMQ并且实现了高可用和平台化建设。
以后别离在多个机房部署了多个集群供业务应用，每日音讯量数百亿。
集群散布在多个机房，每日音讯量级也不低，高可用运维保障是有难度的。
3.3 vivo基于RocketMQ的高可用保障实践经验
3.3.1 集群部署架构介绍
为了更好的保障集群的高可用，咱们采纳了双机房热备的形式进行集群搭建。
咱们会在两个机房进行Broker的部署，业务Topic会默认散布在两个机房，以此来保障在一个机房内的Broker节点异样时业务能够放弃失常生产生产能力。
业务默认是会优先应用本机房的节点进行生产生产，只有在异样时才会主动疾速实现跨机房的流量切换。
同时咱们构建了一个BrokerController模块用于实现Broker节点的主从切换，以此保障集群容量的疾速复原。
双机房热备模式有哪些劣势呢？
- 第一，音讯无需跨机房复制，升高对机房专线的依赖；
- 第二，能够升高业务发送音讯的延时，也能够晋升业务的解决性能；
双机房热备模式的劣势是每个机房的节点都须要冗余肯定的buffer来撑持其它机房的节点异样时主动转移过去的业务流量。
3.3.2 平台零碎架构介绍
集群双机房热备部署模式是音讯平台的高可用基石，在此之外咱们还建设了多个平台模块来保障平台的高牢靠。
如上图所示，
- mq-rebalance模块用于撑持集群流量的主动负载平衡；
- mq-monitor模块进行监控指标的采集并且与vivo外部的监控零碎买通；
- mq-recover模块次要用于业务流量的降级和复原解决；
- mq-live模块用于集群的探活。
另外咱们还基于社区的connector组件建设了RabbitMQ-connector，实现了寰球音讯路由能力。
后续咱们打算建设基于gRPC协定建设通用的音讯网关实现与集群的交互，以此屏蔽不同的消息中间件选型。
3.3.3 运维能力平台化晋升运维效率
次要有三点实际：
第一，RocketMQ集群配置平台化治理。RocketMQ集群含有较多的配置项，默认是通过节点文件治理的，在大规模集群运维过程中会存在保护艰难的问题。
通过平台化治理能够确保集群内配置对立，节点在启动时从平台中读取到所有的配置，防止在集群部署时须要登录到机器进行配置保护，并且咱们反对了集群配置的动静失效。
第二，运维操作平台化，例如Broker节点的流量摘除与挂载、Topic一键扩缩容等间接通过平台撑持，实现便捷运维。
第三，集群保护平台化，咱们将集群与Broker节点的关系保护在平台中，并且在首次部署时调配Broker节点所在集群，这样在平台上就有清晰的集群信息，便于咱们保护治理多套集群。
3.3.4 平台监控告警能力建设
- 一方面，咱们为每个集群都建设了如上图所示的监控大盘。
在监控大盘中有每个集群的生产生产流量、业务生产生产统计、发送耗时等信息，撑持咱们疾速察看集群的运行状态，不便日常巡检。
消息中间件作为在线业务申请解决链路中的关键环节，高可用尤为要害。监控大盘中的发送耗时信息是咱们认为察看集群是否稳固运行的最要害的指标。
- 另一方面，咱们对集群构建了丰盛的监控告警能力。
如上图所示，咱们别离对主机维度、集群维度、Topic/Group维度、客户端维度都做了监控指标埋点上报。
通过丰盛的监控告警，咱们能够及时发现问题并疾速染指解决问题，具体的监控告警也能够帮忙咱们疾速确认问题本源。
3.4 业务从RabbitMQ无感迁徙到RocketMQ实战经验
3.4.1 应用RocketMQ替换RabbitMQ根因剖析
别离从可用性保障、性能、容量、性能个性比照RabbitMQ和RocketMQ。
- 可用性保障方面，RabbitMQ集群无负载平衡能力，队列流量理论由集群内某个节点承载，存在瓶颈。其次RabbitMQ存在脑裂问题，从咱们的运维教训看如果呈现网络故障集群通常无奈主动复原，并且可能失落大量数据。
- 性能方面，RabbitMQ集群整体性能较低，并且不反对程度扩大。
- 容量方面，从咱们的运维教训看，当音讯沉积到千万后，RabbitMQ性能就会有所降落。在大量音讯沉积开始生产后，因为RabbitMQ的背压流控机制，最终可能会因为集群负载过大导致发送限流甚至发送阻塞。
- 性能个性方面，RabbitMQ不反对生产异样延时重投递性能，也不反对音讯轨迹、事务音讯、程序音讯等个性。
而RocketMQ在可用性保障、性能、容量、性能个性方面绝对于RabbitMQ都是更优的。
- 可用性保障方面，RocketMQ采纳多主多从的松耦合架构部署，主从间通过同步双写保障音讯的可靠性和一致性。
- 性能方面，Topic能够散布在多个Broker中，实现程度扩容，并且RocketMQ反对从从节点拉取音讯，读写拆散的设计很好的反对了业务读取冷数据的诉求。
- 容量方面，RocketMQ应用磁盘存储，磁盘容量就是音讯的存储容量，利用从从节点拉取冷数据个性，海量音讯沉积对音讯写入性能根本无影响。
- 性能个性方面，RocketMQ反对了音讯轨迹、事务音讯、程序音讯等个性。
综合剖析，RocketMQ能够更好的撑持互联网业务的诉求。
3.4.2 AMQP音讯网关架构撑持实现无感迁徙
因为以后RabbitMQ曾经有数千个服务接入，为了让业务不批改代码即可迁徙到RocketMQ，咱们建设了一个AMQP音讯网关来实现MQ协定的解析和流量转发。
如上图所示，MQ-Proxy模块用于解析AMQP协定，代理客户端的生产生产申请。
RabbitMQ的元数据信息存在在集群中，并且与RocketMQ元数据概念存在差别，为此咱们建设了MQ-Meta模块用于保护Exchange/Queue极其绑定关系等元数据信息，并且Proxy模块能够动静感知元数据变更。
另外，为了更好的撑持业务诉求，咱们对AMQP协定进行了扩大，反对了部分有序和批量生产能力。
3.4.3 RabbitMQ和RocketMQ元数据概念映射
为了更好的整合RabbitMQ和RocketMQ，咱们对它们的元数据进行了一一对应。
其中将RabbitMQ的Exchange映射为RocketMQ的Topic，Queue映射为Group，RoutingKey映射为音讯头的一个参数，VirtualHost映射为Namespace。
为什么将RoutingKey映射为音讯头的一个参数而不是Tag呢？这是因为RabbitMQ的RoutingKey是有含糊匹配过滤能力的，而RocketMQ的Tag是不反对含糊匹配的。
另外咱们还通过扩大使得RocketMQ也反对了RoutingKey过滤。
在通过多轮优化后，在1KB音讯体场景下，一台8C16G的机器在单发送下可撑持超过九万的TPS，单推送能够撑持超过六万TPS，性能上很好的满足了以后业务的诉求。
3.5 在线业务消息中间件的将来布局
次要有两局部：
一方面，咱们心愿能够调研降级到RocketMQ5.0版本架构，RocketMQ5.0的存算拆散架构能够更好的解决咱们以后遇到的存储瓶颈问题，Pop生产能够帮忙咱们实现更好的生产负载平衡。
咱们还心愿能够基于gRPC协定建设对立的音讯网关能力。
另一方面，咱们心愿能够摸索消息中间件容器化部署，提供消息中间件的疾速弹性扩缩容能力，更好的反对业务需要。
四、总结
回顾vivo消息中间件演进历史，咱们实现了在线业务消息中间件从RabbitMQ迁徙到RocketMQ，大数据消息中间件正在从kafka演进为应用pulsar撑持。
咱们了解消息中间件将持续朝着云原生演进，满足业务快速增长的诉求，充分利用云的劣势为业务提供极致的体验。