大家好，我是校长。
有读者让我聊一聊关于西安一码通大数据系统崩溃的问题，症结在哪?领导怎么就被撤职了?
领导被撤职这件事，咱可不敢乱分析。
但是，我们可以从技术的角度来聊一聊西安一码通崩溃这件事。
先从最近网上流传的一个特别火的截图聊一聊吧。
呃，看到了么?
由于系统群体规模和访问规模的特殊性，每一行代码、每一张图片、每一个技术文档都反复核准，优化再优化，精益求精。为确保系统运行更高效，他们将一张图片从 1MB 压缩到 500KB，再从 500KB 优化到 100KB。这样的工作看似简单，却蕴含着高技术含量，他们连续两天两夜守在电脑前，终于攻下难关。在不断的优化过程中，“一码通” 平台形成了 A\B\C 三个主从备环境的基本框架，能够满足在各种突发情况下，实现快速响应与切换高可用环境。一个又一个看似微不足道的改进，最终构建起 “一码通” 平台整体的稳定、高效运行。
这是在 2021 年 6 月份的新闻稿，估计是写给领导看的，毕竟领导不懂技术啊。
一张图片从 1 MB 压缩到 500 KB ，再压缩到 100 KB 都可以拿出来给领导炫耀，这样的开发团队技术能好?还两天两夜守在电脑旁边攻下难关。
对此，一码通技术保障组还荣获了 2021 年 “政府信息化管理创新奖”，以及 2020 年 “西安青年五四奖章集体”。
这次疫情，让西安一码通半个月的时间，崩溃了 2 次，现在回想起来这些奖项?多多少少是不是有点可笑呢?
其实，我前天看到这条新闻的时候，我还在纳闷呢?这里的图片压缩指的是什么图片的压缩呢?是一码通上的二维码吗?
为什么服务器端要保存或者生成图片二维码呢?意义在哪里呢?本质上二维码就是一串字符，完全可以在移动端等终端设备上生成啊，服务器将字符串发给手机终端 App，App 根据传过来的字符串在手机上生成二维码岂不是更方便，更快捷呢?
这样就可以给服务器端节省很大的压力，节省算力。
图片等文件，在各个终端之间传输，本质上都是传输的字节，只不过是有一个转换的过程，如果你在服务器端进行转换，那肯定很消耗服务器的性能啊，西安 1000 多万人，比如：同时打开一码通的人有 100 万人，100 万人的图片都服务器端生成和 100 万人的图片都在各自手机终端上的 App 生成，哪个更快，更节省?这都是常识吧?
不理解。
我看很多人也都有我这样的质疑，后来才发现，外包团队还算靠谱，这里的图片压缩并不是二维码。
二维码图片是本地渲染生成的，不是从服务器端下载的。
那这里的图片是什么?是首页里的新闻图片和广告位图片。
根据网上其他技术人的抓包显示，好像最大的那张图是：
呃，你没看错，这张图是从服务器端拉回来的。
我感觉这就有点迷惑了，既然是一个查询功能的展示图，就相当于 icon，不是动态变化的广告位，那为什么要从服务器端拉取呢?直接写死在 App 本地不就行了吗?这样既可以省流量，也可以节省服务器端的带宽，这样干不是徒增压力吗?
而且，在我看来，这个软件的设计，产品经理也要负很大责任，首页罗列了这么多的功能，都超出一屏幕了，尤其是下面的「资讯头条」，每条新闻都带着图片，一进来就请求服务器拉去资源，你说服务器压力能不大吗?
这种无关紧要的功能，完全可以放到二级，三级页面，用户不打开页面，自然没有请求，服务器压力就会减少很多。
对我来讲，工具类软件，首页超出一屏幕的功能罗列在我看来都属于不合格的产品。
当然了，吐槽归吐槽。
虽然从产品的角度来讲，有点不合格。但是，导致一码通崩溃的主要原因，我感觉应该不是图片的原因。
大概率可能跟服务器带宽有关系。
然后，我又搜集了资料，找到了如下数据：
一码通注册用户 4695.2 万，每分钟扫码量 120 万，也就是 2 万 TPS(次每秒)。
2021 年 12 月 20 日早 7 时 40 分左右，西安 “一码通” 用户访问量激增，每秒访问量达到以往峰值的 10 倍以上，造成网络拥塞，致使包括 “一码通” 在内的部分应用系统无法正常使用。
根据一码通 12 月的数据显示日均扫码量是 800 万，而 20 日的访问量是以前峰值的 10 倍以上。所以，建议市民非必要不要展码亮码。
有网友说：假定， “是以往峰值 10 倍以上” 的说辞正确，推算新的峰值访问量将达到 20 万 TPS，按每秒处理 1000 个事务则必须打开 1 万个并发连接的经验来判断，一码通按照每秒 200 万的峰值请求来设计才会保险。
再看看承包单位吧。
中标单位是知名外包公司东软，但是一期的价格是：46 万。
说实话，一个承载 1000 万多人的产品， 46 万真心是不高。这么低的价格，你说能做出什么好产品来呢?
到这里你可能会说：价格低，不一定人家技术差，可能就是带宽不够。
那咱接着看。
由于 2021 年 12 月 20 日一码通崩溃过一回了，所以为了紧急应对这次疫情，总带宽都达到了 700 G ，你还想咋地呢?
所以，不是带宽的问题。
本质上就是软件架构和系统部署有问题，都给你扩容到 700 G 了，硬件都给你拉满了，还能崩溃。
所以，在我看来就是一开始一期项目中标 46 万，这 46 万的价格，肯定外包公司没有用心对待，你想想 46 万够干什么的?一个日访问量百万级的产品。可能就是感觉价格低，加上时间紧任务重，基础架构没有做好。
以致于后期想弥补都不太好弥补了，或者是根本就没有能力弥补了。
我们程序员都这个都有经验啊，祖传代码不愿意改，不好动。而且，一开始做项目的时候，为了赶进度，能凑合就凑合，以致于后期都补救不了了。
最后，我想说：其实这件事挺能给相关部门警示的，我们都知道政府，国企的系统其实都是外包的，体验都不怎么好，关键是没有专业的人，而且，很多数据都是涉及民生的，都只能自己设机房，搞服务器，不使用企业的云服务器之类的。
但是，未来是大数据时代，未来很多数据都是要上云的，这时候，咋办?很多东西未来都是要全国联网的，打通地域之间的限制，其实，国家应该专门成立一个国家级的技术公司，专门来搞上云这件事，不能下放，更不能外包，成立的技术公司，可以跟华为，阿里，腾讯合作，让他们必要时提供技术支持。
否则，十几亿人口的数据上云，没有专业，有经验的团队合作，很难搞。
不能让各个地方各自玩各自的，更不能找那些不靠谱的外包公司。
