简介： 随着公司业务的一直倒退，流量也在一直增长。咱们发现生产中的一些重大事故，往往是被突发的流量冲跨的，对流量的治理和防护，保障系统高可用就尤为重要。
作者|梁勇
背景
哈啰已进化为包含两轮出行（哈啰单车、哈啰助力车、哈啰电动车、小哈换电）、四轮出行（哈啰逆风车、全网叫车、哈啰打车）等的综合化挪动出行平台，并向酒店、到店团购等泛滥本地生活化生态摸索。
随着公司业务的一直倒退，流量也在一直增长。咱们发现生产中的一些重大事故，往往是被突发的流量冲跨的，对流量的治理和防护，保障系统高可用就尤为重要。
本文就哈啰在音讯流量和微服务调用的治理中踩过的坑、积攒的教训进行分享。
作者介绍
梁勇 (老梁)，《RocketMQ 实战与进阶》专栏联结作者、参加了《RocketMQ 技术底细》审稿工作。ArchSummit 寰球架构师大会讲师、QCon 案例研习社讲师。
以后次要在后端中间件方向，在公众号【瓜农老梁】已陆续发表百余篇源码实战类文章，涵盖 RocketMQ 系列、Kafka 系列、GRPC 系列、Nacosl 系列、Sentinel 系列、Java NIO 系列。目前就任于哈啰出行，任职高级技术专家。
聊聊治理这件事
开始之前先聊聊治理这件事件，上面是老梁集体了解：
治理在干一件什么事？
- 让咱们的环境变得美妙一些
须要晓得哪些地方还不够好？
- 以往教训
- 用户反馈
- 业内比照
还须要晓得是不是始终都是好的？
- 监控跟踪
- 告警告诉
不好的时候如何再让其变好？
- 治理措施
- 应急计划
目录
- 打造分布式音讯治理平台
- RocketMQ 实战踩坑和解决
- 打造微服务高可用治理平台
背景
裸奔的 RabbitMQ
公司之前应用 RabbitMQ，上面在应用 RabbitMQ 时的痛点，其中很多事变因为 RabbitMQ 集群限流引起的。
- 积压过多是清理还是不清理？这是个问题，我再想想。
- 积压过多触发集群流控？那是真的影响业务了。
- 想生产前两天的数据？请您重发一遍吧。
- 要统计哪些服务接入了？您要多等等了，我得去捞 IP 看看。
- 有没有应用危险比方大音讯？这个我猜猜。
裸奔的服务
已经有这么一个故障，多个业务共用一个数据库。在一次晚顶峰流量陡增，把数据库打挂了。
- 数据库单机降级到最高配仍然无奈解决
- 重启后缓一缓，不一会就又被打挂了
- 如此循环着、煎熬着、默默期待着顶峰过来
思考：无论音讯还是服务都须要欠缺的治理措施
打造分布式音讯治理平台
设计指南
哪些是咱们的要害指标，哪些是咱们的主要指标，这是音讯治理的首要问题。
设计指标
旨在屏蔽底层各个中间件（RocketMQ / Kafka）的复杂性，通过惟一标识动静路由音讯。同时打造集资源管控、检索、监控、告警、巡检、容灾、可视化运维等一体化的音讯治理平台，保障消息中间件安稳衰弱运行。
音讯治理平台设计须要思考的点
- 提供简略易用 API
- 有哪些关键点能掂量客户端的应用没有安全隐患
- 有哪些要害指标能掂量集群衰弱不衰弱
- 有哪些罕用的用户 / 运维操作将其可视化
- 有哪些措施应答这些不衰弱
尽可能简略易用
设计指南
把简单的问题搞简略，那是能耐。
极简对立 API
提供对立的 SDK 封装了（Kafka / RocketMQ）两种消息中间件。
一次申请
主题生产组主动创立不适宜生产环境，主动创立会导致失控，不利于整个生命周期治理和集群稳固。须要对申请流程进行管制，然而应尽可能简略。例如：一次申请各个环境均失效、生成关联告警规定等。
客户端治理
设计指南
监控客户端应用是否标准，找到适合的措施治理
场景回放
场景一 刹时流量与集群的流控
假如当初集群 Tps 有 1 万，刹时翻到 2 万甚至更多，这种适度陡增的流量极有可能引发集群流控。针对这类场景需监控客户端的发送速度，在满足速度和陡增幅度阈值后将发送变的平缓一些。
场景二 大音讯与集群抖动
当客户端发送大音讯时，例如：发送几百 KB 甚至几兆的音讯，可能造成 IO 工夫过长与集群抖动。针对这类场景治理需监控发送音讯的大小，咱们采取通过预先巡检的形式辨认出大音讯的服务，推动应用同学压缩或重构，音讯管制在 10KB 以内。
场景三 过低客户端版本
随着性能的迭代 SDK 的版本也会降级，变更除了性能外还有可能引入危险。当应用过低的版本时一个是性能不能失去反对，另外一个是也可能存在安全隐患。为理解 SDK 应用状况，能够采取将 SDK 版本上报，通过巡检的形式推动应用同学降级。
场景四 生产流量摘除和复原
生产流量摘除和复原通常有以下应用场景，第一个是公布利用时须要先摘流量，另外一个是问题定位时心愿先把流量摘除掉再去排查。为了反对这种场景，须要在客户端监听摘除 / 复原事件，将生产暂停和复原。
场景五 发送 / 生产耗时检测
发送 / 生产一条音讯用了多久，通过监控耗时状况，巡检摸排出性能过低的利用，针对性推动革新达到晋升性能的目标。
场景六 晋升排查定位效率
在排查问题时，往往须要检索发了什么音讯、存在哪里、什么时候生产的等音讯生命周期相干的内容。这部分能够通过 msgId 在音讯外部将生命周期串联起来。另外是通过在音讯头部埋入 rpcId / traceId 相似链路标识，在一次申请中将音讯串起来。
治理措施提炼
须要的监控信息
- 发送 / 生产速度
- 发送 / 生产耗时
- 音讯大小
- 节点信息
- 链路标识
- 版本信息
罕用治理措施
- 定期巡检：有了埋点信息能够通过巡检将有危险的利用找进去。例如发送 / 生产耗时大于 800 ms、音讯大小大于 10 KB、版本小于特定版本等。
- 发送平滑：例如检测到刹时流量满足 1 万而且陡增了 2 倍以上，能够通过预热的形式将刹时流量变的平滑一些。
- 生产限流：当第三方接口须要限流时，能够对生产的流量进行限流，这部分能够联合高可用框架实现。
- 生产摘除：通过监听摘除事件将生产客户端敞开和复原。
主题 / 生产组治理
设计指南
监控主题生产组资源应用状况
场景回放
场景一 生产积压对业务的影响
有些业务场景对生产沉积很敏感，有些业务对积压不敏感，只有前面追上来生产掉即可。例如单车开锁是秒级的事件，而信息汇总相干的批处理场景对积压不敏感。通过采集生产积压指标，对满足阈值的利用采取实时告警的形式告诉到利用负责的同学，让他们实时把握生产状况。
场景二 生产 / 发送速度的影响
发送 / 生产速度跌零告警？有些场景速度不能跌零，如果跌零意味着业务出现异常。通过采集速度指标，对满足阈值的利用实时告警。
场景三 生产节点掉线
生产节点掉线须要告诉给利用负责的同学，这类须要采集注册节点信息，当掉线时能实时触发告警告诉。
场景四 发送 / 生产不平衡
发送 / 生产的不平衡往往影响其性能。记得有一次征询时有同学将发送音讯的 key 设置成常量，默认依照 key 进行 hash 抉择分区，所有的音讯进入了一个分区里，这个性能是无论如何也上不来的。另外还要检测各个分区的生产积压状况，呈现适度不平衡时触发实时告警告诉。
治理措施提炼
须要的监控信息
- 发送 / 生产速度
- 发送分区详情
- 生产各分区积压
- 生产组积压
- 注册节点信息
罕用治理措施
- 实时告警：对生产积压、发送 / 生产速度、节点掉线、分区不平衡进行实时告警告诉。
- 晋升性能：对于有生产积压不能满足需要，能够通过减少拉取线程、生产线程、减少分区数量等措施加以晋升。
- 自助排查：提供多维度检索工具，例如通过工夫范畴、msgId 检索、链路零碎等多维度检索音讯生命周期。
集群衰弱治理
设计指南
度量集群衰弱的外围指标有哪些？
场景回放
场景一 集群衰弱检测
集群衰弱检测答复一个问题：这个集群是不是好的。通过检测集群节点数量、集群中每个节点心跳、集群写入 Tps 水位、集群生产 Tps 水位都是在解决这个问题。
场景二 集群的稳定性
集群流控往往体现出集群性能的有余，集群抖动也会引发客户端发送超时。通过采集集群中每个节点心跳耗时状况、集群写入 Tps 水位的变化率来把握集群是否稳固。
场景三 集群的高可用
高可用次要针对极其场景中导致某个可用区不可用、或者集群上某些主题和生产组异样须要有一些针对性的措施。例如：MQ 能够通过同城跨可用区主从穿插部署、动静将主题和生产组迁徙到灾备集群、多活等形式进行解决。
治理措施提炼
须要的监控信息
- 集群节点数量采集
- 集群节点心跳耗时
- 集群写入 Tps 的水位
- 集群生产 Tps 的水位
- 集群写入 Tps 的变化率
罕用治理措施
- 定期巡检：对集群 Tps 水位、硬件水位定期巡检。
- 容灾措施：同城跨可用区主从穿插部署、容灾动静迁徙到灾备集群、异地多活。
- 集群调优：零碎版本 / 参数、集群参数调优。
- 集群分类：按业务线分类、按外围 / 非核心服务分类。
最外围指标聚焦
如果说这些要害指标中哪一个最重要？我会抉择集群中每个节点的心跳检测，即：响应工夫（RT），上面看看影响 RT 可能哪些起因。
对于告警
- 监控指标大多是秒级探测
- 触发阈值的告警推送到公司对立告警零碎、实时告诉
- 巡检的危险告诉推送到公司巡检零碎、每周汇总告诉
音讯平台图示
架构图
看板图示
- 多维度：集群维度、利用维度
- 全聚合：要害指标全聚合
RocketMQ 实战中踩过的坑和解决方案
行动指南
咱们总会遇到坑，遇到就把它填了。
1. RocketMQ 集群 CPU 毛刺
问题形容
**
RocketMQ 从节点、主节点频繁 CPU 飙高，很显著的毛刺，很屡次从节点间接挂掉了。
只有系统日志有谬误提醒
2020-03-16T17:56:07.505715+08:00 VECS0xxxx kernel:[] ? \_\_alloc\_pages\_nodemask+0x7e1/0x9602020-03-16T17:56:07.505717+08:00 VECS0xxxx kernel: java: page allocation failure. order:0, mode:0x202020-03-16T17:56:07.505719+08:00 VECS0xxxx kernel: Pid: 12845, comm: java Not tainted 2.6.32-754.17.1.el6.x86\_64 #12020-03-16T17:56:07.505721+08:00 VECS0xxxx kernel: Call Trace:2020-03-16T17:56:07.505724+08:00 VECS0xxxx kernel:[] ? \_\_alloc\_pages\_nodemask+0x7e1/0x9602020-03-16T17:56:07.505726+08:00 VECS0xxxx kernel: [] ? dev\_queue\_xmit+0xd0/0x3602020-03-16T17:56:07.505729+08:00 VECS0xxxx kernel: [] ? ip\_finish\_output+0x192/0x3802020-03-16T17:56:07.505732+08:00 VECS0xxxx kernel: [] ?
各种调试零碎参数只能减缓然而不能根除，仍然毛刺超过 50%
解决方案
将集群所有系统升级从 centos 6 降级到 centos 7，内核版本也从从 2.6 降级到 3.10，CPU 毛刺隐没。
2. RocketMQ 集群线上提早音讯生效
问题形容
RocketMQ 社区版默认本反对 18 个提早级别，每个级别在设定的工夫都被会消费者精确生产到。为此也专门测试过生产的距离是不是精确，测试结果显示很精确。然而，如此精确的个性竟然出问题了，接到业务同学报告线上某个集群提早音讯生产不到，诡异！
解决方案
将 ” delayOffset.json “ 和 ” consumequeue / SCHEDULE\_TOPIC\_XXXX “ 移到其余目录，相当于删除；逐台重启 broker 节点。重启完结后，通过验证，提早音讯性能失常发送和生产。
打造微服务高可用治理平台
设计指南
哪些是咱们的外围服务，哪些是咱们的非核心服务，这是服务治理的首要问题
设计指标
服务能应答从天而降的陡增流量，尤其保障外围服务的安稳运行。
利用分级和分组部署
利用分级
依据用户和业务影响两个纬度来进行评估设定的，将利用分成了四个等级。
- 业务影响：利用故障时影响的业务范围
- 用户影响：利用故障时影响的用户数量
S1：外围产品，产生故障会引起内部用户无奈应用或造成较大资损，比方主营业务外围链路，如单车、助力车开关锁、逆风车的发单和接单核心链路，以及其外围链路强依赖的利用。
S2: 不间接影响交易，但关系到前台业务重要配置的治理与保护或业务后盾解决的性能。
S3: 服务故障对用户或外围产品逻辑影响十分小，且对次要业务没影响，或量较小的新业务；面向外部用户应用的重要工具，不间接影响业务，但相干治理性能对前台业务影响也较小。
S4: 面向外部用户应用，不间接影响业务，或后续须要推动下线的零碎。
分组部署
S1 服务是公司的外围服务，是重点保障的对象，需保障其不被非核心服务流量意外冲击。
- S1 服务分组部署，分为 Stable 和 Standalone 两套环境
- 非核心服务调用 S1 服务流量路由到 Standalone 环境
- S1 服务调用非核心服务需配置熔断策略
多种限流熔断能力建设
咱们建设的高可用平台能力
局部限流效果图
**
- 预热图示
- 排队期待
- 预热 + 排队
高可用平台图示
**
- 中间件全副接入
- 动静配置实时失效
- 每个资源和 IP 节点具体流量
总结
- 哪些是咱们的要害指标，哪些是咱们的主要指标，这是音讯治理的首要问题
- 哪些是咱们的外围服务，哪些是咱们的非核心服务，这是服务治理的首要问题
- 源码 & 实战 是一种比拟好的工作学习办法。
版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。