業(yè)務(wù)專線：15989169178
這兩天，因為西安一碼通的二次崩潰，幾乎每個技術(shù)群里都在吐槽和猜測。
網(wǎng)上一直在說崩潰是因為后臺傳輸?shù)氖菆D片？
第一次看到這個消息的時候，小編是抱有懷疑態(tài)度的。畢竟大家都知道這種大的政府項目都是要招標(biāo)的，我曾經(jīng)參見過很多次的競標(biāo)，能去競標(biāo)的公司都不是很小的公司，因此技術(shù)實力也不是一般小公司的水平。
作為程序員來說，怎么會出現(xiàn)這么低級的錯誤呢？不管是開發(fā)還是測試，應(yīng)該認真負責(zé)自己經(jīng)手的產(chǎn)品。
網(wǎng)上有很多大神對問題進行了分析。
知乎上也開了個貼討論：一碼通崩潰的技術(shù)原因是什么？
原帖地址：https://www.zhihu.com/question/509914161，有興趣的小伙伴可以自行前往。
其中最熱回復(fù)如下：
注意這里一個細節(jié)！答主跟大部分人一樣，開始以為是服務(wù)器負載太大，但之后又轉(zhuǎn)到了圖片優(yōu)化上的猜測。這里提到了一篇陜西電信的文章。
于是小編去找了一下，還真有一篇名為《“科技抗疫”中流砥柱：西安電信“一碼通”平臺服務(wù)保障專班》的報道，地址：https://m.thepaper.cn/baijiahao_13083245
里面有這樣一段話被網(wǎng)友們抓了出來：
上面這段話中的紅色部分，就是該答主所指問題所在！
這篇洋洋灑灑近2000字的"美文"，就這一小段與技術(shù)沾點邊，所以確實極有可能就是當(dāng)時該系統(tǒng)開發(fā)時面臨的最難攻克點。而這樣的實現(xiàn)方式，也確實并不是一個好的選擇！當(dāng)然這也都是猜測，具體怎么樣我們也不知道。
往后翻了下，在知乎上看到了知友 “盧興民” 的回答，別人是真的去分析了二維碼接口數(shù)據(jù)的，證明并不是在服務(wù)器生成圖片。
西安健康碼的接口數(shù)據(jù)
真正的二維碼數(shù)據(jù)是 /person/app/refreshQRCode這個接口
這位知友表示：
看下這個接口返回，設(shè)計上也沒有太大的問題。
主要問題集中在所有的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)上傳的這么低級錯誤，但是相關(guān)技術(shù)團隊也確實有點業(yè)余。
你覺得這次西安一碼通再次崩潰的技術(shù)原因是什么呢？
轉(zhuǎn)自公眾號：程序員大咖
