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

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

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

  • 网易云音乐消息队列改造背景
  • 网易云音乐业务对消息队列要求
  • 网易云音乐消息队列架构设计
  • 网易云音乐消息队列部分高级特性介绍
  • 网易云音乐消息队列落地使用情况
  • 网易云音乐消息队列未公开规划

背景

网易云音乐从13年4月上线以来,业务和用户突飞猛进。后台技术也从传统的 Tomcat 集群到分布式微服务快速演进和迭代,在业务的不断催生下,诞生了云音乐的 RPC,API 网关和链路跟踪等多种服务,消息队列也从 RabbitMQ 集群迁移到 Kafka集群。对于消息队列,更多处于使用阶段,也在使用中出现很多问题。因此我们期望提供一种完全可控,出现问题我们自己能排查,能跟踪,可以根据业务需求做定制改造的消息队列。

调研结果


RabbitMQ 由于持久化场景下的吞吐量只有2.6万,不能满足我们业务吞吐量的需求,云音乐在 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 消费,有的多达 30+个。因此优先级高的 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 个集群。涉及顺序消息,普通消息,多种高可用高可靠要求。

接入应用 数量200+,每条业务线核心业务都有涉及。峰值 QPS 已达 30w+,topic 800+。在测试环境单个集群,由于环境很多,Topic 数量也疯长,单个达到 4000+,未来随着 kafka迁移的更多,Topic 数量还会不断上涨。

从 2018 年 11 月开始,云音乐 kafka 禁止在线业务接入,新的全部使用 RocketMQ,另外 2019 Q1 开始组织协调业务将在线业务以前使用 Kafka 的迁移到 RocketMQ,截止目前,已经迁移 70%+,业务整体稳定性得到极大提升。

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

未来规划与展望

目前云音乐消息队列的特性已经很多,并且能够很好的满足业务的需求。从核心歌单、曲库业务到 QPS 很高的 push 业务,但在日志方面还未涉及。

涉及到日志传输开源 RocketMQ 有部分性能问题,需要做优化,目前我们已经完成这部分优化,由于优先级的关系,还没推广到日志传输相关应用。我们期望云音乐的消息队列能够拓展到日志方面,将消息队列具备的完善监控告警等能力赋能到大数据,NDC 订阅(数据库更新订阅服务)。同时增加路由能力减少多机房间跨机房访问。

另外,消息队列 RocketMQ 在整个网易除云音乐外并没有其他大产品在使用,未来我们会联合杭研,将消息队列推广到其他大产品线,将云音乐对消息队列的改进和特性普惠到其他大产品。

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

原文链接

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

Image placeholder
jjc
未设置
  17人点赞

没有讨论,发表一下自己的看法吧

推荐文章
网易云音乐热评的规律,44万条数据告诉你

本文转载自凹凸数读网易云的每日推荐里藏着你听过的歌,你听过的歌里藏着你的故事。网易云音乐的评论里,藏着许多人的故事。我们爬取了网易云音乐歌单中48400首歌的444054条热评,来看看网易云的热门评论

万亿级消息背后: 小米消息队列的实践

目录业务背景架构与关键问题性能与资源优化平台化效率小米消息中间件的规划与愿景前文《消息队列价值思考》讲述了消息中间件在企业IT架构中的重要价值,本文将呈现这些价值在落地小米业务过程中的遇到的问题和实践

有态度的网易(暴力裁员),难道这就是网易的“态度”?

我相信昨天大家都看了这篇文章《网易裁员,让保安把身患绝症的我赶出公司,我在网易亲身经历的噩梦》在微信、知乎、微博以及各大平台都已经刷屏了。原因只有一个:这个员工真的被逼的太惨了。先给大家简单分析一下整

扩展 Laravel 的消息通知系统(支持多语言和内容更改)

LaravelNotification在5.3版本中被添加作为核心框架的扩展。它为我们提供了一种简单易懂,表现力强的API去发送通知,包括各种预置发送渠道还有Laravel社区提供的各种自定义渠道。

分享一款支持多种短信服务商 Hyperf 组件,基于 overtrue/easy-sms 组件改造

一款支持多种短信服务商Hyperf组件1.新增配置文件phpbin/hyperf.phpvendor:publishhyperf-libraries/sms2.修改配置

从300万行到50万行代码,遗留系统的微服务改造

在传统企业甚至互联网企业中往往存在大量的遗留系统,这些遗留系统大多都能够正常工作,有的可能还运行着关键业务或者持有核心数据。但是,大部分遗留系统通常经常存在技术陈旧、代码复杂、难以修改等特点。笔者曾经

网易裁员事件,我给大家挖了这些法律知识,建议收藏!

网易裁员事件搞得沸沸扬扬的,这两天网易也对事件进行了回复,基本上可以确认事情属实,不了解事件经过的朋友可先看这篇文章:《有态度的网易(暴力裁员),难道这就是网易的“态度”?》。从这个事件中其实也暴露了

与聊天机器人相比,87%的消费者更喜欢与人类进行互动

最近对人工智能进展的调查、研究、预测和其他定量评估发现:·企业领导者表示,聊天机器人平均增加了67%的销售额·超过60%的美国人认为政府和企业每天收集他们的数据·到2020年,全球只有14%的大型组织

vue..js 编写的简单音乐播放器

闲暇之余写了一个音乐小应用项目目录代码开始index.html 每日推荐音乐 {{music.title}} {{music.author}} n

前端微服务在字节跳动的落地之路

不少前端团队都面临着独石应用的工程巨大、理解困难和合作混乱的种种问题,微前端或许是一种比较好的解决方案,它允许我们为应用加入新功能而不影响整体结构。但同时,我们可能会付出一些代价,例如重复依赖、团

41岁阿里工程师:35岁转管理,真的是必经之路吗?

程序员节,也恰恰是我在阿里工作满3年的时候,借此机会盘点一下自己近3年来的工作,也为自己后续发展把把关。个人的眼界和思考总是有限的,特别是对于研究和技术领域来说,知道得越多,其实就会知道自己有多无知,

用户从0到5亿,中国移动 OneLink 架构演进之路

导语本文根据范良泽老师在2019年10月31日【第十一届中国系统架构师大会(SACC)】现场演讲内容整理而成。范良泽(中移物联网有限公司系统架构专家)2008年毕业于上海交通大学,曾供职于华为、Ope

SACC 2019:云闪付APP架构优化实践之路

中国银联科技事业部架构师 程朝程朝2011年加入中国银联,拥有三年应用开发设计经验,三年MySQL与Redis内核开发设计经验,三年应用架构设计经验;擅长分布式系统设计,有丰富的系统设计与调优经验,现

看完知乎轮子哥的编程之路,我只想说,收下我的膝盖…

vczh,本名陈梓瀚,因知乎的个人信息介绍上写有“专业造轮子”,所以江湖人称“轮子哥”。vczh大学时代就在微软实习,毕业后即加入微软。开始时是在微软上海,后来进入北京的微软亚洲研究院。现已移居美国西

蚂蚁金服研究员玉伯回顾阿里十一年成长之路

注:这是在阿里内部前端大学的一个分享,整理了一份对外的版本,希望分享内容能对你有所帮助。 编者按:本文通过玉伯授权后发布今天跟大家分享下个人成长和带团队的一些感悟。我可能更偏向于写作型或阅读型,很少

对话蒋杰、丁奇,腾讯云数据库之路

此前,笔者曾经就腾讯云数据库战略升级一事写过一篇文章,对腾讯云数据库聚焦“云原生”“自治”“超融合”三大方向背后原因,以及怎样理解腾讯云数据库战略升级与五大新品、三大方向的关系进行了分析。近日,在腾讯

DBA职业发展之路:去“IOE”等挑战之下,DBA将何去何从?

开篇随着近些年来,开源、自动化、云化的兴起,DBA职业也正悄然发生一些变化。经常有朋友咨询我,职业发展规划;特别是近期Oracle的大幅裁员之后,针对DBA这一职业未来该如何发展?本文是个人对此问题的

TF中文社区之下,国内云网络的开源之路

北国的冬,似乎比想象中要来得晚一些。立冬前夕,阳光还未褪去金秋的温婉,碧云黄叶,书香意气,充盈在山东大学(青岛校区)的校园里。迎着温暖的阳,和煦的风,中国开源云网络的种子在这里生根发芽——Tungst

中国联通容器化之路及选型标准

“容器”的概念灵感来源于集装箱,有了集装箱,货物不会杂乱无章地堆放在一起,易于管理,也方便运输。容器技术也被称为轻量化虚拟化技术,与集装箱的作用相似。相比前网红虚拟机,容器技术凭借其轻量化、快速部署以

从网络接入层到 Service Mesh,蚂蚁金服网络代理的演进之路

本文作者:肖涵(涵畅)上篇文章《 诗和远方:蚂蚁金服ServiceMesh深度实践|QCon实录》中, 介绍了ServiceMesh在蚂蚁金服的落地情况和即将来临的双十一大考,帮助大家了解Servic

PingCAP马晓宇:TiDB的HTAP之路

HTAP是目前数据库领域比较热门的一个概念,它既能支持OLTP(在线事务处理),又能支持OLAP(在线分析处理),可以涵盖大部分企业级应用的需求,一站式解决他们的问题。本次,小编有幸采访到PingCA

OceanBase数据库创始人阳振坤分享征战6088万tpmC的艰辛之路

前言:中国人民大学常被誉为是“中国人文社会科学的最高学府”,其实人民大学也是“中国数据库的发源地”。由中国人民大学教授萨师煊与王珊合作编写的《数据库系统概论》是国内第一部系统阐明数据库原理、技术和理论

国产自研数据库DM8发布 看冯裕才的四十年“达梦”之路

5月8日下午,借助第十届中国数据库技术大会(DTCC2019),国内知名数据库管理系统和大数据平台软件及解决方案提供商、武汉达梦数据库有限公司(以下简称“达梦”)发布了新一代数据库产品–DM8。这一天

日志易陈军:创业之路本身就是试出来的

这是一个典型的行业老炮创业之旅,是老兵的再次出发。日志易创始人&CEO陈军陈军,这位70后创业者。90年代到现在,从思科到谷歌,然后回国加入腾讯、高德,做的工作一直都与日志相关,20多年的行业经验给了

两年Flink迁移之路:从standalone到on yarn,处理能力提升五倍

一、背景与痛点在2017年上半年以前,TalkingData的AppAnalytics和GameAnalytics两个产品,流式框架使用的是自研的td-etl-framework。该框架降低了开发流式