从西安一码通崩溃，看压力测试重要性及Bug分析

西安一码通服务器出现问题，服务崩溃了！！！页面没有个人信息显示，拨打西安一码通服务热线也无法接通。全市都无法使用。官方只表示正在对系统紧急抢修解决，请大家耐心等待。西安“一码通”因访问量过大导致系统崩溃，登上热搜。

那我们就从测试角度分析一下这次问题可能出现在哪里，以及压力测试对系统的重要作用和出现此类问题有什么方法补救

故障原因分析

原版，打开西安一码通健康码后，底下会有：

绿码+二维码+疫苗接种情况+最近一次的核酸结果(15天内)

点击“核酸结果”展开，可以看到最近7天内的所有核酸结果

 

在20号瘫痪一天之后，新版一码通变成了这样：

绿马+二维码

 

 

 

 

 

 可以看到【核酸结果】和【疫苗接种情况】不再显示,核酸查询入口挪到主界面，让公交地铁等只扫码但不看核酸的场景不再查询核酸。

只显示最近一条记录，手动查询其他日期也不再显示。

这些措施明显是为了：

1、减少绿码页面的响应数据,

2、减少核酸结果页面查询默认结果

      

原来旧版打开绿码，数据库查询健康码表1次+最近核酸表1次+查询疫苗接种表1次+查询7天内所有核算结果1次。（理想情况下，如果数据从不同系统查询引入另说）

修改后的绿码，数据库查询健康码表1次

核酸页的查询也只变成查询一次最近结果 

由上述改动方案来看有可能是几点导致服务器瘫痪的情况：

1、有些场景只需要绿码页面，不需要核酸，原版都在一页展示，页面查询接口并发量过大；

2、市民上班时间集中使用遇到无法刷出健康码的情况，多次尝试刷新进入，进一步增加并发，服务器瞬时访问流量急速上升，数据库性能也跟不上；

3、没有考虑高流量高负载的情况，导致测试不充分；产品设计未考虑千万级的并发访问，交付前未进行同等级的压力测试。

根据百度数据，西安人口约1300万，属于千万级别

 

问题解决建议

新版的一码通已经给出了他们的解决方案：

1、业务剥离，将核酸结果从绿码分开使用，细化区分使用场景，将业务关联度比较高的模块独立化。

 2、减少接口通讯数据，查询7天内所有核算结果变成最近一次查询结果，日期查询无结果，砍功能了属于是。

除了这两个还可以，1、短时间内多次请求可做防抖机制(应对多次尝试刷新进入)；2、核酸结果建议做缓存机制，24小时间隔后再次访问强制刷新，接口可带时间戳参数；3、 添加高性能自动化测试，压力测试；在发布前做预防机制；

另外由于西安应急措施不足，导致应对秩序混乱，公交地铁手动登记，考研因考点关闭导致的无措，加上出血热，希望肉夹馍加油，大家都能平安健康

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

 

没想到啊，这个事还能有后续，12月30日，孙春兰总理亲赴现场指导疫情，国家工信部总工程师到陕西通信管理局调研，国家要求西安一定保障一码通的系统，

 

 结果，1月4日上午，一码通又崩了，1月5日就把局长开了 ，办事效率惊人（属于是当着钦差大臣的面现眼了），

按道理来说，这软件应该不是买高性能服务器扩容能解决的了，毕竟国家都出手了，服务器那几个钱肯定不是事了，

那就是程序设计架构有问题，不支持扩容 or 不支持高负载访问

走到这一步，估计已经换公司了，工信部大佬直接拿出一套新架构，全部程序员通宵开发测试，

应该以后也不会出问题了，这么看问题确实出在局长这条线上(狗头)