大家好，我是校長。

有讀者讓我聊一聊關于西安一碼通大數據系統崩潰的問題，癥結在哪?領導怎么就被撤職了?

領導被撤職這件事，咱可不敢亂分析。

但是，我們可以從技術的角度來聊一聊西安一碼通崩潰這件事。

先從最近網上流傳的一個特別火的截圖聊一聊吧。

呃，看到了么?

由于系統群體規模和訪問規模的特殊性，每一行代碼、每一張圖片、每一個技術文檔都反復核準，優化再優化，精益求精。為確保系統運行更高效，他們將一張圖片從 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 萬夠干什么的?一個日訪問量百萬級的產品。可能就是感覺價格低，加上時間緊任務重，基礎架構沒有做好。

以致于后期想彌補都不太好彌補了，或者是根本就沒有能力彌補了。

我們程序員都這個都有經驗啊，祖傳代碼不愿意改，不好動。而且，一開始做項目的時候，為了趕進度，能湊合就湊合，以致于后期都補救不了了。

最后，我想說：其實這件事挺能給相關部門警示的，我們都知道政府，國企的系統其實都是外包的，體驗都不怎么好，關鍵是沒有專業的人，而且，很多數據都是涉及民生的，都只能自己設機房，搞服務器，不使用企業的云服務器之類的。

但是，未來是大數據時代，未來很多數據都是要上云的，這時候，咋辦?很多東西未來都是要全國聯網的，打通地域之間的限制，其實，國家應該專門成立一個國家級的技術公司，專門來搞上云這件事，不能下放，更不能外包，成立的技術公司，可以跟華為，阿里，騰訊合作，讓他們必要時提供技術支持。

否則，十幾億人口的數據上云，沒有專業，有經驗的團隊合作，很難搞。

不能讓各個地方各自玩各自的，更不能找那些不靠譜的外包公司。