西安一碼通崩潰的真實原因是什么？
大家好！我是編程君
最近西安一碼通二次崩潰這個事情，實在是太頂了。作為程序員，出現(xiàn)這種問題屬實不應該。
網(wǎng)上一直在說崩潰是因為后臺傳輸?shù)氖菆D片？
第一次看到這個消息的時候，小孟是抱有懷疑態(tài)度的。畢竟大家都知道這種大的政府項目都是要招標的，我曾經(jīng)參見過很多次的競標，能去競標的公司都不是很小的公司，因此技術實力也不是一般小公司的水平。
作為程序員來說，怎么會出現(xiàn)這么低級的錯誤呢？不管是開發(fā)還是測試，應該認真負責自己經(jīng)手的產(chǎn)品。
網(wǎng)上有很多大神對問題進行了分析。
知乎上也開了個貼討論：一碼通崩潰的技術原因是什么？
原帖地址：https://www.zhihu.com/question/509914161，有興趣的小伙伴可以自行前往。
目前最熱回復如下：
優(yōu)化上的猜測。這里提到了一篇陜西電信的文章。
于是小孟去找了一下，還真有一篇名為《“科技抗疫”中流砥柱：西安電信“一碼通”平臺服務保障專班》的報道，地址：
https://m.thepaper.cn/baijiahao_13083245
里面有這樣一段話被網(wǎng)友們抓了出來：
上面這段話中的紅色部分，就是該答主所指問題所在！
這篇洋洋灑灑近2000字的"美文"，就這一小段與技術沾點邊，所以確實極有可能就是當時該系統(tǒng)開發(fā)時面臨的最難攻克點。而這樣的實現(xiàn)方式，也確實并不是一個好的選擇！
小孟創(chuàng)建的技術交流群，好多的小伙伴都在聊背后崩的原因是什么。我也很感興趣！
今天又在知乎上看到了知友 “盧興民” 的回答，別人是真的去分析了二維碼接口數(shù)據(jù)的，證明并不是在服務器生成圖片。
西安健康碼的接口數(shù)據(jù)
真正的二維碼數(shù)據(jù)是 /person/app/refreshQRCode這個接口
這位知友表示：
看下這個接口返回，設計上也沒有太大的問題。?
主要問題集中在所有的js/css/img這些靜態(tài)資源全都從從一個出口進行提供，沒上CDN
粗略估算了一下，js/css/img數(shù)據(jù)總共約500kB?
按照從某個群里得到的數(shù)據(jù)，暫且認為是準的，健康碼的請求量峰值達到了3.3w?qp
那按照這個量估計 33000 x 500 x 8 bps ≈ 125Gbps ?這個出口量級很難用單機房承載，峰值一來，出口網(wǎng)卡打滿，直接gg。
到寫這個回答時，西安健康碼還是沒有將靜態(tài)資源上CDN，之后看看訪問量再起飛的時候，能不能扛得住吧。
知乎鏈接：
https://www.zhihu.com/question/509914161/answer/2299099095
事情到這大家也都明白了吧，真不是之前網(wǎng)上傳的這么低級錯誤，但是相關技術團隊也確實有點業(yè)余。
所以，小伙伴你怎么看呢？歡迎評論區(qū)交流！
