西安健康碼崩了！隨便聊聊

事件描述

事情大致是這樣的，去年 12 月 20 日和今年的 1 月 4 日，短短兩周內(nèi)，西安一碼通程序崩了兩次，導(dǎo)致市民無法掃碼亮碼，只能在寒風(fēng)中排隊等候。

官方的解釋是：短期用戶訪問量激增，大概是正常訪問量的 10 倍以上，導(dǎo)致網(wǎng)絡(luò)阻塞、系統(tǒng)崩潰。

于是，名場面來了：

“時任西安市大數(shù)據(jù)局局長劉軍參加發(fā)布會并回應(yīng)稱，西安市一碼通使用頻率加大，對網(wǎng)絡(luò)與平臺造成較大壓力，在全員核酸檢測的特殊時期，為減輕系統(tǒng)壓力，建議廣大市民 非必要不展碼、亮碼 ，在出現(xiàn)系統(tǒng)卡頓時，請耐心等待， 盡量避免反復(fù)刷新 。”

雖然聽上去挺合理的，但總感覺哪里不太對勁。。。

人類為一個小系統(tǒng)讓步？上千萬人為幾個搞系統(tǒng)的小團隊讓步？真就 “非必要時不亮碼，必要時碼不亮” 了。

據(jù)說后來，該局長被停職檢查。。。

總之，在疫情形勢不容樂觀的情況下，這個事故的嚴(yán)重程度可以說是 P0 級了。

技術(shù)分析

那么事情是否真的如官方所說，是由于網(wǎng)絡(luò)阻塞導(dǎo)致的系統(tǒng)崩潰呢？

先說說什么是網(wǎng)絡(luò)阻塞。打個比方，把用戶的訪問流量想象成往小水管中注水，如果流量突然激增，出水口太小來不及排水，水就流不動了。

怎么解決網(wǎng)絡(luò)阻塞呢？一種最常見的方案是對網(wǎng)絡(luò)進(jìn)行 擴容 。

提到擴容，最簡單粗暴的方式是，換個粗水管，就能應(yīng)對更大的突發(fā)流量。但如果平時流量用小水管就能應(yīng)對，這樣改造就會很浪費資源。

除了這種方式外，其實有非常多優(yōu)秀的擴容方案。比如之前看過美團的一個分享，在某業(yè)務(wù)訪問的高峰期（比如中午 12 點的外賣系統(tǒng)），系統(tǒng)會自動協(xié)調(diào)其他非高峰期業(yè)務(wù)的部分資源給該業(yè)務(wù)，從而保證總資源有限的情況下，順利扛過流量高峰。

所以，如果健康碼第一次的崩潰是因為網(wǎng)絡(luò)阻塞，按道理來說除了這么大的事故肯定會吸取教訓(xùn)，對網(wǎng)絡(luò)進(jìn)行 擴容 等措施的，如果做了擴容，第二次的崩潰就不應(yīng)該再甩鍋給網(wǎng)絡(luò)了。但現(xiàn)實恰恰相反，第二次崩潰依然宣稱是網(wǎng)絡(luò)阻塞，那我肯定是不信了。

而且有了第一次的經(jīng)驗，第二次又遇到了同樣的網(wǎng)絡(luò)阻塞問題，真的要修復(fù)好幾個小時么？

此外，事故發(fā)生之后，程序明顯發(fā)生了 回滾 ，界面恢復(fù)成了幾個月前的樣子！

說到回滾，我就來勁了，這種事我干的太多了，大多數(shù)情況下，都是寫了 Bug 影響到線上項目了，才會做這個操作。

所以我猜測一碼通的崩潰，肯定和系統(tǒng)之爛脫不開關(guān)系。既然官方稱數(shù)據(jù)庫還能正常運行，那么大概率是業(yè)務(wù)層代碼自身出了問題。

比如本來頁面很簡潔，只需要從服務(wù)器查詢健康碼信息（根據(jù)用戶 N 天內(nèi)的行為進(jìn)行綜合計算而成），而一碼通新版本又多了核酸檢測情況等一些額外的信息查詢，所以就增加了單次數(shù)據(jù)庫查詢的耗時，占用數(shù)據(jù)庫連接更久、釋放得更晚。請求很多的情況下，數(shù)據(jù)庫連接很快就被占滿了，導(dǎo)致新的請求都要一直排隊等待可用的數(shù)據(jù)庫連接，直到等待超時。

舉個例子，本來食堂提供兩菜一湯，大家排隊去食堂打飯，每個人要花 20 秒。后來食堂突然提供了烤腰子，大家又要多打一道菜，比原來多花 10 秒，隊伍移動慢了，就導(dǎo)致后面的隊越排越長，直到把食堂堵死。

當(dāng)然，也有可能是數(shù)據(jù)庫里又多了大量數(shù)據(jù)，導(dǎo)致查詢時間變長。打個比方就是食堂提供了更多菜品，大家挑選的時間更久了。

要解決這個問題，就要定位請求究竟在哪個環(huán)節(jié)等待，是數(shù)據(jù)庫連接池的最大連接數(shù)不足、還是數(shù)據(jù)庫本身的最大連接數(shù)不足等。常見的手段就是調(diào)整連接數(shù)參數(shù)、或者對應(yīng)用進(jìn)行擴容。

當(dāng)然這只是我的猜測~

尾聲

最后，我從網(wǎng)上了解到，大部分區(qū)域的一碼通，其實都是由騰訊和阿里免費提供的。但西安不一樣，它的一碼通，是由當(dāng)?shù)卣块T招標(biāo)搭建的，而且還是在三天內(nèi)研發(fā)出來的！

因此，我覺得這次事故需要背鍋的人和團隊真的太多了，下到寫 Bug 的開發(fā)者、設(shè)計系統(tǒng)的架構(gòu)師、保障系統(tǒng)的運維同學(xué)，上到各公司和政府部門的領(lǐng)導(dǎo)決策者等等。西安不像其他省份一樣用全國統(tǒng)一、相對更穩(wěn)定的健康碼也就算了（本地數(shù)據(jù)管理方便些），但究竟是誰給了你們勇氣不對 僅花三天就上線 、上千萬人使用 的系統(tǒng)進(jìn)行壓力測試和容災(zāi)演練的？

雖然我不是這件事的受害者，不過光是讓我想像一下這么多人大冬天里排隊等系統(tǒng)修復(fù)的場景，我就真的是很氣憤了！

當(dāng)然，如果這件事情真的是天災(zāi)，就當(dāng)我在扯犢子吧。

大概是這樣，就隨便聊聊，希望以后自己設(shè)計系統(tǒng)時能長點心，盡量不要因為自己的失誤影響到其他人。

共勉！