网易云音乐的消息队列改造之路

  • 时间:
  • 浏览:0

十年文案老司机,不如网易评论区。

网易云音乐自2013年上线后,业务保持了高速增长。云音乐除了提供好听的音乐外,还留下了朋友在乐和人上的美好回忆。本文分发自网易云音乐消息队列负责人林德智在近期 Apache Flink&RocketMQ Meetup 上海站的分享,通过该文,您将了解到:

  • 网易云音乐消息队列改造背景
  • 网易云音乐业务对消息队列要求
  • 网易云音乐消息队列分发
  • 网易云音乐消息队列每项高级社会形态介绍
  • 网易云音乐消息队列落地使用具体情况
  • 网易云音乐消息队列未公开规划

背景

网易云音乐从13年4月上线以来,业务和用户突飞猛进。后台技术也从传统的 Tomcat 集群到分布式微服务快速演进和迭代,在业务的不断催生下,诞生了云音乐的 RPC,API 网关和链路跟踪等多种服务,消息队列也从 RabbitMQ 集群迁移到 Kafka集群。对于消息队列,更多指在使用阶段,也在使用中再次出现 所以 什么的问提。其他朋友期望提供你这个 删改可控,再次出现 什么的问提朋友其他人能排查,能跟踪,可不上能根据业务需求做定制改造的消息队列。

调研结果



RabbitMQ 其他持久化场景下的吞吐量可不上能了2.16万,可不上能了满足朋友业务吞吐量的需求,云音乐在 2017 年将消息队列从 RabbitMQ 迁移到 Kafka 也是你你这个 意味着着,其他不再考虑范围之内。其他云音乐整体业务的 QPS 较高,其他,ActiveMQ 本来在考虑范围。

这里主要对比 RocketMQ 与 Kafka:



Kafka 更偏向大数据,日志处理,缺少死信,消费失败自动重试,事物消息,定时消息,消息过滤,广播消息等社会形态,另外 Kafka 这么 同步刷盘。云音乐的业务更偏向于多 Topic,死信可溯源,消费失败可收敛自动重试,高可用,自动 Failover 等社会形态。对于商城和社交业务来说,事物,顺序 Topic 使用会比较多。Kafka 和RocketMQ 对比 :

http://jm.taobao.org/2016/03/24/rmq-vs-kafka

经过 RabbitMQ,Kafka 和 RocketMQ( ActiveMQ 性能较差,暂不考虑)的调研和分析后,朋友发现 RocketMQ 比较适合云音乐的通用业务,其他开源 RocketMQ 可不上能 其他匮乏,可不上能了朋友处理了什么匮乏不能在业务中大规模使用。

开源 RocketMQ 的基本架构如下:(基本介绍参考)

开源 RocketMQ 主要什么的问提有:

  • Broker 仅提供了 Master 到 Slave 的基因重组,这么 Failover 切换的能力;
  • 事物消息不开源(朋友刚开始了了英文研发时不开源);
  • 消息发送消费无追踪(朋友刚开始了了英文研发时不开源);
  • 告警与监控体系这么 ;
  • 开源控制台不完善。

云音乐业务对消息队列的要求



朋友期望消息队列具备宕机 Failover 能力,根据不同业务场景提供不同 QOS 能力,如商城消息可不上能了丢失,交易事物消息支持,消息发送消费追踪,失败排查等能力。

同時 对业务比较关心的发送耗时,消费耗时,消费延迟,消费失败异常等提供监控和告警能力。同時 对运维比较关心的整体运行水位和各项指标提供监控大盘,以及排查发现消息队列自身什么的问提与长期运维能力。

另外云音乐少每项业务是 Nodejs 和 Python 的,朋友提供 HTTP 协议接入能力。

分发

整体架构如下: 

以开源 RocketMQ 为内核,删改继承开源 RocketMQ 具备的社会形态。为满足高可用,朋友增加了 failover 组件,对 broker 进行健康检查提供快速切换能力。其中nginx 的 hotdoc 在开源 RocketMQ 底下是个 jmenv,你你这个 块直接使用。

对于业务开发关心的监控,朋友修改客户端,把耗时,异常等数据采用系统消息辦法 上报,由 Monitor 组件消费消息并写入 ES,并提供控制台查询能力。同時 客户端上报的数据,Alarm 也会消费一份,根据业务配置的监控项检查告警,超出阀值直接发出告警。另外消息系统也会再次出现 宕机,宕机选主可不上能 一段时间(秒级),虽然客户端有重试能力,其他其他场景可不上能了很好满足。其他,消息队列提供了降级组件,在系统异常时,客户端会将消息发送本地其他发送到容灾集群,降低系统宕机时对业务的影响。

对于运维比较关心的系统巡检,朋友提供系统巡检能力,将系统比较关键的具体情况定时巡检,异常则快速发出告警。对于运维比较关心的整体大盘,朋友在 Monitor 组件中加入系统数据分发,将数据写入 Influxdb,提供以 Grafana 为前端的 dashboard。另外朋友也提供控制台资源管控能力,将 Topic,ProducerGroup,ConsumerGroup,以及上下游应用关联并管控起来。

各组件交互流程如下: 

  • NameServer 提供 topic 路由信息发现,配置中心能力;
  • Broker 提供 topic 消息存储,索引,查询。同時 Broker 自身提供 HA 都要的基因重组,角色修改,探活,具体情况获取等 API。同時 – Broker 定时向所有Nameserver 注册;
  • Nginx 提供发现 NameServer 能力,由运维将 nameserver 列表填写到hotdoc 中。处理 NameServer 变更业务重新配置上线;
  • 降级组件提供消息发送失败的处理,在消息发送失败的具体情况下 client 会将消息发送到容灾集群,由降级组件统一处理保证发送方业务的稳定性;
  • Failover 组件检查 Broker 具体情况,Broker 宕机根据 QOS 要求切主;
  • Console 提供资源管控,消息查询,轨迹跟踪,监控报表,监控告警配置,死信重投等能力;
  • 巡检组件巡检消息队列自身集群所有组件健康与服务具体情况,有异常提前通知运维和消息队列相关人员;
  • 监控组件提供监控报表数据分发处理,消息队列大盘数据分发处理;
  • 告警组件主要分发告警信息,根据控制台配置的告警阀值和人员信息通知相应业务方;
  • 消息队列大盘提供消息队列集群自身的监控具体情况,主备基因重组具体情况,QPS等集群大盘报表展示。

每项高级社会形态介绍

这每项是云音乐根据其他人业务的需求,对开源的修改和扩充。朋友对开源 RocketMQ 的改动较多,其他篇幅的关系,这里仅介绍这多少社会形态,如 HTTP 协议实现和秒级延迟,高可用等这里不做介绍,有兴趣的同学可不上能交流。

消息轨迹

你你这个 社会形态和开源4.4中提供的消息轨迹实现机制一样。和开源不同的是,云音乐消息队列提供发送消费、事物消息回查轨迹,同時 消费失败时,也在轨迹中提供失败异常信息,另一一还还有一个就不能追踪失败意味着着。

事务消息



云音乐在做事务消息时,开源事务消息还没出来。云音乐通过修改存储引擎实现其他人的事物消息。提供事务消息回查按时间收敛能力,回查可不上能了具体情况超过次数进入死信,同時 提供死信告警,事务消息回查死信处理能力。

多环境隔离

云音乐有所以 条业务线,每条业务线可不上能 所以 个需求在做,同時 各个业务线之间的访问可不上能 通过服务化的辦法 进行。为提升开发和测试波特率,通过对 RPC 流量打标,的辦法 将流量隔离到相应环境,并一路透传下去。消息也一样,同一一还还有一个需求发送的消息都要相应的环境开发,测试,和其他互不影响。其他云音乐设计实现了消息队列的隔离,加快业务开发测试,预发快速验证能力。 

消费多程序运行 池自定义支持



开源 RocketMQ 消费端仅有一一还还有一个消费多程序运行 池,多个 topic 的消费会互相影响。另外同一一还还有一个消费端仅有一一还还有一个 listener,其他是多个 topic,都要上层业务分发。云音乐同一一还还有一个应用可不上能 有多个 topic 消费,有的多达 50+个。其他优先级高的 topic 都要自定义其他人的消费多程序运行 池,优先级低的使用公共的。另外 每个 topic 也要有其他人的 listener,另一一还还有一个就不需要上层分发。基于上述要求,朋友增加订阅可不上能同時 指定 listener 和 consumeThreadExecutor 的辦法 。

消费限流与降级

开源 RocketMQ 并这么 提供消费限流能力,基于 Sentinel 的是 pull 模式,而可不上能 push 模式,可不上能了很好满足云音乐的业务需求。

云音乐的消息消费不少可不上能 写数据库其他访问第三方,什么消费和在线业务可不上能 同一一还还有一个应用,消息队列自身虽然具备削峰填谷的能力,其他消费端会最大化使用消费多程序运行 池,这会对在线业务也产生影响。为保证在线业务优先,都要限制消费的波特率,减少瞬时高峰消息消费对在线业务的影响。

这每项可不上能通过调整消费多程序运行 池和消费 qps 来调整。朋友选着了调整消费 qps消费限流的辦法 ,另一一还还有一个能和监控数据对起来并提供控制台动态调整能力,消费多程序运行 池调整虽然朋友也提供动态调整多程序运行 池能力其他并可不上能 线性的,调整起来这么 参考,比较困难。消费限流做在了底层而可不上能 让应用层其他人做,和上层的区别时,上层限流了会触发消息消费一次其他失败,底层不需要失败本来算消费一次,其他还没投递上层业务。

多机房网络 bug 修复



云音乐有每项业务部署在建德,都要消费杭州的数据。这每项消费的机器老是隔三差五报 timeout。经过排查,发现 client 新建的连接老是在关闭创建循环,非常不稳定,这每项排查 remoting 层的代码发现 client 建立连接指在并发什么的问提,会将建立好的链接关闭。定位待开源 client 的 remoting bug 后,朋友进行了修复。

另外可不上能 几天,曲库的业务同学也报发送 3s 超时,经过仔细排查,发现异常日志和连接建立日志和网络建立并发什么的问提的日志一致,协同业务升级到最新修复的客户端处理。业务升级上线后如上所示,发送非常平稳,不再超时。

其他

作为开源的受益者,每项改动朋友会提交到 Apache RocketMQ 官方,如消费限流,消费多程序运行 池,网络 bug 修复等。

消息队列在云音乐的使用具体情况



截止目前为止,基于 RocketMQ 改造实现的消息队列在网易云音乐生产环境其他有 6 个集群。涉及顺序消息,普通消息,多种高可用高可靠要求。

接入应用 数量50+,每条业务线核心业务可不上能 涉及。峰值 QPS 已达 50w+,topic 50+。在测试环境单个集群,其他环境所以 ,Topic 数量也疯长,单个达到 500+,未来随着 kafka迁移的更多,Topic 数量可不上能 不断上涨。

从 2018 年 11 月刚开始了了英文,云音乐 kafka 禁止在线业务接入,新的删改使用 RocketMQ,另外 2019 Q1 刚开始了了英文组织协调业务将在线业务可不上能 使用 Kafka 的迁移到 RocketMQ,截止目前,其他迁移 70%+,业务整体稳定性得到极大提升。

随着业务接入 RocketMQ 的增多,本来断催生下游大数据生态的接入和使用。云音乐大数据主要使用 flink,目前 flink 在运行 job 50+,其中 RocketMQ 消息量 每天达8亿+,你你这个 块未来还有不少增长空间。

未来规划与展望

目前云音乐消息队列的社会形态其他所以 ,其他不能很好的满足业务的需求。从核心歌单、曲库业务到 QPS 很高的 push 业务,但在日志方面还未涉及。

涉及到日志传输开源 RocketMQ 有每项性能什么的问提,都要做优化,目前朋友其他完成这每项优化,其他优先级的关系,还没推广到日志传输相关应用。朋友期望云音乐的消息队列不能拓展到日志方面,将消息队列具备的完善监控告警等能力赋能到大数据,NDC 订阅(数据库更新订阅服务)。同時 增加路由能力减少多机房间跨机房访问。

另外,消息队列 RocketMQ 在整个网易除云音乐外并这么 其他大产品在使用,未来朋友会联合杭研,将消息队列推广到其他大产品线,将云音乐对消息队列的改进和社会形态普惠到其他大产品。

本文作者: 林德智,网易云音乐消息队列负责人,具有多年分布式消息系统等底下件分发及研发经验,对分布式系统有较深刻的理解。目前负责云音乐消息队列及云音乐每项稳定性性能相关工作。

原文链接

本文为云栖社区原创内容,未经允许不得转载。

本文由

吐泡泡ooO

发布在

ITPUB

,转载此文请保持文章删改性,并请附上文章来源(ITPUB)及本页链接。

原文链接:http://www.itpub.net/2019/08/06/2659/