简介：近年来，消息领域的全面云原生化逐渐深入，如RocketMQ5.0版本的存储计算分离设计和raft模式，和卡夫卡3。0引入了分层存储和raft模式，近年新兴的Pulsar也开始采用云原生架构。未来可以根据具体业务需求引入功能迭代，实现组件价值最大化。作者：张奕豪｜小红书消息中间件负责人一、消息队列业务场景及挑战1、总体规模RocketMQ和Kafka的总体规模如下图所示。其中8000w/s的TPS峰值一般出现在晚上下班后，写入量达到50GB/s，每天新增2-3PB数据，节点数1200+。2、业务架构RocketMQ和Kafka虽然在性能上差不多，但是在使用场景上还是有区别的。RocketMQ丰富的业务特性更适合在线业务场景，而Kafka的高吞吐量使其更倾向于线下和近线业务。当然在实际应用中会有交叉使用。有时候线上业务也会使用Kafka进行解耦，一些流处理数据也会使用RocketMQ进行存储。整体业务架构如下图所示。业务日志和APP用户行为管理内容会发送到Kafka，数据库增量日志、在线业务、在线数据交换等会发送到RocketMQ。Kafka和RocketMQ中的一部分数据会流入flink构建实时数仓、离线数仓和一些数据产品（如报表、监控等），RocketMQ中的另一部分数据将用于线上业务APP的异步解耦。消息队列业务架构三、稳定性挑战a．背景：小红书消息组件整体收敛较晚，公司技术架构最大目标是提高系统稳定性；b.挑战：现有消息组件使用量大，但不稳定，同时面临人手紧缺、时间紧迫、对MQ原理理解不深入的困境；C。策略：先做监控，增强集群的可观察性是了解其健康状态最有效的方式。4.稳定性治理除了监控告警，我们还在稳定性治理方面做了以下改进：引擎：资源隔离、新增监控管理等；b.平台：工单审核、权限控制、业务溯源；C。.治理：针对集群可视化能力和集群运维能力建设；二、消息队列治理实践1、集群可视化：监控指标下图是基于PrometheusGrafana的消息中间件架构。消息中间件监控系统架构图包含三个监控维度：硬件维度、服务维度和业务维度，共采集了150+个监控指标。那么如何定义这三个维度的监控指标呢？A。硬件维度：主要包括网络带宽、CPU使用率、磁盘容量/IO、TCP丢包/延迟等资源指标；b.服务维度：主要指运行状态指标，如：宕机监控、JVM指标、读写延迟、请求队列等；C。业务维度：面向用户的指标，也就是客户比较关心的指标，比如：消费延迟/积压、QPS、Topic吞吐量、Offset等；因为公司内部规定一个节点只能一个端口可以给Prometheus使用，但是大部分的监控指标都是单独收集的，所以设计了指标聚合服务MAS，把所有的指标汇集在一起??，同时，一些meta添加信息以帮助进一步解决问题。这里MAS相当于metric的一个代理层，可以根据业务实际情况添加。2.告警处理下图列出了监控系统刚建立时出现的一些告警信息。当时，每天大约有600-700条报警信息。告警问题也是五花八门，根本无法处理，导致监控系统无用。鉴于上述情况，我们提出监控的核心原则是不宜过度，不应淹没在警告的海洋中。警告太多和没有警告没有区别。基于这一原则，制定了一系列应对策略：前期：关闭低质量告警，确保每一个高质量告警都能及时发现和处理；中期：随着优质告警的减少逐步开放之前被屏蔽的告警，进一步处理逐步减少告警数量；后期：开启所有告警，保证每天的每条告警都能及时发现和处理。根据我们的经验，后期基本不会出现“服务不可用”这样的告警。大多数警报是早期警告。如果能及时介入预警，就可以确保在问题进一步扩大之前得到解决。告警处理分阶段策略3、集群可视化：RocketMQ服务的指标设计与优化，业务指标监控，基于开源RocketMQ-exporter改造，解决指标泄露、部分指标采集偏差等问题。这里有两个更重要的改进：卡顿监控优化问题1：consumermetricleakage，exporter运行几天可以达到300w+，curl一个接口耗时25s，日志文本600MB；原因：如下图所示，每连接一个新的客户端，端口值就会增加。由于exporter实现未能及时清除offlineclientindex值，导致client端口不断增加，系统告警。改造：为exporter添加metricexpire模块；结果：一个curl界面耗时减少到2s；问题2：滞后指标不准确，导致线上误报原因：export只提供group维度的rocketmq_group_diff，没有broker维度。需要额外计算；改造：给broker增加计算逻辑，先计算lag；结果：从下图可以看出，消息积压值已经从6K的抖动恢复到稳定值；b.分位数线/滑动窗口优化问题一：线上经常遇到brokerbusy的问题，需要监控出现的时间点。exporter虽然自带发送池等指标，但都是瞬时值，几乎没有参考意义；改造：添加指标计算经纪商5分钟内的最大值；结果：问题2：写消息耗时为历史最大值，参考效果有限；改造：优化耗时5分钟以内，分位数P99/P999；结果：获取准确的消息编写耗时。4、集群可视化：巡检系统巡检系统与监控系统的区别在于，监控系统响应的是瞬时变化快、需要及时发现和处理的问题，表现形式相对固定；检查系统是一个长期的工作监督，对于静态环境和配置，变化少，表现形式自由。随着治理的继续，您如何确认集群已达到健康状态？A。严格按照部署标准部署集群，包括硬件配置、运行参数、可用区等，对所有集群进行定期巡检，并生成报告反映集群状态；b.共制定20+项核心标准，检验结果以表格形式呈现，如下表所示。C。由于判断问题的指标太多，设置了集群健康子系统，基于集群的可用性只能由一个唯一的指标来反映的思想，并为每个指标设置一个权重，并且通过最后的分数来判断集群是否有问题，如下图所示：5.集群可视化：消息对账监控在设计告警的时候，总会有一些告警项没有考虑到。这里的解决方案是消息协调系统，它可以有效地监控消息延迟、丢失和集群健康状况。消息对账系统的优势在于提供端到端的监控，包括多种监控效果，其自驱动力可以覆盖未考虑的告警项，故障的发现和定位也是独立的.消息协调监控系统在Kafka社区提供了对应的KafkaMonitor组件。我们将这个组件转化为服务，提供自动添加新集群监控的能力，减轻运维压力。6、集群的运维：自动化平台的运维能力建设是通过自动化实现的，其根本目的是释放人力。下图是主题迁移工具，由RocketMQ和Kafka改造而成：RocketMQ修改nameserver删除逻辑，支持broker间主题自动迁移；它还处理消费者组、重试/dlq主题；依托自主研发的管理平台；b.Kafka基于reassign改造，自定义reassign算法，减少分区搬迁的影响；阶段工作流，每一步自动执行，下一步操作人工确认；综合自主开发的管理平台。话题迁移工具3.未来的探索与规划近年来，消息领域的全面云原生化逐渐深入，如RocketMQ5.0版本的存储计算分离设计和raft模式，以引入Kafka3.0为例分层的设计方式（tieredstorage）和raft模式，近几年新兴的Pulsar也开始采用云原生架构。未来可以根据具体业务需求引入功能迭代，实现组件价值最大化。原文链接本文为阿里云原创内容，未经许可不得转载。
