从前端角度分析：西安一码通崩溃事件-轻识

事件现象

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

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

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

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

❝
一边刷新一码通，一边陷入分析的旋涡。
❞

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

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

现状如此，前端能否做些什么？

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

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

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

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

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

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

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

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

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

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

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

「西安加油！」

原文:juejin.cn/post/7044758038858694687

长按下面二维码添加【鬼哥】微信