从前端角度分析:西安一码通崩溃事件

3,175 阅读4分钟

事件现象

12月20日,西安一码通崩溃了,网上随即出现大量像段子一样的新闻,比方说:健康码打不开,需手执健康码截图凭发誓进入公司;比方说维护一码通的开发因为打不开健康码而进不了软件园。

image.png

下午响应政府号召去做核酸,排在需要三四眼才能望到头的位置,不停的有人相互询问:“你的码能刷出来吗?”
“我的码也刷不出来,估计系统崩了吧,也许一会重启下就好了。”

半个小时后,等待检测的队伍突然躁动起来。我踮起脚尖看到前面排队的人开始分散,随后听到前面的传话:“系统问题,暂停检测!”
无奈离开的我,耳边传来不知是谁喊的一嗓子:“弄撒哩”。

这声音很刺耳,无他,只因同是西安IT人。

崩溃原因分析

一边刷新一码通,一边陷入分析的旋涡。

小程序的界面出来了,证明前端静态资源加载无异常。
健康码疫苗及核酸状态显示区域布局塌陷,虽然没有日志可供分析,但基于常识可认定为:因接口压力过大,导致的后端服务崩溃

但西安上千万的市民,可不管你后端崩不崩溃。市民甲乙丙丁因为健康码加载失败,大多会选择重新打开小程序,而这造成了接口调用量指数级增长,使原本就不富余的服务器资源更加雪上加霜。

现状如此,前端能否做些什么?

前端该做些什么

在一个行业呆的久了,每当遇到出现在身边的BUG就难免会有代入感。虽然自已这二把刀的技术,连参与健康码开发的机会都没有。

1. 对异常进行处理

从界面上来看崩溃的主要原因是接口返回异常,且在此情况下前端并未对异常进行处理。

捕获并处理接口返回的异常,是一项基本的前端礼仪。
当接口异常时,通过错误页告知用户本次打开失败了,并提醒或强制通过倒计时等交互来防止用户频繁刷新。

仅此一项简单交互,就可以减少大量的接口压力。

2. 梯段显示

从界面分析中发现前端在逻辑实现中并没有把健康码、接种疫苗状态、核酸检测状态进行分批加载,正是这种一把梭的加载方式导致一处崩所有崩。

假设后端已经存在微服务架构,前端理因根据优先级异步加载这三组来自不同微服务的数据。
甚至于将其中的接种疫苗、核酸检测状态改造为触发式加载,即优先展示健康码,并在原接种疫苗、核酸检测状态的位置增加触发按纽。

3. 前端缓存

通过以往的使用,基本可以确认个人的健康状态非实时更新。

即然如此,个人的健康状态在两次计算的间隔期就应该利用前端缓存。
核酸及疫苗状态虽然与健康状态有所不同,但也可以通过前端缓存 + 触发式更新的方式进行前端缓存利用,即在人员进行核酸检测及疫苗接种扫码时,清除前端缓存并将清除状态保持至数据更新前。

以上的方式有着同一原则:使用前端手段,减少不必要的刷新,从而达到减少服务器压力的目的。

一切都会好的

防止系统崩溃的最好方式是平日里敲击的键盘,在日常工作中少一些所谓的底层逻辑、顶层设计、过程抓手,多留一些优化时间给新时代的农民工。

没有一个不可逾越的冬天,一切问题都会解决。
我是写个程序换个饼:一个玩过传奇喜欢杀生丸的前端开发,GridManager作者。

西安加油!