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

后台技术也从传统的 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 流量打标的方式将流量隔离到相应环境，并一路透传下去。消息也一样，同一个需求发送的消息需要相应的环境开发、测试和其他互不影响。因此云音乐设计实现了消息队列的隔离，加快业务开发测试，预发快速验证能力。