关于西安一码通，我也想说几句_风闻

嗯。。。

有关西安健康码系统连着崩了两次的新闻已经在网上发酵了好几天，想必差友们差不多都知道了。

负责健康码平台搭建的部门领导也在昨天被停了职，算是给了大家一个交待。

不过就在今天差评君发现，西安的健康码又被冲上了知乎热搜。

原因其实不复杂，就是去年 6 月份，一篇关于西安 “ 一码通 ” （ 健康码 ）的报道被大家给翻了出来。

报道的内容差不多就是，一码通团队的成员吃苦耐劳，不眠不休，解决了重重险阻，为疫情防控发挥了巨大的作用巴拉巴拉。

报道不算太长，感兴趣的小伙伴有时间可以自己去搜搜看看。

假如前几天西安的健康码没有两连崩，那么这篇报道怎么写都行，也不会有人在意。

“ 有了一码通，防疫更轻松 ”  ▼

但是就在疫情防控的档口，西安的健康码 gg 了。

于是这篇文章就成了大家分析 “ 一码通为什么会崩溃 ” 的一道技术资料。

结果大家读完之后发现：哦 ~ 原来你们花了两天两夜，把 1 MB 的图片给压缩到了 100 KB。

大小只有原来的 1/10 ，好厉害啊。

对技术稍微有所了解的差友们可能已经听出来了，我是在阴阳怪气。

是的，我就是在阴阳怪气。

不是我吹，别看我就是个臭写字的，但是我只用了 30 秒，就想到了两种办法，把一张健康码图片的大小压缩十倍：

**1 ）**使用 jpg/webp/heif 等格式对健康码进行重编码；

**2 ）**使用 svg 矢量图形绘制健康码；

第一种方法其实大家都会，就是找个图像压缩工具给图片转个码。

别说 100KB ， 10KB 都能压给你看。

第二种方法则是用 HTML 代码把图片元素写出来。

最终实现的文件大小也比普通图片要小。

而且最关键的是，以上这两种方法，都有成熟的代码可抄。

随便 GayHub 一搜，不论你是想跑在服务器里，还是跑在浏览器里，只要复制粘贴几行代码粘贴一下。

一分钟，什么配套库配套依赖都给你安排上，怎么可能两天两夜守在电脑前面干这事。。。

几百款作业任君挑选。。。▼

而且假如 “ 一码通 ” 的团队真就这么独立纯手搓，知乎大佬 DBinary 也帮他们尝试了一下。

结果是一个人、一副键盘、一个半小时。。。

所以假如西安的一码通团队真的花了两天两夜研究图片压缩的事。。。

我看不懂，但我大受震撼。

而且实际上，有好事的热心网友也对西安健康码的网页活动做了元素审计。

结果发现健康码本身就是以字符串的形式传输，然后再在手机本地根据字符串生成的二维码图片。

而从一码通服务器传输过来的字符串本身，压根不会超过 1KB 。。。

至于那篇报道里提到的图片压缩，大概率压缩的是下面截图里的这两张。。。

而不是我们脑补的健康码本身。

其实吧。。。就像大家说的那样，写这篇报道的作者大概率平常是不怎么接触技术的。

比如说，不知道差友们还记不记得，去年我们聊过的阿里 “ 全球第一 ” 的那个视频编码器。。。

所以那位记者发出来一篇看起来很厉害、但其实戳不到技术痛点的文章，还是挺正常的。

很可能可能一码通团队定位这个图片负载问题的时候是有一定技术成本的，但是落实到笔头的时候，记者只 get 到了第一层。。。

不过这些都是题外话了。

所以到底为什么，西安的健康码会连着崩了两次呢？

我也和几个有过类似项目开发经验的小伙伴聊了聊，最后大家得出的结论是：数据库没抗住。

因为根据公开的报道看，西安的一码通平台去年就已经把网络出口扩容到万兆了，今年还有可能更高。

服务器一开始的时候只有八台，但是这一年多的时间里一码通也投入了几百万去购买云服务设施。

可以说从这个规模上来看，就算你真的一张图片有 1MB ，就算静态资源和接口都放在同一个域名上，几十万人同时访问顶多卡点，不至于整个系统崩掉。

但数据库这个玩意，就很玄学了。。。

它每秒钟的承载能力如何，跟表单的大小、制式、内外存的读写速度、宿主机处理器的运算速度、以及网络的吞吐能力都有关系。

要不然美国的甲骨文（ Oracle ）公司也不能光靠研发数据库软件和解决方案，把自己整成了全球 500 强，市值上万亿。。。

尤其是健康码这种数字基建，容纳的几乎是全市的人口信息，外加上它本身还要和更上一级的健康码系统勾连，和疫苗数据、核酸数据、行程数据等等数据库系统对接。

拉取一个健康码背后的逻辑，不可谓不复杂。

假如健康码的数据库在一开始没选好型，隔离没做好，那么一旦后期负载起来了，再发现负载瓶颈的话，大概率就只能靠烧钱的方式扩容堆服务器的性能来解决了。

（ 不过以上这些也只是差评君和一些小伙伴的猜测，假如有小伙伴有更准确的内幕消息，欢迎打脸 ~ ）

其实吧，差评君跟大家叭叭了这么多，多少有那么点马后炮的意思。

毕竟当时国内所有开发健康码的团队都是第一次，没有前车之鉴的情况下做出来的产品性能低一些，也可以理解。

但是光就这两次全员核酸时的健康码崩溃来说，显然是西安一码通对于将会有多少人同时调用服务没个准确的估算，扩容不到位。

这种本来可以避免的徒劳为什么会发生，我不理解。

以前，微博上一有点明星离婚一类的不可预测事件，服务器就得被吃瓜群众搞的宕机。

之后胡忠想就会跑出来说，啊太突然啦，我们已经在紧急扩容了。

不出半个小时，微博的服务就会开始逐渐恢复，大家继续该干嘛干嘛。

但是健康码不是微博，全员核酸也不是什么不可预测事件。

这个锅，西安的一码通还是好好背好吧。

哎，说一千道一万，现在大家希望的，其实只是西安的一码通团队能够吸取这两次的教训。

毕竟， “ 助力抗疫 ” 的健康码可不该如此跳脱，变成抗疫道路上的阻力。

参考资料：

知乎，西安电信一码通项目此前报道中提到「两天两夜把 1m 图片优化到100kb」，图像压缩技术难度是怎样的？，养猫的哈士奇、DBinary 等人的回答