跳到主要内容

小红书消息中间件的运维实践与治理之路

· 6 分钟阅读

1. 消息队列业务场景与挑战

1.1 整体规模

下图展示了 RocketMQ 和 Kafka 的总体规模。其中峰值 TPS 的 8000w/s 一般出现在晚上下班以后的时间段,写入量达到50GB/s,每天新增2-3PB数据,节点数1200+个。

Example banner;

1.2 业务架构

虽然 RocketMQ 和 Kafka 的性能相似,但在使用场景上还是有所区别的。RocketMQ 丰富的业务特性更适用于在线业务场景,而 Kafka 的高吞吐性使其更偏向离线、近线业务。当然,在实际应用中也会有交叉使用的现象,有时在线业务也会使用 Kafka 解耦,有的流处理数据也会使用 RocketMQ 存储。

业务总体架构如下图所示,业务日志和APP用户行为打点类的内容会发给 Kafka,数据库增量日志、在线业务、线上数据交换等会发给 RocketMQ。Kafka 和 RocketMQ 中的数据会有一部分流入 flink 中构建实时数仓、离线数仓以及一些数据产品(如报表、监控,等),RocketMQ 中另一部分数据会用于在线业务APP异步解耦。

Example banner;

1.3 稳定性挑战

a. 背景: 小红书整体收敛消息组件较晚,公司技术架构最大的目标是提升系统稳定性;

b. 挑战: 现存消息组件使用量极大,但没有稳定性保障;同时面临人手紧缺、时间紧,对MQ原理了解不深入的困境;

c. 策略: 先做监控,增强集群的可观测能力是了解其健康状况的最高效手段。

1.4 稳定性治理

除了监控告警,我们在稳定性治理方面还做了以下改造工作:

  1. 引擎:资源隔离,新增监控打点等;
  2. 平台:工单审核,权限管控,业务追溯;
  3. 治理:针对集群可视化能力和集群可运维能力的建设;
Example banner;

2. 消息队列治理实践

2.1、集群可视化:监控metrics

下图是基于 Prometheus Grafana 构建的消息中间件体系架构。

Example banner;

图中包含三个监控维度:硬件维度、服务维度和业务维度,累计收集监控指标150+项。

那么如何定义这三个维度的监控指标呢?

  1. 硬件维度:主要包括网络带宽、CPU使用率、磁盘容量/IO、TCP丢包/延迟等资源指标;

  2. 服务维度:主要指运行状况的指标,如:宕机监控、JVM指标、读写时延、请求队列等;

  3. 业务维度:即面向用户的指标,这是客户比较关心的指标,如:消费延迟/积压、QPS、Topic吞吐量、Offset等;

由于公司内部规定一个节点只能使用一个端口给Prometheus,而各项监控指标大多是分开收集,于是设计了指标聚合服务 MAS 将所有指标汇集在一起,同时又增加了一些元信息帮助进一步排查问题。这里 MAS 相当于metric 的一个代理层,可以根据业务的实际情况来添加。

2.2 告警处理

下图列举了一些发生在监控体系刚建立时候的告警信息,当时每天的告警信息约有600-700条之多,告警的问题也是各式各样,根本无法处理,造成监控系统形同虚设。

Example banner;

鉴于以上情况,我们提出监控的核心原则要宁缺毋滥,不要淹没在告警海中,告警太多和没有告警没什么区别。根据这一原则制定了一系列应对策略:

初期:关闭低优告警,以确保每一条高优告警能得到及时发现和处理;

中期:随着高优告警的减少,逐步打开之前屏蔽的告警,进一步处理,实现告警数量逐步减少;

后期:打开全部告警,确保日常告警每一条都能及时发现和处理。

根据我们的经验,到后期基本不会有“服务不可用”这类的告警,大部分告警属于预警,如果预警能及时介入处理,就可以确保在问题进一步扩大之前解决。