简介：近年来，音讯畛域的全面云原生化逐步走向深刻，比方 RocketMQ 5.0 版本的存算拆散设计和 raft 模式，再比方 Kafka3.0 引入了分层设计的形式（tiered storage）和 raft 模式，以及近年来新崛起的 Pulsar 也开始采纳云原生架构，在将来都能够针对具体业务需要引入进行性能迭代，施展组件的最大价值。
作者：张亿皓|小红书消息中间件负责人
一、音讯队列业务场景与挑战
1、整体规模
下图展现了 RocketMQ 和 Kafka 的总体规模。其中峰值 TPS 的 8000w/s 个别呈现在早晨上班当前的时间段，写入量达到 50GB/s，每天新增 2 -3PB 数据，节点数 1200+ 个。
2、业务架构
尽管 RocketMQ 和 Kafka 的性能类似，但在应用场景上还是有所区别的。RocketMQ 丰盛的业务个性更实用于在线业务场景，而 Kafka 的高吞吐性使其更偏差离线、近线业务。当然，在理论利用中也会有穿插应用的景象，有时在线业务也会应用 Kafka 解耦，有的流解决数据也会应用 RocketMQ 存储。
业务总体架构如下图所示，业务日志和 APP 用户行为打点类的内容会发给 Kafka，数据库增量日志、在线业务、线上数据交换等会发给 RocketMQ。Kafka 和 RocketMQ 中的数据会有一部分流入 flink 中构建实时数仓、离线数仓以及一些数据产品（如报表、监控，等），RocketMQ 中另一部分数据会用于在线业务 APP 异步解耦。
音讯队列业务架构
3、稳定性挑战
a. 背景：
小红书整体收敛音讯组件较晚，公司技术架构最大的指标是晋升零碎稳定性；
b. 挑战：
现存音讯组件使用量极大，但没有稳定性保障；同时面临人手紧缺、工夫紧，对 MQ 原理理解不深刻的窘境；
c. 策略：
先做监控，加强集群的可观测能力是理解其健康状况的最高效伎俩。
4、稳定性治理
除了监控告警，咱们在稳定性治理方面还做了以下革新工作：
a. 引擎：资源隔离，新增监控打点等；
b. 平台：工单审核，权限管控，业务追溯；
c. 治理：针对集群可视化能力和集群可运维能力的建设；
二、音讯队列治理实际
1、集群可视化：监控 metrics
下图是基于 Prometheus Grafana 构建的消息中间件体系架构。
消息中间件监控体系架构图
图中蕴含三个监控维度：硬件维度、服务维度和业务维度，累计收集监控指标 150+ 项。
那么如何定义这三个维度的监控指标呢？
a. 硬件维度：次要包含网络带宽、CPU 使用率、磁盘容量 /IO、TCP 丢包 / 提早等资源指标；
b. 服务维度：次要指运行状况的指标，如：宕机监控、JVM 指标、读写时延、申请队列等；
c. 业务维度：即面向用户的指标，这是客户比较关心的指标，如：生产提早 / 积压、QPS、Topic 吞吐量、Offset 等；
因为公司外部规定一个节点只能应用一个端口给 Prometheus，而各项监控指标大多是离开收集，于是设计了指标聚合服务 MAS 将所有指标会集在一起，同时又减少了一些元信息帮忙进一步排查问题。这里 MAS 相当于 metric 的一个代理层，能够依据业务的理论状况来增加。
2、告警解决
下图列举了一些产生在监控体系刚建设时候的告警信息，过后每天的告警信息约有 600-700 条之多，告警的问题也是各式各样，根本无法解决，造成监控零碎形同虚设。
鉴于以上状况，咱们提出监控的外围准则要宁缺毋滥，不要吞没在告警海中，告警太多和没有告警没什么区别。依据这一准则制订了一系列应答策略：
初期：敞开低优告警，以确保每一条高优告警能失去及时发现和解决；
中期：随着高优告警的缩小，逐渐关上之前屏蔽的告警，进一步解决，实现告警数量逐渐缩小；
前期：关上全副告警，确保日常告警每一条都能及时发现和解决。
依据咱们的教训，到前期根本不会有“服务不可用”这类的告警，大部分告警属于预警，如果预警能及时染指解决，就能够确保在问题进一步扩充之前解决。
告警解决阶段性策略
3、集群可视化：metric 设计与优化
RocketMQ 的服务、业务指标监控，基于开源 RocketMQ-exporter 进行革新，解决 metrics 透露、局部指标采集偏差等问题。
这里着重介绍两个比拟重要的革新：
a. lag 监控优化
问题一：consumer metric 泄露，exporter 运行几天指标量就可达到 300w+，curl 一次接口破费工夫 25s，log 文本有 600MB；
起因：如下图所示，每接入新的客户端，端口值就会减少，因为 exporter 实现中没能将离线客户端指标值及时清理造成客户端端口继续减少导致系统告警。
革新：在 exporter 中退出 metric expire 模块；
后果：curl 一次接口破费的工夫降到 2s；
问题二：lag 指标不准，造成线上误告警
起因：export 只提供 group 维度的 rocketmq_group_diff，没有 broker 维度的，要额定计算；
革新：在 broker 中退出计算逻辑，先将 lag 计算好；
后果：能够从下图中看到，音讯积压值从 6K 的抖动复原成安稳值；
b. 分位线 / 滑动窗优化
问题一：线上时常会遇到 broker busy 的问题，须要对产生的工夫点进行监控。尽管 exporter 自带 send pool 等指标，但为瞬时值，简直没有参考意义；
革新：在 broker 中退出计算 5 分钟内最大值的指标；
后果：
问题二：音讯写入耗时是历史最大值，参考作用无限；
革新：优化为 5 分钟内耗时，以及 P99/P999 等分位值；
后果：失去精确的音讯写入耗时。
4、集群可视化：巡检零碎
巡检零碎与监控零碎的区别是：监控零碎是反馈刹时的问题，变动很快，须要及时发现和解决，出现模式绝对固定；巡检零碎则是长期工作的监督，针对动态环境和配置，变动较少，出现模式更加自在。
随着治理工作的继续发展，如何确认一个集群达到衰弱状态？
a. 严格依照部署规范部署集群，包含硬件配置、运行参数、可用区等，对所有集群进行定期巡检，产出报表反映集群情况;
b. 共制订外围规范 20+ 项，巡检后果以表格模式出现，如下图表格。
c. 因为指标过多无奈从判断问题，因而设定了集群衰弱分体系，是基于集群的可用性只能通过惟一指标反映的思维，将每个指标设置一个权重，通过最终的分值来判断集群是否存在问题，如下图所示：
5、集群可视化：音讯对账监控
在设计告警时，总会有些没有思考到的告警项，这里的解决方案是音讯对账零碎，它能够无效监控音讯提早、失落和集群衰弱度。
音讯对账零碎的劣势在于它提供端对端的监控，包罗多项监控的成果，并且它的自驱力能够替没有思考到的告警项兜底，故障的发现和定位也被独立开。
音讯对账监控零碎
在 Kafka 社区提供了相应的 Kafka Monitor 组件，咱们将这个组件进行服务化革新，提供自动化增加新集群监控的能力，加重运维的压力。
6、集群可运维：自动化平台
可运维能力的建设是通过自动化来实现的，其基本目标是开释人力。
下图展现的是 topic 迁徙工具，从 RocketMQ 和 Kafka 两局部革新：
a. RocketMQ
批改 nameserver delete 逻辑，反对在 broker 间主动迁徙 topic；
同时解决 consumer-group，retry/dlq topic；
依赖自研治理平台；
b. Kafka
- 基于 reassign 革新，自定义 reassign 算法，缩小 partition 搬迁的影响；
- stage 工作流化，每一步主动执行，人工确认下一步操作；
- 集成自研治理平台。
Topic 迁徙工具
三、将来的摸索与布局
近年来，音讯畛域的全面云原生化逐步走向深刻，比方 RocketMQ 5.0 版本的存算拆散设计和 raft 模式，再比方 Kafka3.0 引入了分层设计的形式（tiered storage）和 raft 模式，以及近年来新崛起的 Pulsar 也开始采纳云原生架构，在将来都能够针对具体业务需要引入进行性能迭代，施展组件的最大价值。
原文链接
本文为阿里云原创内容，未经容许不得转载。