线上业务侧主要关注RocketMQ集群部署架构、平台系统架构、日常运维操作平台、监控告警集成实践，以及vivo如何通过构建完成所有线上服务AMQP消息网关。业务服务从RabbitMQ到RocketMQ的业务不敏感迁移，实现了在线业务消息中间件组件的统一。大数据端主要从资源隔离、流量均衡、智能动态限流、集群治理四个维度介绍了vivoKafka的最佳实践，以及Kafka核心技术架构在超大场景下的缺陷数据规模，以及未来对Pulsar组件的长期规划和建设。1.vivo分布式消息中间件现状1.1技术选型在技术选型方面，我们从吞吐量、功能特性、生态集成度、开源活跃度等多个维度对目前主流的分布式消息中间件进行了比较。最后，在线上业务端，我们选择了基于RocketMQ搭建消息平台，依托RocketMQ丰富的特性，满足业务间的削峰、解耦、异步等需求。在大数据方面，我们选择了Kafka，一个高并发、高可用、低延迟、高吞吐的分布式消息中间件。构建具有超大数据规模处理能力的统一数据接入服务和实时数仓服务。Kafka组件作为统一的数据接入服务，是大数据整个链路的咽喉，是构建大数据生态系统不可或缺的组件之一。1.2目前规模和运行指标方面，目前大数据业务端Kafka集群接入项目数百个，接入规模上万主题，集群每天处理消息数万亿条，99.99%可用性保证，单机日均处理数百亿条消息。在线业务端，RocketMQ集群接入上百个项目，接入规模上千个服务，集群每天处理数百亿条消息，100%可用性保证，平均发送时间<1ms.2.大数据侧消息中间件最佳实践2.1Kafka介绍首先我们来看一下Kafka官网的定义和发展历程。Kafka是由Apache软件基金会开源的流处理平台。它是一个高吞吐量的分布式发布订阅消息系统。具有高吞吐量、低延迟、高并发、高可用性、高扩展性等特点。Kafka于2010年由LinkedIn开源，2011年移交给Apache软件基金会孵化，2012年成为Apache软件基金会顶级开源项目。2.2Kafka在超大数据规模场景下面临的挑战在超大数据规模场景下，我们会面临以下问题？如何规划资源隔离，保证核心业务、优质业务、通用业务互不影响？如何保证集群中节点间流量均衡，减少单个节点或部分节点流量差异较大造成的资源浪费？超大数据规模场景下，如何限流保证集群的稳定性，最小化对业务可用性的影响？集群运行时间长，客户端版本多样。如何持续保证集群的高可用？接下来我将从资源隔离、流量均衡、智能动态限流、集群治理四个维度与大家分享Kafkainvivo的最佳实践。2.3资源隔离资源隔离的核心作用是避免服务之间的交互，但是如何平衡隔离粒度、资源利用率和运维成本是我们考??虑的重点。如果隔离粒度太粗，隔离效果会很差。如果隔离粒度太细，资源利用率低，运维成本增加。那么vivo在Kafka集群资源的隔离上是如何平衡三者的关系的呢？首先，我们根据业务属性和业务线两个维度对集群维度进行隔离。比如我们把集群分为商业化专用集群、监控专用集群、日志专用集群。机器资源的物理隔离是在集群维度上完成的。同时，我们在集群内部引入了资源组的概念。同一个集群中可以包含多个资源组。每个资源组可以为多个业务提供服务。资源组彼此独立。上图右上图展示了在我们没有引入资源组概念的情况下，集群中不同业务主题分区的分散情况。可以看到业务A和业务B的topic分区分布到集群中的所有broker上。如果业务A的流量爆发式增长，可能会影响到业务B。右下图是我们引入资源组概念后，不同业务topic分区的分布情况。可以看到不同业务的topic分区只会分配到自己业务所属的资源组，即使业务A流量突然增加导致机器不可用，也不会影响业务B。引入资源组概念允许我们实现集群内机器资源的逻辑隔离。因此，在资源隔离方面，我们采用了物理隔离和逻辑隔离相结合的方式来实现Kafka集群在超大数据规模场景下的资源隔离方案。2.4流量均衡流量均衡的核心作用是充分利用集群内部资源，提高资源利用率。Kafka服务是有状态服务。Kafka的技术架构设计涉及与节点绑定的主题分区。不支持将同一份数据分区存储在磁盘维度和节点维度。分区的读写请求由分区领导者所在的节点处理。因此，Kafka集群流量均衡的本质是topic分区的分布式均衡。在流量均衡方面，我们做了两个阶段的建设。第一阶段引入机器实时出入流量、cpu负载、磁盘存储等指标作为负载因子，在分区分布式均衡算法上生成分区迁移方案。分区迁移后达到流量均衡的目的。第一期流量均衡功能上线后，我们将资源组内节点间的流量差异从几百兆/秒缩小到几十兆/秒。随着集群数据规模的不断增大，我们发现每秒几十兆的流量差异仍然会造成资源浪费。因此，在二期流量均衡功能建设中，我们加入分区分布式均衡、leader分布式均衡、replica分布式均衡、磁盘均衡等Kafka元数据指标作为负载因子生成Kafka分区迁移方案，并添加多种分区迁移执行迁移提交策略。二期流量均衡功能上线后，我们将资源组内节点间的流量差异从几十兆/秒降低到不到十兆/秒。上图是我们第一期流量均衡功能上线前后资源组内节点的流量监控面板。可以看到在第一期功能上线前，资源组内节点间的流量偏差有几百兆每秒。一期功能上线后，资源组内节点间流量偏差在每秒几十兆以内，资源组内节点间流量偏差降低75%。大大提高了服务器的资源利用率。上图是我们流量均衡功能二期上线前后资源组内节点的出入口流量监控面板。可以看到，节点间的出入口流量偏差从每秒几十兆字节下降到不到十兆字节每秒，资源组中节点间的流量偏差减少了80%。效果也很明显。2.5智能动态限流限流的本质是限制客户端流量的突然增加，保证服务器的可用性。避免客户端流量突然增加导致服务器整体不可用。如何平衡限流的粒度、限流阈值的设置、资源利用率和服务器稳定性？这是我们需要思考的。如果限流粒度太粗，限流效果会很差。当大部分业务的流量同时突然增加时，会给服务器的稳定性带来风险。如果限流粒度太细，服务器将无法应对突然增加的客户服务流量。如果限流阈值设置过高，会给服务器的稳定性带来风险。如果限流阈值设置得太小，服务器的资源利用率会很低。在限流方面，首先我们采用多平台联诊机制，根据项目实际生产数据判断是否需要进行流量调整，计算出调整后的限流阈值。其中，多个平台包括（JMX统一指标采集平台、统一监控平台、统一告警平台、Kafka集群管理平台等）。二、智能分析Kafka集群服务资源的负载情况，计算各资源的剩余状态。判断是否可以调整阈值，并根据客户实际生产数据计算阈值调整多少为宜。第三，实时自动调整限流阈值。通过以上三个步骤实现了智能动态限流方案。解决了限流粒度、限流阈值设置、资源利用率、Kafka集群可用性之间的平衡关系。智能动态限流的实现给我们带来了以下明显的好处。大幅提升Kafka集群服务器应对客户端流量骤增的能力。通过使用项目的移峰方式，进一步提高了Kafka集群的资源利用率。项目限流阈值智能自动调整，无需人工干预，大大降低了Kafka集群在超大数据规模场景下的运维成本。根据服务器的负载动态调整项目的限流阈值，最大限度降低限流对业务可用性的影响。2.6集群治理Kafka集群元数据由ZooKeeper集群统一管理。元数据信息永久有效，永不过期。元数据由KafkaController节点发布。Topic数量达到数万，Partition数量达到数十万。元数据治理可以有效避免元数据规模对Kafka集群稳定性的影响。随着连接的服务和Kafka用户越来越多，正确使用Kafka客户端也可以大大提高Kafka服务器的稳定性和资源利用率。Kafka分区绑定到磁盘目录。在创建主题和扩展主题分区时，根据主题流量适当设置主题分区的数量，可以有效防止单机或单盘性能瓶颈成为集群整体性能瓶颈。在Kafka集群管理方面，vivo实现了节点流量偏差管理、主题元数据管理、主题分区数据倾斜管理、主题超大分区管理、主题消费延迟管理等解决方案，为Kafka集群的高可用保驾护航。2.7实践经验积累vivoKafka消息中间件团队在三年内根据实际业务场景和生产数据规模积累了大量的实践经验。比如在高可用/高扩展性方面，实现了机架感知、弹性伸缩、数据压缩。在监控告警方面，提供用户流量限流告警、话题流量暴增告警、消费延迟告警、领导者实时监控告警。多平台联合故障感知与告警等能力建设。我们为Kafka集群做了大量的扩容能力建设。是否解决了Kafka集群在超大数据规模场景下的所有问题？答案是否定的。下面我们来看看Kafka集群在超大数据规模场景下面临的新挑战。2.8Kafka技术架构在超大数据规模场景带来的缺陷不支持去中心化存储，不支持存储计算分离，不支持冷热数据分层存储等设计缺陷在数据规模非常大的场景下尤为明显。因此，Kafka集群在超大数据规模场景下面临以下痛点。资源利用率低。无法快速响应业务增长。故障恢复时间长。历史数据消费失败率高（主要体现在磁盘io性能上）。2.9大数据侧分布式消息中间件的未来规划基于上述Kafka架构设计的缺陷，vivoKafka团队于2021年开始对另一款开源分布式消息中间件Pulsar进行研究。2.9.1简介Pulsar先来看看Pulsar官网的定义和发展历程：Pulsar是Apache软件基金会的顶级开源项目。是集消息、存储、轻量级函数计算为一体的下一代云原生分布式消息流组件，采用计算与存储分离的架构设计，支持多租户、持久化存储、多机房跨地域数据复制，具有高并发、高吞吐、低延迟、高扩展、高可用等特点。Pulsar于2012年诞生于雅虎内部，2016年开源交给Apache软件基金会孵化。2018年成为Apache软件基金会顶级开源项目。2.9.2Pulsar的核心优势基于Pulsar支持存储计算分离、分区数据分布式存储、冷热数据分层存储、无状态Broker架构设计，使得Pulsar拥有高资源大规模数据场景下的利用率和快速响应。具有业务增长、秒级故障恢复、实时流量均衡、支持海量数据存储等明显优势。2.9.3Pulsar未来规划我们对Pulsar组件的规划分为立项、稳定建设、能力提升、稳定运行四个阶段。我们目前正处于Pulsar组件的稳定性建设阶段。2022年，我们的目标是打造一个支持日万亿级消息处理能力、完整的分级存储、监控告警集成、KoP功能平台化等扩展能力的Pulsar集群。计划在2023年建成日均消息处理能力10万亿条的Pulsar集群，达到业界一流水平。并完成Pulsarbroker容器化部署、Pulsar生态建设、PulsarSql和PulsarFunction应用研究等拓展能力建设。2024年实现日均数十万亿消息处理能力的Pulsar集群，达到业界一流水平。3.在线业务消息中间件最佳实践3.1RocketMQ简介RocketMQ是阿里巴巴于2012年开源的一款低延迟、高并发、高可用、高可靠的分布式消息中间件，具有海量消息积累、高吞吐量、可靠重试等特性。RocketMQ于2012年开源，2016年进入Apache孵化，2017年成为Apache顶级项目。3.2RocketMQ在vivo内部使用现状vivo中间件团队将在2021年引入RocketMQ，完成高可用和平台化建设。目前在多个机房部署了多个集群供业务使用，日消息量上百亿级。集群分布在多个机房，每天消息量不低。难以保障高可用运维。3.3vivo基于RocketMQ高可用保障的实践经验3.3.1集群部署架构介绍为了更好的保证集群的高可用，我们采用了双机房热备的方式来搭建集群。我们将Broker部署在两个机房，业务topic默认分布在两个机房，保证在一个机房的Broker节点出现异常时，业务也能保持正常的生产和消费能力。默认情况下，业务会优先使用机房内的节点进行生产和消费，只有在出现异常时才会自动快速完成跨机房的流量切换。同时，我们构建了一个BrokerController模块来实现Broker节点的主从切换，从而保证集群容量的快速恢复。双机房热备模式有哪些优势？第一，消息不需要跨机房复制，减少对机房专线的依赖；二是可以降低业务消息发送的延迟，提高业务处理性能；双机房热备模式的缺点是每个机房的节点都需要一定的冗余缓冲来支撑其他机房节点出现异常时自动转移的业务流量。3.3.2平台系统架构介绍集群双机房热备部署模式是消息平台高可用的基石。此外，我们还构建了多个平台模块，以确保平台的高可靠性。如上图所示，使用mq-rebalance模块来支持集群流量的自动负载均衡；mq-monitor模块采集监控指标，对接vivo内部监控系统；mq-recover模块主要用于业务流量处理的降级和恢复；mq-live模块用于集群检测。此外，我们还基于社区的connector组件构建了RabbitMQ-connector，实现全局消息路由能力。未来我们计划构建一个基于gRPC协议的通用消息网关，实现与集群的交互，屏蔽不同的消息中间件选择。3.3.3平台化运维能力提升运维效率主要有以下三种做法：一是RocketMQ集群配置平台化管理。RocketMQ集群包含很多配置项，默认通过节点文件进行管理，在大规模集群运维过程中会存在维护困难。通过平台化管理，保证集群内的配置统一。节点在启动时可以从平台读取所有配置，避免集群部署时需要登录机器进行配置维护，我们支持集群配置的动态验证。二是平台化运维操作，如Broker节点的流量移除和挂载、主题的一键式扩缩容等，由平台直接支持，实现便捷的运维。第三，集群维护平台化。我们在平台上维护集群和Broker节点的关系，在第一次部署的时候分配Broker节点所在的集群，这样平台上集群信息一目了然，方便我们维护和管理多组集群。3.3.4平台监控告警能力建设一方面，我们为每个集群搭建了如上图所示的监控面板。在监控仪表盘中，有各集群的生产消费流量、业务生产消费统计、发送时间等信息，支持我们快速观察集群的运行状态，方便日常巡检。消息中间件作为线上业务请求处理环节中的关键一环，对于高可用尤为关键。监控大盘发送耗时信息是观察集群是否稳定运行最关键的指标。另一方面，我们为集群构建了丰富的监控告警能力。如上图所示，我们分别上报了host维度、cluster维度、topic/group维度、client维度的监控指标。通过丰富的监控告警，及时发现问题，快速介入处理。详细的监控告警也可以帮助我们快速确认问题的根源。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.2AMQP消息网关架构支持实现无感知迁移由于RabbitMQ已经有上千个服务接入，为了让业务不修改代码也可以迁移到RocketMQ，我们搭建了一个AMQP消息网关实现无感知迁移MQ协议。流量转发。如上图所示，MQ-Proxy模块用于解析AMQP协议，代理客户端的生产和消费请求。RabbitMQ的元数据信息存在于集群中，与RocketMQ元数据的概念不同。为此，我们构建了MQ-Meta模块来维护Exchange/Queue等元数据信息及其绑定关系，Proxy模块可以动态感知元数据。数据变化。另外，为了更好的支持业务需求，我们扩展了AMQP协议，支持本地点单和批量消费能力。3.4.3RabbitMQ和RocketMQ元数据的概念映射为了更好的集成RabbitMQ和RocketMQ，我们将它们的元数据做了一一对应。其中，RabbitMQ的Exchange映射到RocketMQ的Topic，Queue映射到Group，RoutingKey映射到消息头的一个参数，VirtualHost映射到Namespace。为什么要将RoutingKey映射为消息头的参数而不是Tag？这是因为RabbitMQ的RoutingKey具有模糊匹配和过滤功能，而RocketMQ的Tag不支持模糊匹配。另外，我们还对RocketMQ进行了扩展，支持RoutingKey过滤。经过多轮优化，在1KB消息体场景下，8C16G机器单次发送可支持9万以上TPS，单次推送可支持6万以上TPS，性能满足当前业务需求。上诉。3.5在线业务消息中间件的未来规划主要有两个部分：一方面希望调研升级到RocketMQ5.0版本架构，RocketMQ5.0的存储计算分离架构可以更好的解决存储瓶颈我们目前遇到的问题，Pop消费可以帮助我们实现更好的消费负载均衡。我们也希望基于gRPC协议构建统一的消息网关能力。另一方面，我们希望探索消息中间件的容器化部署，提供消息中间件快速弹性伸缩的能力，更好地支撑业务需求。4.总结回顾vivo消息中间件的进化史，我们完成了在线业务消息中间件从RabbitMQ到RocketMQ的迁移，大数据消息中间件正在从Kafka进化到使用pulsar支持。我们了解到，消息中间件将不断向云原生方向演进，以满足业务快速增长的需求，充分利用云的优势，提供极致的业务体验。
