我看西安“一碼通”崩潰事件：外行領導內行

1月4日，“新冠”疫情防控之際，西安市個人電子識別碼系統（簡稱，西安“一碼通”）崩潰，致使市民無法正常顯示疫情防控碼，生產生活受到影響。這是半個月來西安“一碼通”第二次崩潰。西安市相關部門公開回應稱，因訪問量太大，全市“一碼通”均出現無法正常顯示的問題。

1月5日凌晨，西安市大數據資源管理局黨組書記、局長劉軍因履職不力，停職檢查。

據了解，西安“一碼通”是2020年2月西安市針對疫情防控牽頭開發的大數據平臺，業主單位是西安市大數據資源管理局。西安市大數據資源管理局官網信息顯示，該平臺可以每分鐘服務120萬人掃碼。相比之下，廣東的粵康碼歷史上的最高峰數據是每分鐘掃碼80萬次，但粵康碼未出現過西安“一碼通”類似大規模、長時間集體癱瘓事件。

西安“一碼通”具體癱瘓的原因到底是什么呢？目前有多種推測成因。

根據工信部“中國工信產業網”之前關于西安電信“一碼通”的報道，“圖片優化”曾經是該項目的一個難關，據報道稱：

“由于系統群體規模和訪問規模的特殊性，每行代碼、每張圖片、每個技術文檔都反復核準，優化再優化，精益求精。為確保系統運行更高效，他們將一張圖片從1MB壓縮到500KB，再從500KB優化到100KB。這樣的工作看似簡單，卻蘊含著高技術含量，他們連續兩天兩夜守在電腦前，終于攻下難關。在不斷優化的過程中，“一碼通”平臺形成了A/B/C三個主從備環境的基本框架，能夠在各種突發情況下，實現快速響應與切換高可用環境。一個又一個看似微不足道的改進，最終實現“一碼通”平臺整體的穩定、高效運行。”

有人因此懷疑，二維碼是服務器端生成二維碼圖片，然后傳送到客戶端。

此外，還有人發現數據傳輸過程存在大圖片傳送，傳送的圖片是一張美化界面的橫幅圖片。

在高并發、高訪問量的情況下，即使將圖片從1M壓縮到100KB意義也不算太大，因為這個“一碼通項目”的使用場景根本就不需要圖片傳送，二維碼在客戶端生成，服務器端傳送字符數據，界面也不需要圖片展示，只要保證云端計算能力足夠大即可，這樣的APP做出來，功能完全可以滿足，就是界面會變得非常“精簡”，沒有什么花里胡哨的東西。

但實際一碼通項目里，為什么會出現圖片傳輸的功能呢？傳送二維碼圖片的可能性我估計不大，因為就算野雞程序員也不一定會這么干，除非是自學成才的外行做的開發，根據客戶端代碼抓包發現，客戶端有javascript生成二維碼的程序，二維碼圖片的確是在客戶端產生的。

因此圖片傳輸有可能傳送的是界面配圖，增加配圖的原因估計是為了界面好看，讓領導滿意，因為領導看到的只是界面，不會關心底層技術問題。

這就帶來一個問題，無關緊要的圖片在高并發、高訪問量的情況下，會大幅占用帶寬流量資源，使得系統變得越來越緩慢，最終可能導致系統出現一系列問題，這顯然是得不償失的，為了面子而失去了里子。

不過，真正導致一碼通崩潰的原因可能并非圖片問題，因為即使大圖片也可以緩存，調用一次后就不需要再調用了，只是浪費了很多帶寬而已，未必就能造成系統崩潰。

我覺得，系統崩潰的主要原因有可能是后端的架構設計問題，大部分后端開發人員寫代碼的時候沒有考慮到高訪問量并發查詢的問題，相關的架構設計具有一定的技術門檻，這也就導致后端開發的代碼只能在低并發的環境里運行，一到高并發環境就會出現各種各樣的問題，最終導致系統崩潰。

對于高并發環境下的查詢技術，一些科技大廠都有非常豐富的經驗，也有很多不錯的架構和資源可供使用。

我估計，“一碼通”項目的負責人，也就是西安市大數據資源管理局的局長，有可能一點不懂技術，或者身邊沒有一個懂技術的人，以為這種一碼通是很簡單的東西，隨便找兩個人就能做的好，不知道這里面存在架構設計等復雜問題。

這些問題對于科技大廠來說，本來是一個很簡單的事情，項目有預算資金，找阿里巴巴、騰訊等科技大廠招標，之后開發、測試、運維，估計到現在也不會出什么問題。但最終卻是，387萬的項目，只拿出了27萬給外包開發。

結果就是，外行領導內行，看不起國內的科技公司，把開發人員當驢指揮，有了資金卻層層外包，項目的開發人員做開發只為了應付領導，不考慮實際效率，糊弄了事，領導又不懂技術，只愛面子，最終這些因素合在一起，最終導致了這個“一碼通項目”在實際使用過程中出現了嚴重事故。