共计 7936 个字符，预计需要花费 20 分钟才能阅读完成。
作者：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 撑持。
咱们了解消息中间件将持续朝着云原生演进，满足业务快速增长的诉求，充分利用云的劣势为业务提供极致的体验。
