RocketMQHardened-Haro在分布式消息治理和微服务治理方面的实践是一个四轮出行（你好搭车、全网约车、你好打车）的综合移动出行平台，探索酒店、小区等众多本地生活生态店铺团购。随着公司业务的不断发展，流量也越来越大。我们发现，生产中的一些重大事故，往往是突如其来的交通冲昏了头脑。管理和保护流量并确保系统的高可用性尤为重要。本文分享Hello在消息流量和微服务调用治理上踩过的坑和积累的经验。让我们谈谈治理。在我们开始之前，让我们谈谈治理。以下是老梁的个人理解：治理是干什么的？什么不足以改善我们的环境？过往的经验、用户的反馈、行业对比，还是要知道是不是一直都不错？监控跟踪告警通知不好的情况下如何改进？治理措施应急预案目录创建分布式消息管理平台RocketMQ实战陷阱及解决方案创建微服务高可用管理平台后台跑来跑去的RabbitMQ公司之前用的是RabbitMQ。以下是使用RabbitMQ时的痛点，其中很多是由于RabbitMQ的集群限流造成的。积压的应清还是不清？这是一个问题，让我考虑一下。积压过多触发集群流控？这真的很影响生意。想消费前两天的数据？请重新发布。应该计算哪些服务？你再等一会儿，我得查IP。使用这样的大新闻有没有风险？我猜这是。裸奔服务曾经有过这样的失败，以至于多个商家共享一个数据库。在晚高峰流量激增期间，数据库被暂停。将数据库升级到最高配置还是不能解决问题。重启后过一会又挂了。如此循环，煎熬，默默等待高峰过去思考：无论是新闻还是服务，都需要完善的治理措施来创造分发哪些是我们的关键指标，哪些是我们的次要指标？这是信息管理的首要问题。设计目标是屏蔽底层中间件（RocketMQ/Kafka）的复杂性，通过唯一标识动态路由消息。同时，构建集资源管控、检索、监控、告警、巡检、容灾、可视化运维等为一体的综合消息管理平台，确保消息中间件平稳健康运行。消息治理平台设计需要考虑的点提供易用的API可以衡量客户端使用的关键点有哪些？没有安全风险。衡量集群健康的关键指标有哪些？有哪些常见的用户/运维操作可视化？这些不健康的简单好用的设计准则，把复杂的问题简单化了，就是能力。极简统一API，提供统一SDK封装（Kafka/RocketMQ）两种消息中间件。为一个应用自动创建主题消费组不适合生产环境，自动创建会导致失控，不利于全生命周期管理和集群稳定。申请过程需要可控，但要尽可能简单。例如：申请所有环境生效，生成关联告警规则等。客户端治理设计指南监控客户端是否规范使用，找到合适的措施管理播放场景。瞬时流量和集群流控假设当前集群Tps为10000，瞬间增加到20000以上。这种过分陡峭的增加流量极有可能触发集群流控。对于这类场景，需要对客户端的发送速度进行监控，在达到速度和陡增阈值后，让发送更加顺畅。场景二大消息和集群抖动当客户端发送大消息时，比如发送几百KB甚至几兆的消息，可能会造成IO时间过长和集群抖动。对于此类场景治理，需要对发送消息的大小进行监控。我们采用事后检查的方式识别大消息服务，推广使用同学压缩或重构，消息控制在10KB以内。场景三客户端版本太低，SDK版本也会随着迭代功能升级。除了功能之外，更改可能会引入风险。使用过低版本时，一是功能无法支持，二是可能存在安全隐患。为了解SDK的使用情况，您可以上报SDK版本，通过检测促进用户升级。场景4消费流量移除和恢复消费流量移除和恢复通常有以下使用场景。第一个是在发布应用的时候需要先去流量，另一个是在定位问题的时候需要先去流量再排查。为了支持这种场景，需要在客户端监听removal/resume事件，暂停和恢复消费。场景5发送/消费耗时检测发送/消费消息需要多长时间，通过监控耗时情况，巡查找出性能低下的应用，有针对性地推动改造，达到目的提高性能。场景六提高排查定位效率排查时，往往需要检索发送了什么消息、存储在何处、何时消费等消息生命周期相关的内容。这部分可用于通过msgId链接消息内部的生命周期。另外，通过在消息头中嵌入类似链接标识的rpcId/traceId，将消息串在一个请求中。治理措施细化所需监控信息发送/消费速度发送/消费耗时消息大小节点信息链接标识版本信息通用治理措施定期巡检：通过埋点信息，通过巡检发现风险应用。例如发送/消费时间大于800ms，消息大小大于10KB，版本小于特定版本等平滑发送：例如检测到瞬时流量达到10000，增加了2次以上，可以通过预热来平滑瞬时流量。消费限流：当第三方接口需要限流时，可以限制消费流量，这部分可以结合高可用框架实现。消费者移除：通过监听移除事件关闭和恢复消费者客户端。Topic/消费组治理设计指南监控Topic消费组资源使用场景回放场景一消费积压对业务的影响有些业务场景对消费积压敏感，有些业务对积压不敏感，只要追上来，后面消费即可.比如自行车解锁是秒级的事情，而信息聚合相关的批处理场景对积压不敏感。通过消费积压指标的采集，实时告警，通知负责学生达到阈值的应用，让他们实时掌握消费情况。场景二消费/发送速度受影响。发送/消费速度降为零报警？在某些场景下，速度无法降为零。如果降为零，说明业务异常。通过采集速度指标，对达到阈值的应用进行实时告警。场景三消费者节点离线。消费者节点下线需要通知负责申请的同学。此类信息需要采集注册节点信息，离线时可以实时触发告警通知。场景4发送/消费不平衡发送/消费不平衡往往会影响其性能。记得在一次咨询中，有同学将发送消息的密钥设置为常数。默认情况下，哈希选择分区是根据key进行的。所有消息都进入一个分区。这种性能无论如何也无法提高。此外，还需要检测各个分区的消费积压情况，在出现过度不平衡时触发实时告警通知。治理措施细化所需监控信息发送/消费速度发送分区详情各分区消费积压消费组积压注册节点信息通用治理措施实时告警：实时告警通知消费积压、发送/消费速度、节点断开、和分区不平衡。提升性能：如果有消费积压不能满足需求，可以通过增加拉取线程、消费线程、增加分区数等方式提升。自助排查：提供多维度的检索工具，如通过时间段多维度检索消息生命周期、msgId检索、链接体系等。集群健康治理设计指南衡量集群健康的核心指标有哪些？场景回放场景一集群健康检测集群健康检测回答一个问题：这个集群健康吗？通过检测集群节点数、集群各节点心跳、集群写Tps水位、集群消费Tps水位来解决这个问题。场景二集群稳定性集群流控往往反映集群性能不足，集群抖动也会导致客户端发送超时。通过采集集群中各节点的耗时心跳和集群写入的Tps水位变化率，可以掌握集群是否稳定。场景三集群高可用高可用主要是针对极端场景下某个可用区不可用，或者集群上某些topic和consumergroup出现异常。需要采取一些有针对性的措施。例如：MQ可以通过同城跨可用区的主从交叉部署、主题和消费组动态迁移到灾备集群、多活等方式来解决。治理措施细化集群节点数采集所需监控信息集群节点心跳耗时集群写入Tps水位集群消耗Tps水位集群写入Tps变化率常用治理措施定期巡检：定期巡检集群Tps水位和硬件水位检查。容灾措施：同城跨可用区主从交叉部署，动态迁移到容灾集群进行容灾，异地多活。集群调优：系统版本/参数、集群参数调优。集群分类：按业务线，按核心/非核心服务。关注最核心的指标这些关键指标中哪个最重要？我会选择集群中每个节点的心跳检测，即：响应时间（RT），我们看看RT有什么影响。大部分告警监控指标为秒级检测触发阈值告警推送到公司统一告警系统，巡检风险通知实时通知推送到公司巡检系统，每周汇总通知消息平台图架构图看板图多-dimensional：集群维度和应用维度全聚合：关键指标全聚合RocketMQ实战踩过的坑和解决动作指南1、RocketMQ集群CPU毛刺问题描述RocketMQ从节点和主节点频繁出现CPU高，毛刺明显，很多从节点直接挂掉。只有系统日志有错误信息2020-03-16T17:56:07.505715+08:00VECS0xxxxkernel:[]?__alloc_pages_nodemask+0x7e1/0x9602020-03-16T17:56:07.505717+08:00VECS0xxxx内核：java：页面失败.order：0，模式：0x202020-03-16T17：56：07.505719+08：00VECS0xxxx内核：Pid：12845,comm:javaNottainted2.6.32-754.17.1.el6.x86_64#12020-03-16T17:56:07.505721+08:00VECS0xxxxkernel:CallTrace:2020-03-16T17:56:07.505724+08:00VECS0xxxx内核：[]？__alloc_pages_nodemask+0x7e1/0x9602020-03-16T17:56:026:026:07.085？核心：[]？各种调试系统参数只能减缓不能根除，毛刺仍然超过50%。解决方法是将集群中的所有系统从centos6升级到centos7，内核版本也从2.6升级到3.10，CPU毛刺消失。二、RocketMQ集群在线延迟消息失败问题描述RocketMQ社区版默认支持18个延迟级别，每个级别在设定的时间被消费者精准消费。为此，我们还专门测试了消费区间是否准确，测试结果表明，非常准确。然而，如此精确的特征存在一个问题。接到业务同学反映，线上某个集群的延时消息无法消费，奇怪！解决方案将“delayOffset.json”和“consumequeue/SCHEDULE_TOPIC_XXXX”移动到其他目录，相当于删除；一个接一个地重启代理节点。重启后，已经验证了延迟消息功能正常发送和消费。构建微服务高可用治理平台的设计指南哪些是我们的核心服务，哪些是我们的非核心服务？应用分类分组部署应用分类根据用户和业务影响两个纬度进行评估设置，将应用分为四个等级。业务影响：应用故障影响的业务范围用户影响：应用故障影响的用户数量S1：核心产品，故障会导致外部用户无法使用或造成较大的资产损失，如主营业务，如单车、助力车开关锁、汽车下单和接单的核心环节，以及对核心环节强依赖的应用。S2：不直接影响交易，但与前台业务重要配置或业务后台处理功能的管理维护有关。S3：服务故障对用户或核心产品逻辑影响很小，对主业务或体量较小的新业务无影响；内部用户的重要工具，不直接影响业务，但相关管理功能对前端业务的影响也较小。S4：对于内部用户，不直接影响业务，或者以后需要下线的系统。群部署S1服务是公司的核心服务，是重点保护的对象，需要保护不受非核心服务流量的意外影响。S1服务组部署分为两套环境，Stable和Standalone。非核心服务调用S1服务流量路由到Standalone环境。S1服务调用非核心服务需要配置熔断策略。多重限流和熔断能力建设我司高可用平台容量部分受限流量效果图预热图排队等待预热+排队高可用平台图全接入中间件动态配置实时生效每个资源和IP节点详细流量汇总哪些是我们的关键指标，哪些是我们的次要指标，这是消息治理的首要问题。哪些是我们的核心服务，哪些是我们的非核心服务，这是服务治理的首要问题。源码&实战是一种更好的工作和学习方式。
