事故复原背景

野性酷女 2023-02-17 11:17 42阅读 0赞

### 文章目录 ###

*   *   *  大型活动亿级访问微服务平台雪崩本:
         *  调查
         *   *  接口不支持进行限流:
             *  数据库查询频率过高
             *  机器的CPU资源
             *  代码配置
             *  代码设计问题
         *  解决方案
         *   *  总结
         *  
         *   *  总结
         *  
     *

今天看了一下日期已经到20年的6月份,距离上次的生产事故已经过去了半个月了,各种复盘,总结,解决方案和代码优化也已经上生产了,在进行逐步验证中

### 大型活动亿级访问微服务平台雪崩本: ###

组织大型促销活动,我们的APP 是一个支付软件,活动的优惠力度比较大,

*  5折立减 没有门槛最高优惠20元
 *  活动上午8点开始
 *  区分 运营商用户(电信用户奖池最多, 移动/联通 用户多但是奖品池少)
 *  活动是5天,前4天是抢红包活动,最后一天是立减,出事的也就是最后一天

公司每年都会举行这种活动/年中一次年尾一次,所以特别重视, 公司的组织架构管理层除外:

参与活动部门有: 安全/运维/DBA/专项项目组/事业群/运营(活动)/运营(配置)/技术部门/客服/账号/理财/保险/消费金融/大数据/AI 所以能力也是可以的,而且这种活动也是举行了很多次,插个话题(以前也是举行了很多次,但是以前是 大部分部门都是进行降级服务的在活动高峰时期)

我负责的业务背景: App 的首页启动支撑,展示层数据 活动/大数据推荐/保险/理财数据/搜索/短视频/公益项目/尊贵的运营商plus会员用户数据 提供接口出去给前端的原生使用. 一共是拆了两个应用提供这些基本功能出去的一个模块基本包含了大部分所以部署的机器是25台,另外一个模块 20台机器,所有的配置都一样的,虚拟出的节点.

**爆点活动开始**

活动开始时间是上午8点,我们组我距离公司比较近,加上业务也是比较熟悉的有幸参与值班人员6.50已经到了公司领完早餐7点多一点,监控一切正常,我还在和其他组的哥们聊天/吹B,时间过得好快,一会就到了8点一到时间点 我的微信电话就响起了 配置运营组打来紧急电话生产环境配置平台挂了,所有页面都是脚本异常,这个平台就做配置,对数据库的CRUD 操作,如果出现问题,优先级是比较低的,但是生产很少出行问题的,所以就记录下来,问题点和时间,准备一会查看原因,突然日志 平台刷刷的异常,短信/电话/邮箱 都爆了,瞬间就慌了, 就像黑暗中被人打了一拳,但不知道在对手在哪里,只有查看日志错误原因是哪个接口挂了,这个时间点大家都来了差不多了,看到群里有反馈是网关层出现大量异常,调用各个模块超时,我缓了一口气,这和我们应该关系不大吧,然后满满排查bug,怎么有一些sql 的异常呢,而且都是数据库的连接超timeout 的异常. 顿时,老脑中出现了许多疑惑.

因为代码中有60%是我写的,所以我知道,这边这些接口都是一次查询 放到redis中,然后通过技术用户匹配的数据,这样做到千人千面的数据+大数据的数据 所以我对我们的数据库还是有信心的,应该是这会活动访问量大,一会就好了,时间就这样过去了,我继续查看异常信息,代码是没有出行逻辑bug,RPC也很少出行异常,这个时候告警还是没有降下去,自己尝试切换登录后发现登录模块也有问题了,我们共用的是同一个库

![img][]

// 数据库连接数过高是平时10倍

**AM:8:40**

拿出我自己准备的预案讲一些不不要的接口的开关进行关闭降级处理,看看是否有效果,刚进行关闭楼下的运维疯狂@我们 说数据库 连接数过高啊,是不是缓存被穿透了,怎么压力都到了数据库,心中慌的一逼.哎,群里大佬 纷纷跟随出主意,最终确定,轮询将一些节点进行重启,这样数据库链接有些阻塞的线程就死了,能保证数据库不会挂,同时 网关模块也表示压力太大了,需要进行紧急扩容,这会 屋逢连夜偏漏雨.

// 运维组扩容失败 网关扩容出现问题

事后了解到,网关大量的请求过高,无法进行正常的分配 和调用 导致请求无法及时到业务方. 现在又卡在一块了,网关/app启动支撑模块,按照安排

网关紧急库容/我们查找原因同时降级处理/

**AM:9:00**

DBA给出了访问数据库比较多的sql 让我们查为什么这几个调用频率怎么这么高,网关也把所有业务线上响应比较上的倒排序, 其中大部分都是我们的,(其他应用基本上都是做的dubbo 接口注册上去的)我们的创建接口的时候设置的是HTTP 接口,无法进行限流处理, 查看这几个接口的重要性,快速评估,优先保证主链路没有问题,不重要的进行下线处理,后续再说,同时给我们应用也扩容,这个点我能做的是把可以关闭的都关闭了,也是定位到了访问数据库压力比较大的业务,将接口线下处理.这已经是把内裤都脱了,保证生产了,哎

**AM:9.30**

基本平台没有什么问题,也是有一些报错和告警,业务量也上去了,同时看都底层交易平台也逐步稳定(刚才网关出现问题导致大量的数据积压 消息需要处理,)客服的收到的投诉也在逐步处理中,待闭环的下降,多地方显示支付正常,参与活动的用户满意度也有好转,但是现在时间已经快了10点了上午的活动快结束了,给大量用户带来不好的体验,同时我们有个应用是做乘车码的 作用和地铁入口/出口直接扫描就可以出去了,在我们这边开启免密支付,直接扣余额的场景. 但是客户端启动出现问题,用户登录都有error,有部分用户在8点前进去地铁,后面出现瘫痪导致出不去地铁.带来了大量的投诉. App端 所有子应用都是进不去的,我们有个应用是话费充值应用 用户使用这个应用的非常多到了月底用户开始冲话费了 正好到了月底,交易量又受到影响,

**AM:10:00**

所有的系统都开始逐步的恢复正常,但是还是有一部分的Exception 数据库的连接超时,整体接口 成功率80%

### 调查 ###

#### 接口不支持进行限流: ####

>  我们后面的新的模块连接 **网关**的是使用的是dubbo 之间调用,这样可以控制流量,和响应时间控制,请求时间,响应时间,同时引入框架Sentinel 或者 Hystrix 都是可以的,但是这次出事的几个接口随着业务的迭代没有人去关心了,原来一直保持的http 接口,但是网关是没有对http管理 进行管理,这里的管理是指,限流方面的,所以网关模块也是有许多需要改动的,比如接口的限流,接口的流量的优先级,流量的动态图,所有接口的可视化展示

#### 数据库查询频率过高 ####

> 有几个接口查询数据的频率非常高,这是平时不会出现的\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YvimvEle-1592039451359)(D:\\文档\\0613CSDN\\f70602ee314aad964a16388d691f802.png)\]这就可以看到平时连接数是非常低,即使大型活动的时候 如果业务架构设计的好,也不会出现非常高的,突然来了一个珠穆朗玛峰,DBA 都要提着刀过来了,排查后发现是没有恶意攻击的,都是最简单的 先走redis 后数据库,当大量用户突然登录,需要查询用户组/白名单/可见范围权限的时候数据库的流量一下子就上去了 这个是没有任何开关的

#### 机器的CPU资源 ####

>  我们这个模块有原来是有60–75台机器的,历史上是正常的,后来因为历史原因,应用拆分,大部分接口在这个模块上但是机器缺分给我们只有25台使用的,平时流量是没有的,CPU负载是正常范围的,但是活动的那天,\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1EkkNTHI-1592039451360)(D:\\文档\\0613CSDN\\cpu当时的负载情况.png)\]

#### 代码配置 ####

>  数据库的配置最大链接池的大小一开始的设置的是50,其实还是算比较少的,后面改为了这个需要看业务和数据库情况调节,没有具体的值.所以不写出来给大家做参考了哦

#### 代码设计问题 ####

>  上面也发现了,好多是先redis->mysql 这种情况来走到的,但是如果一个值是没有的,突然大流量进来的时候缓存没有建立起来,流量还是到了数据库

### 解决方案 ###

*  短期
    
     *  修改数据库最大连接数
     *  redis 做二级缓存
     *  业务支持降级开关
     *  在大型活动的时候向运维组申请临时加机器
     *  接口改造 http 接口改为dubbo接口 同时加入限流框架Sentinel
     *  老的接口下线处理,前后端都下线,APP端接口下线/不影响用户体验,后端针对模块进行排查接口的业务逻辑
 *  中期
    
     *  代码的评审也就是 CodeReview
     *  接口的设计 需要更加的思考
     *  开发我们自己的工具 来引对大流量的场景
     *  加入到全链路 监控组内,方便实时动态的查看生产情况
     *  全员培训 生产的敬畏之心
 *  长期
    
     *  严防 流量入口 dubbo/Http/Kakfa 保证平台的稳定型
     *  代码的质量, 如果代码比喻为一块块红砖,那么项目就是我们所建起来的高楼大厦,我们的目标是建设上海中心这样的项目总不能做豆腐渣工程吧 质量是第一把关 代码评审
     *  合作大数据 将每天的日志,捞出异常的日志,和日志分析,发送报告给我们,同时配合AI部门做出代码的质量检测 (缺陷/修复 建议)

#### 总结 ####

思考

--------------------

###  ###

捞出异常的日志,和日志分析,发送报告给我们,同时配合AI部门做出代码的质量检测 (缺陷/修复 建议)

#### 总结 ####

思考

--------------------

###  ###

##  ##

[img]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9kc3MzLmJkc3RhdGljLmNvbS83MGNGdjhTaF9RMVlueEdrcG9XSzFIRjZoaHkvaXQvdT0yNDk1MDMyNDk3LDIyNzc1Mzc2NDAmZm09MjYmZ3A9MC5qcGc?x-oss-process=image/format,png