有关西安健康码连续崩了两次的新闻，已经在网上发酵了好几天，相关的负责人也被问责，西安的健康码一度冲上热搜，有网友用广州健康码的数据与西安健康码做比较，认为这并非天灾而是人祸，那么问题到底如何，超拼科技今天从专业的角度给大家分析分析。

说起西安健康码的问题，就不得不说起去年6月份一篇关于西安一码通的报道，大概内容概要是经过团队的不懈努力，吃苦耐劳、不眠不休解决了重重险阻，为疫情防控发挥了巨大的作用，报道不算太长，假如前几天西安的健康码没有两连奔溃，那么这篇报道怎么写都行，也不会有人在意，但在现在这个节骨眼上这篇文章就成为专业人士分析一码通崩溃问题的技术资料，这篇报道中有一段描写如下“由于系统群体规模和访问规模的特殊性，每行代码、每张图片、每个技术文档都反复核准，优化再优化，精益求精。为确保系统运行更高效，他们将一张图片从1MB压缩到500KB，再从500KB优化到100KB。“

从这里不难看出，技术团队经过两天两夜的时间将1mb的图片压缩到了100kb，大小只有原来的1/10，对技术稍微有点了解的朋友都知道，十倍的压缩率根本不值一提，首先它压缩的肯定不是健康码本身，因为二维码这种东西就是一串数据，是可以在前端本地收到数据之后生成二维码的，笔者通过对西安健康码代码的分析，发现西安一码通本身就是以字符串形式传输的，然后再在手机本地根据字符串生成二维码图片。

所以报道里提到的图片压缩，大概率指的是健康码打开页面的这几个装饰性图片，其实就当下的技术而言图片十倍的压缩率根本不是什么技术问题，技术可以实现的方法有很多，也可以使用svg矢量图形绘制，用html代码把图片元素写出来，最终实现的文件大小也会比普通图片小很多，而且最关键是图片的存储一般稍微有点经验的技术处理这种无关数据安全的图片，要么将图片放到阿里云OSS这类成熟的第三方存储，要么用专门的图片存储服务器来存储图片，而通过上述前端代码路径来看，图片应该是存储在业务服务器，现在看这个新闻确实让人看的一头雾水，两天两夜解决这么一个问题，实在很让人费解。

然而让西安一码通连崩溃两次的，应该不是图片的问题，从专业的开发角度而言大概率是因为数据库没有抗住！因为图片完全可以在用户第一次打开的时候缓存到本地，生活在西安基本上吃饭坐车、出入都要扫码、不存在很多人第一次使用的情况，根据公开的报道来看，西安的一码通平台去年就已经把网络出口扩容到万兆了，今年有可能更高，服务器一开始的时候只有8台，但是这一年的时间里，西安一码通也投入了几百万去购买服务器设施，可以说从这个规模上来看，就算真的一张图片有1mb，且每次都要加载一遍，就算静态资源和接口都放在同一个域名上，几十万人同时访问顶多卡点，不至于让整个系统崩溃，但是数据库就很玄学了，它每秒钟的承载能力如何，跟表单的大小、制式、内外存的读写速度、宿主主机处理器的运算速度以及网络的吞吐能力都有关系，要不然美国的甲骨文公司也不能光靠研发数据库软件和解决方案就成为了世界五百强。

像健康码这种数字基建，容纳的几乎是全市所有的人口信息，外加上本身还要和更上一级的健康码系统勾连，和疫苗数据、核酸数据、行程数据等等数据系统对接，拉取一个健康码最后的逻辑，不可谓不复杂。问题的本身是清晰的，而笔者在使用健康码的过程中发现，西安健康码在崩溃前做了很多迭代升级，似乎想把系统构造成一个政务生活平台，在系统里面对接了社保、小饭桌、停车诱导、个税计算器……等等

加入这些功能可能初衷无可厚非，但是假如健康码的数据库在一开始就没有选好型，隔离没做好，那么一旦负载上来，再发现负载瓶颈，大概率只能靠烧钱的方式扩容堆积服务器的性能来解决问题，在两天还有一个很厉害的传言说西安一码通的服务器是阿里云在美国的服务器，这就不光是疫情的事情了，还牵扯到数据安全的问题，庆幸的是笔者通过技术手段验证后发现这确实是个谣言。

健康码崩溃的问题说了这么多，很多人就很疑虑为什么健康码要每个省做一套，甚至西安市都没有用陕西省的健康码，这就不得不说现在疫情的现状了，现在的疫情都是局部的，讲究精细化调控，各地的需求不太一样，如果让全国统一调配可能不切实实际了。

关于西安健康码的谜云大概率就是这个情况，那么各位读者朋友是不是意识到了找一家靠谱的软件开发公司是多么重要的事情了吧，超拼科技就是这样一家公司。

大家如果有技术问题也欢迎跟我们进行探讨……

超拼科技-科技赋能，帮助合作的每一位伙伴获得成功！