网易云音乐的消息队列改造之路
极客时间编辑部
讲述：丁婵大小：2.44M时长：05:19
网易云音乐自 2013 年上线后，业务保持了高速增长。日前，网易云音乐消息队列负责人林德智在 Apache Flink&RocketMQ Meetup 上海站分享了网易云音乐的消息队列改造实践，以下为重点内容。
网易云音乐从 13 年 4 月上线以来，业务和用户突飞猛进。 后台技术也从传统的 Tomcat 集群到分布式微服务快速演进和迭代，在业务的不断催生下，诞生了云音乐的 RPC，API 网关和链路跟踪等多种服务，消息队列也从 RabbitMQ 集群迁移到 Kafka 集群。对于消息队列，更多处于使用阶段，也在使用中出现很多问题。因此我们期望提供一种完全可控，出现问题我们自己能排查，能跟踪，可以根据业务需求做定制改造的消息队列。
经过 RabbitMQ，Kafka 和 RocketMQ（ ActiveMQ 性能较差，暂不考虑）的调研和分析后，我们发现 RocketMQ 比较适合云音乐的通用业务，但是开源 RocketMQ 也有一些缺陷，比如 Broker 仅提供了 Master 到 Slave 的复制，没有 Failover 切换的能力。而且当时事物消息不开源、消息发送消费无追踪、没有告警与监控体系等等，只有我们解决了这些缺陷才能在业务中大规模使用。
我们期望消息队列具备宕机 Failover 能力，根据不同业务场景提供不同 QOS 能力，如商城消息不能丢失、交易事物消息支持、消息发送消费追踪、失败排查等能力。
同时对业务比较关心的发送耗时，消费耗时，消费延迟，消费失败异常等提供监控和告警能力。同时对运维比较关心的整体运行水位和各项指标提供监控大盘，以及排查发现消息队列自身问题与长期运维能力。
另外云音乐少部分业务是 Nodejs 和 Python 的，我们提供 HTTP 协议接入能力。
所以，最终以开源 RocketMQ 为内核，完全继承开源 RocketMQ 具备的特性。为满足高可用，我们增加了 Failover 组件，对 Broker 进行健康检查提供快速切换能力。
对于业务开发关心的监控，我们修改客户端，把耗时，异常等数据采用系统消息方式上报，由 Monitor 组件消费消息并写入 ES，并提供控制台查询能力。同时客户端上报的数据，Alarm 也会消费一份，根据业务配置的监控项检查告警，超出阀值直接发出告警。另外消息系统也会出现宕机，宕机选主也有一段时间（秒级），虽然客户端有重试能力，但是有些场景不能很好满足。因此，消息队列提供了降级组件，在系统异常时，客户端会将消息发送本地或者发送到容灾集群，降低系统宕机时对业务的影响。
在运维方面，我们提供系统巡检能力，将系统比较关键的状态定时巡检，异常则快速发出告警。我们也提供控制台资源管控能力，将 Topic，ProducerGroup，ConsumerGroup，以及上下游应用关联并管控起来。
另外，由于云音乐根据自己业务的需求，对开源 RocketMQ 的改动较多，林德智也介绍了几个特性，如消息轨迹、事务消息、多环境隔离。
消息轨迹和开源不同的是，云音乐消息队列提供发送消费、事物消息回查轨迹，同时消费失败时，也在轨迹中提供失败异常信息，这样就能够追踪失败原因。
云音乐在做事务消息时，开源事务消息还没出来。云音乐通过修改存储引擎实现自己的事物消息。提供事务消息回查按时间收敛能力，回查不到状态超过次数进入死信，同时提供死信告警，事务消息回查死信处理能力。
对于多环境隔离，云音乐有很多条业务线，每条业务线都有很多个需求在做，同时各个业务线之间的访问都是通过服务化的方式进行。为提升开发和测试效率，通过对 RPC 流量打标的方式将流量隔离到相应环境，并一路透传下去。消息也一样，同一个需求发送的消息需要相应的环境开发、测试和其他互不影响。因此云音乐设计实现了消息队列的隔离，加快业务开发测试，预发快速验证能力。
最后，林德智表示，作为开源的受益者，他们会将部分改动提交到 Apache RocketMQ 官方，以供更多人参考。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
Okay前面说从rabbit 迁移到kafka，但后面一直说rocket定制，好像没啥关联2
渔村蓝消息队列怎么隔离的
悟空WuKong阅
收起评论