西安一码通崩溃2次，作为一个曾经写过几年代码的西安码农实在是脸上无光，本来不想说些什么，直到我看到了这张图：

主要是这段话：为确保系统运行更高效，他们将一张图片从1MB压缩到500KB，再从500KB优化到100KB。

答题者以为所说的压缩图片是指二维码图片，我心想，就是一码通的技术人员再不行也不至于如答题者所说在传图片吧，二维码无非就是一串字符串，服务器生成字符串，客户端生成二维码这是常识吧，于是准备测试一下用证据来说话。

于是用浏览器打开西安一码通url：

我们先来看看它引用了哪些js文件：

可以看到除了jquery（js库）、weui（微信UI）、swiper（滑动模块）之外，是有jquery.qrcode二维码生成js的，所以说西安一码通的二维码是本地生成的，并不是在传图片，开发人员并没有那么蠢。

然后我又抓包分析，也确认了推测，登录一码通之后，向服务器请求了一段json，json数据就含有关键code信息，之后也并没有二维码图片数据的网络传输。同时通过网络抓包，还得出了一码通还是有本地缓存机制的，反复刷新的时候并不会每次都从服务器请求json数据。

所谓一张图片压缩到500K以及100K之类的，个人感觉应该只是某个不懂技术的记者在采访完一大堆技术人员后，只记住了某个美工所说的对资源图片的压缩处理的话而已，估计这个记者觉得这个数字很直观，却没想到让人贻笑大方。

既然反驳了这个谣言，那么我粗浅的从我能看到的反驳一下其他谣言。

谣言：西安一码通没有分布式部署，没有容灾机制，只是一台老旧服务器。

从笔者了解，西安一码通使用多家服务商提供的技术服务，其中就有阿里云私有云。

并且ping一码通网关地址：data.xa.gov.cn

可以看到使用CDN加速以及gtm容灾机制。所以谣言不攻自破。

谣言：西安一码通层层转包最终价27万。

谣言的起因是这张截图，但是仔细看不难发现，这张截图上27万的项目名称为“西安市科技局创新一码通”，跟西安一码通完全是两个东西，被混淆了而已。

在这里并非给西安一码通洗白，两次大范围崩溃并且长时间无法恢复必定是存在问题的，个人推测更多是架构的问题，或者某些业务逻辑的关键节点有问题。

上文中我证实他有CDN加速以及容灾机制，但至于配置的好不好，这个就不得而知了。另外一码通负载均衡有没有做，做的好不好，也是无从得知的。还有造成崩溃可能性最大的数据库是完全隐藏在后端的，除非项目的开发人员，我们无法得知西安一码通的数据库架构如何，因为数据库是最可能造成瓶颈的原因之一。数据库设计的合理与否直接关系查询效率，而如何避免数据库堵塞也是高并发系统的难点之一。

最后两次崩溃的卡壳界面都是一码通页面加载完成，与后台获取json信息时出现了问题，具体的接口地址是：

但是这个接口背后的业务逻辑只有一码通的开发人员才清楚，只有看到项目源代码才能知道这个接口到底涉及到多少数据，多少业务，进行了多少次数据处理，有没有做优化，是否健壮，是否符合高并发需求，就不得而知了。

一码通从2020年立项之初只是展示三色码记录扫码时间位置来进行大数据流调，后期不断增加新需求，包括核酸检测，疫苗接种，等等，在源文件中甚至还残留西安马拉松赛事相关代码，所以个人猜测是初期的薄弱架构无法胜任后期不断增加的需求，导致扩容以及业务逻辑节点都存在困难和隐患。

从页面引用的js文件版本号可以看出，其他js文件都是2021年12月9日版本。唯独qrcode.js是2022年1月4日的版本，笔者打开qrcode.js发现里面是一码通的主要业务逻辑，说明导致1月4日瘫痪的原因可能与部分业务逻辑相关，这也正好佐证了我的观点。

在疫情的关键点掉链子，让医护人员和百姓在寒冬因为一码通瘫痪白白付出辛苦和时间，并加重疫情传播风险，这样的错误是不可原谅的，但是相信一定会有一个公正的调查结果，只是不要轻信这些低级的谣言。

郑重声明：本文仅从技术层面对相关谣言进行辟谣，非对一码通瘫痪以及相关人员失职洗白，请勿人身攻击！