新闻类的网站如何做优化、,厦门服装企业网站推广,网站顶部展出的大幅广告,wordpress 有道智云十年文案老司机#xff0c;不如网易评论区。
网易云音乐自2013年上线后#xff0c;业务保持了高速增长。云音乐除了提供好听的音乐外#xff0c;还留下了我们在乐和人上的美好回忆。本文整理自网易云音乐消息队列负责人林德智在近期 Apache FlinkRocketMQ Meetup 上海…
十年文案老司机不如网易评论区。
网易云音乐自2013年上线后业务保持了高速增长。云音乐除了提供好听的音乐外还留下了我们在乐和人上的美好回忆。本文整理自网易云音乐消息队列负责人林德智在近期 Apache FlinkRocketMQ Meetup 上海站的分享通过该文您将了解到
网易云音乐消息队列改造背景网易云音乐业务对消息队列要求网易云音乐消息队列架构设计网易云音乐消息队列部分高级特性介绍网易云音乐消息队列落地使用情况网易云音乐消息队列未公开规划
背景
网易云音乐从13年4月上线以来业务和用户突飞猛进。后台技术也从传统的 Tomcat 集群到分布式微服务快速演进和迭代在业务的不断催生下诞生了云音乐的 RPCAPI 网关和链路跟踪等多种服务消息队列也从 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
经过 RabbitMQKafka 和 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。另外我们也提供控制台资源管控能力将 TopicProducerGroupConsumerGroup以及上下游应用关联并管控起来。
各组件交互流程如下 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 已达 30wtopic 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 在整个网易除云音乐外并没有其他大产品在使用未来我们会联合杭研将消息队列推广到其他大产品线将云音乐对消息队列的改进和特性普惠到其他大产品。
原文链接 本文为云栖社区原创内容未经允许不得转载。
