西安电信一码通项目此前报道中提到「两天两夜把 1m 图片优化到100kb」，图像压缩技术难度是怎样的？ 第2页

嗯，作为互联网人说几句吧。怎么说呢，大概有这么几个槽点：

1 图像压缩不是什么难的技术

首先我们要确定这个图片是否可以被压缩。如果此处指的是一码通的二维码，那显然可以被压缩（因为二维码的分辨率并不需要很高）；如果指的是广告位图片或者logo，都这时候了把这种图片干掉不更好么？

如果你自己打开电脑的画图板，将一张图片分辨率缩小，或者把图片从bmp转换为png jpg，这并不算是很难的事情；并且你会发现，二维码这么大的图片确实应该需要不到50k就可以了。

2 二维码图片应该在客户端生成，服务端应该只需要发送字符串给客户端

这是更加需要吐槽的地方。二维码字符串应该在服务端生成，这样传送给客户端时，实际响应请求大小应该是1k级别的。

客户端生成二维码的库应该是现成的。

所以我有点怀疑，原文里面说的真的是二维码吗？真的像是广告位或者logo图。

3 一码通崩溃的根因？

我们可以这样理解网络请求，一类是占用较大带宽的（例如视频，图片，直播），另一类是占用较大计算资源（例如生成实时的二维码）。

这两类的优化思路完全不同，文中说的针对的是前一类的优化。

我们假设西安1000w人口，有400w人需要在1小时内使用一码通。平均qps是1k，峰值期间假设突发10倍，也就是10k qps；按照文中图片压缩到100k来说，峰值带宽为1G。

怎么说呢，我的感受是10k qps的计算压力更大一些；在图片优化之前，带宽压力是10G，容量较小的机房确实有可能顶不住，但是大机房基本没问题（当然前提是你有足够的分发服务，比如nginx）。

4 缺少性能测试和容量评估

重要的事情说三遍，性能测试！性能测试！性能测试！

不过抛开技术来说，这里更有可能的是一个配合问题。即运营提出了大家集中使用一码通的要求，但这个诉求和风险并没有传递给技术人员，从而没有对此时系统所需的容量进行评估。

换句话来说，可能并不是没做性能测试，而是根本不知道自己要面对的压力是有多大。

当然，以上基本属于我的猜测，实际情况可能并不是这样，估计我们也是无从得知了。

ps：

我也是个西安人，实际上并不是在说老家的坏话，只是想从纯技术的角度说明一下我的理解。

目前这么多人赞我，受宠若惊，谢谢大家。

这个事情，完全不是一些高赞回答说的这个事情。

西安电信好歹也是管着一个市的三大运营商，外包再弱，也弱不到给服务器给手机传一张1M的图片。

而且有人已经抓包验证过了。

一般来说，这种八股文章是办公室秘书写的。

秘书一般来说，不懂技术

但是，写文章还得出彩，一般来说，就会问下面要资料，这个资料最好有数字，显得有东西。

问题是，开发人员不会写文章，你非要，就给你编一个图片压缩，糊弄秘书。

办公室秘书不懂，你怎么给材料，我怎么写，最多文字通顺点。

这种笑话，就写出来了。

审稿的是办公室主任，他也不懂。

终审是领导，领导更不懂，看看文字好像没问题，这个东西就发出来了。

西安一码通崩溃，并不是这个图片的问题，图片在手机里面有，你下载APP的时候已经下载了，不用从服务器端再加载，除非APP自动升级。

西安一码通崩溃，无非数据库和网络的问题。一码通背后是一个数据库的查询比对，并发少，数据量少的时候，不是问题。

大家日常用，虽然1000多万人，但是在一秒钟内亮码做查询动作的时候，可能只有几万人，上下班高峰可能也就是几十万。

数据库里面一个人两次核酸，一共2000万条记录。

以前写的程序，网络的带宽，可能预留到百万并发。数据库优化也针对2000万条记录优化的差不多。能使用。

但是，到了集中亮码，全民多次核酸的时候。一个人10轮核酸，这是1亿条核酸记录，并发远不是几十万。而是几百万。

这个时候就崩了，而且很难短时间解决。

你开发一套新的，来不及。

旧的正在运行，升级了怎么切换？

当初开发这个东西，也是2020年疫情期间，做一个能用的，不一定草台班子，肯定是一个不太成熟的东西，也就是适应当时的情况。

这个东西，恐怕不止西安一码通。各地的都不好说。

1000万级别的大城市，搞多轮核酸，系统架构设计是否顶得住也难说。

这个事情，可以给各地提醒一下，遇到西安这个情况，需要怎么优化数据库，需要多少资源能顶住。

其实，12306能搞定，一码通应该是小问题，就是预留要想充分。

看到文章后比较疑惑两点：

1.为啥一码通这种高并发应用会出现后端传图片的问题？还是1MB的高清图片？

2.到底传了什么重要的图片给前端？

然后就在手机上随便抓了个包——

打开 Stream ，模拟一般用户操作，点击西安一码通，分别点击查看健康码，查看核酸报告，然后查看抓包结果——

只发现了这些包含图片的响应，其中数据量最大的，就是这张图——

疑惑解开了，应该就是为了产品界面美观而从后端传了一些图片进来。

总体来说，这个事儿本身就是个迷惑行为，比如我们江苏的苏康码，打开就是你的健康码，功能单一，交互体验虽然说不上友好但简洁明了。

我在想，做这种超高并发的，应用场景复杂的应用不就应该秉承简洁明了稳定的宗旨吗？你为了界面美观搞了一大堆用不到的东西上去，不是脑子有毛病吗？

从工作经验上来看，这事儿可能就是产品牵头搞出来的，为了美观牺牲性能的典型问题；

再深一层说，可能就是为了满足领导们对界面美观的要求，而不得不牺牲研发诉求的问题。

以上都是我猜的。

总结出来的教训，就是以后但凡涉及到不熟悉不懂的领域，还是去请教懂的人吧·····

以上。

---

  nordwand 网友的相关建议: 
      

有人抓包看过了，二维码是在客户端生成的。至于那个在服务器端原大小1M最后被压缩到100k传到客户端的图是什么，就不得而知了。

---

这东西的槽点不在于图片压缩问题。

服务器根据每个人的疫情防控信息生成了健康码，然后被开发人员费劲心思把健康码的图片压缩后传到了客户端；健康码被扫描后，其中包含的信息都在生成的一串字符串中，这个字符串包含了个人疫情防控信息。扫描健康码得到了字符串，即可快速得到个人防控信息。

那，为什么不直接向客户端发送字符串，由前端生成二维码呢？

---

  serenayu 网友的相关建议: 
      

Logo和卡通图片不用svg，倒是去加班压缩jpg？jpg压缩需要加班？

战术上的勤奋不能掩盖战略上的懒惰，加班的自我感动不能掩盖低下的业务水平。

---

  guidaogui 网友的相关建议: 
      

难度大概是这样的：

       image_resize(...);//压缩图像，改变图像尺寸 sleep(100);/*睡眠0.1秒，在第2个版本删除这一句，以提升用户体验*/ sleep(100);/*睡眠0.1秒，在第3个版本删除这一句，以提升用户体验*/ sleep(100);/*睡眠0.1秒，在第4个版本删除这一句，以提升用户体验*/ sleep(100);/*睡眠0.1秒，在第5个版本删除这一句，以提升用户体验*/ sleep(100);/*睡眠0.1秒，在第6个版本删除这一句，以提升用户体验*/ sleep(100);/*睡眠0.1秒，在第7个版本删除这一句，以提升用户体验*/ sleep(100);/*睡眠0.1秒，在第8个版本删除这一句，以提升用户体验*/ sleep(100);/*睡眠0.1秒，在第9个版本删除这一句，以提升用户体验*/ sleep(100);/*睡眠0.1秒，在第10个版本删除这一句，以提升用户体验*/       

经过两天两夜后，终于把睡眠函数删掉了一半，系统流畅度极度提升，用户体验也很不错。

另外的一半先留着，以备不时之需，因为不知道什么时候领导又要优化。

---

  li-xiang-1-48 网友的相关建议: 
      

2583. 22万元

---

  dao-bi 网友的相关建议: 
      

我不禁好奇了，是什么级别的代码功底，需要用两天两夜？

我现在都还能翻出来我以前写的稀烂的图片压缩代码，也用不了两天两夜啊。。。。

而且手机上的软件，有几个敢在软件内部用1M大小的图片？

这也太吓人了。

感觉这是忽悠不懂行的人的工作总结。

还是说以前一码通完全没有做缓存，也没有做虚拟分发之类的东西，所有通信都是直来直往，突然一下高并发，就给搞崩了。然后不好解释....

---

  feng-kuang-shen-shi-92 网友的相关建议: 
      

做过类似相关的程序。说一下，图片大小与一码通系统崩溃的因果关系。

讲这个之前，请注意两个概念，第一、客户端（手机端）；第二、服务端

1、图片压缩主要是在哪里生成？

图片压缩并不是很难的事，不同格式的图片存在着各种压缩的方式。

以jpg格式的图片来说，运用有损压缩的时候，压缩比例大得惊人。这个找个PS，然后选择色盘，把颜色数量调小点。瞬间能看到效果。

因此优化图片并不是重点。

新闻公报中所说的图片大小，不知道指的是哪个图片？

按照通常的理解，图片主要是有两块。

第一、注册时候的身份证识别。

第二、二维码的生成。

如果存在身份证的识别，就需要把身份证图片上传到服务器端，然后在服务器端保存，这个图片大小影响巨大。

二维码的生成，二维码肯定是在服务器端生成的。图片的大小影响巨大。

如果二维码有100多K那完蛋了，太大了，没有必要。

大家随便找一张二维码，中间有logo的那种一般就10K左右的样子。

2、网络传输，尽量要求不传输图片

我以前从事过一个系统部分内容的开发。就是很多幼儿园，进幼儿园报道的时候，抓拍一下儿童的照片，然后把照片发到家长的手机里。

不发图片一点问题都没有，一旦发照片，很难做到及时推送。

因为幼儿园上学跟放学的时间太集中了。当时瞬间的操作，尤其是节假日的前一天。那个峰值非常恐怖。

回到一码通来，其中可能存在的服务端生成图片的部分，就是二维码了。

这种二维码如果是电信自己写的APP，可以在客户端直接生成，传输只需要传输少量的格式信息即可。

如果是微信小程序，那服务端生成的二维码，100K还是大了，还需要缩小。

3、测试

西安电信的一码通崩溃，我其实挺理解的。这个好比中国最牛的电子商务网站12306一样。

以前春运期间是日常的崩溃。

道理就是有大量的人涌入，服务器处理不过来。

不过值得特意说明的是：一码通项目跟图片压缩的关系不大。

因为当时使用的过程应该是不存在图片的上传。

因此，网络带宽不是主要问题。

主要问题是服务器的处理容量等。没有先做好压力测试。即便做过压力测试，也只能说没有达到现实的这种场景。

4、项目的金额与CDN

这种项目明显是外行领导内行，据说整个一码通的项目是30万块钱。

从程序架构来看，问题不大，从抓包的结果来看。

所谓1M的图片只是开头的一个静态的图片。

就是上面这张。

然后随便找了一台服务器应付了事。

平常每秒用到二维码的人不多，所以没事。

现在西安一下子用的人多，那套肯定应付不了。

其实，只要整一下CDN，这个问题瞬间解决。

---

  wang-lei-45-21-47 网友的相关建议: 
      

对于搞技术的而言基本、大概、理论上可以说是没难度，不过很显然这篇报道里写的并不是给普通人看的，给完全不懂技术的外行领导内行的领导看足够糊弄了。

---