一、问题背景

用户群里面有个别用户反馈系统卡主了,一直在刷新,但就是出不来,但是我们本地又是好好的。让用户清空一下缓存,再次刷新就又好了。这个问题乍一看是系统不行的样子,但是查看监控又发现指标一切正常,并没有异常的情况发生。



Http Cookie过大导致的400问题_系统架构


二、问题分析

因为是偶发性问题,用户的bug场景已经消失,没办法远程查看用户的电脑,所以只能根据现有问题,将bug复现出来。

1、排除法定位问题

首先我们可以确定,这个问题是个别用户+特殊场景下产生的,所以可以排除是系统架构问题。然后有一个很明显的点,用户清空缓存之后,就恢复正常,我们服务对外提供接口,是没有缓存之分的,所以问题大概率出现在客户浏览器上面。

还有一个很明显的问题是:前端页面一直在刷新出不来,跟前端沟通发现,如果getUser接口请求没有得到正确的响应,就会一直等待。所以问题再次缩小为:getUser接口没有返回200的正确请求。通过后端api调用日志,可以确定用户出问题的这段时间,没有错误请求进来。

getUser为用户基本信息接口,前端会根据用户信息来判断各种权限。

api的日志没进来,我们可以确定这个接口在nginx端就被拦截了,通过查看nginx端的日志,发现了很多getUser请求报Http 400 Bad Request问题。分析到这一步,我们基本可以把思路放在,什么错误场景下才会产生Http 400错误。

三、找到问题原因

通过对能够产生Http 400的场景进行分析,最终确定是:Http请求头的cookie超过最大限制导致nginx返回400的错误,跟我们的问题场景最符合。跟前端确认产生cookie的页面操作后,最终定位到是登录/退出的页面操作,然后本地不断进行登录然后退出,发现getUser的cookie会越来越大,数据量达到4KB的时候,就返回400错误,复现出用户的问题了。



Http Cookie过大导致的400问题_系统架构_02


四、修复方案

找到问题后,问题的解决方案就简单很多了,既然是cookie太大从而导致的Http 400错误,那就在退出登陆的时候清空历史cookie即可,但是有一点需要注意的是,如果用户处于已登录状态下,访问系统的登录接口,要强制性重定向到登陆后的控制台页面,不能在已登录情况下,重复登录。

所以对应的处理方案为:

  • 后端修改点:登出接口将历史废弃cookie删除。
  • 前端修改点:登录页面下,进行用户登录状态判断,如果已登录就重定向到控制台页面上。

五、复盘总结

虽然找到问题并解决,但同时也暴露出更多的问题来,解决这一个问题并非我们的最终目的,最终目的应该是避免或者更快的找到问题,解决一类的问题。

1、过程存在的问题

  1. 前端对getUser判断太过暴力,非200就一直刷新,一方面影响用户体验,一方面没办法快速定位问题。
  2. 监控体系不够完善,发生多个Http 400错误,没有提前感知到并报警,因为用户主动反馈的都属于一定级别的故障。
  3. 登录/登出的核心功能,方案设计不够完善,cookie清空的基本点都没有考虑到。

2、长期的解决方案

1、完善监控

不仅仅是对系统各个环节进行监控,还要对用户的客户端进行监控,比如console控制台错误,兼容性问题等。设置各类异常点的报警,将报警推送到开发可以看得到的地方(邮件、短信、电话等)。

2、完善规范

前后端对接严格遵循规范,对请求参数、返回值、错误信息等的处理进行明确的要求。对于方案的设计要按照要求:先出设计文档,技术研讨确定,最后再实施测试,让每一次方案设计都能够尽可能的完善,减少出错的概率。

3、制定bug问题库

对每次发生的bug进行复盘总结,形成文档沉淀到公司的bug问题库中,后续不管是遇到问题还是方案设计,都可以借鉴参考,让已经发生的问题,不再重复发生。