1月4日，“新冠”疫情防控之际，西安市个人电子识别码系统（简称，西安“一码通”）崩溃，致使市民无法正常显示疫情防控码，生产生活受到影响。这是半个月来西安“一码通”第二次崩溃。西安市相关部门公开回应称，因访问量太大，全市“一码通”均出现无法正常显示的问题。

1月5日凌晨，西安市大数据资源管理局党组书记、局长刘军因履职不力，停职检查。

据了解，西安“一码通”是2020年2月西安市针对疫情防控牵头开发的大数据平台，业主单位是西安市大数据资源管理局。西安市大数据资源管理局官网信息显示，该平台可以每分钟服务120万人扫码。相比之下，广东的粤康码历史上的最高峰数据是每分钟扫码80万次，但粤康码未出现过西安“一码通”类似大规模、长时间集体瘫痪事件。

西安“一码通”具体瘫痪的原因到底是什么呢？目前有多种推测成因。

根据工信部“中国工信产业网”之前关于西安电信“一码通”的报道，“图片优化”曾经是该项目的一个难关，据报道称：

“由于系统群体规模和访问规模的特殊性，每行代码、每张图片、每个技术文档都反复核准，优化再优化，精益求精。为确保系统运行更高效，他们将一张图片从1MB压缩到500KB，再从500KB优化到100KB。这样的工作看似简单，却蕴含着高技术含量，他们连续两天两夜守在电脑前，终于攻下难关。在不断优化的过程中，“一码通”平台形成了A/B/C三个主从备环境的基本框架，能够在各种突发情况下，实现快速响应与切换高可用环境。一个又一个看似微不足道的改进，最终实现“一码通”平台整体的稳定、高效运行。”

有人因此怀疑，二维码是服务器端生成二维码图片，然后传送到客户端。

此外，还有人发现数据传输过程存在大图片传送，传送的图片是一张美化界面的横幅图片。

在高并发、高访问量的情况下，即使将图片从1M压缩到100KB意义也不算太大，因为这个“一码通项目”的使用场景根本就不需要图片传送，二维码在客户端生成，服务器端传送字符数据，界面也不需要图片展示，只要保证云端计算能力足够大即可，这样的APP做出来，功能完全可以满足，就是界面会变得非常“精简”，没有什么花里胡哨的东西。

但实际一码通项目里，为什么会出现图片传输的功能呢？传送二维码图片的可能性我估计不大，因为就算野鸡程序员也不一定会这么干，除非是自学成才的外行做的开发，根据客户端代码抓包发现，客户端有javascript生成二维码的程序，二维码图片的确是在客户端产生的。

因此图片传输有可能传送的是界面配图，增加配图的原因估计是为了界面好看，让领导满意，因为领导看到的只是界面，不会关心底层技术问题。

这就带来一个问题，无关紧要的图片在高并发、高访问量的情况下，会大幅占用带宽流量资源，使得系统变得越来越缓慢，最终可能导致系统出现一系列问题，这显然是得不偿失的，为了面子而失去了里子。

不过，真正导致一码通崩溃的原因可能并非图片问题，因为即使大图片也可以缓存，调用一次后就不需要再调用了，只是浪费了很多带宽而已，未必就能造成系统崩溃。

我觉得，系统崩溃的主要原因有可能是后端的架构设计问题，大部分后端开发人员写代码的时候没有考虑到高访问量并发查询的问题，相关的架构设计具有一定的技术门槛，这也就导致后端开发的代码只能在低并发的环境里运行，一到高并发环境就会出现各种各样的问题，最终导致系统崩溃。

对于高并发环境下的查询技术，一些科技大厂都有非常丰富的经验，也有很多不错的架构和资源可供使用。

我估计，“一码通”项目的负责人，也就是西安市大数据资源管理局的局长，有可能一点不懂技术，或者身边没有一个懂技术的人，以为这种一码通是很简单的东西，随便找两个人就能做的好，不知道这里面存在架构设计等复杂问题。

这些问题对于科技大厂来说，本来是一个很简单的事情，项目有预算资金，找阿里巴巴、腾讯等科技大厂招标，之后开发、测试、运维，估计到现在也不会出什么问题。但最终却是，387万的项目，只拿出了27万给外包开发。

结果就是，外行领导内行，看不起国内的科技公司，把开发人员当驴指挥，有了资金却层层外包，项目的开发人员做开发只为了应付领导，不考虑实际效率，糊弄了事，领导又不懂技术，只爱面子，最终这些因素合在一起，最终导致了这个“一码通项目”在实际使用过程中出现了严重事故。