西安一碼通又崩了！難道又不小心回滾上個(gè)版本了？
1
又崩了
對(duì)，西安一碼通又一次，崩了！
有人諷刺說，西安掌握了流量密碼，天天可以上熱搜，我剛?cè)タ戳艘幌拢靼惨淮a通已經(jīng)上微博熱搜了。
然后微博上一片XX聲，突然就看到了這句：我們（西安）每天都生活在，全國人民的笑話中。
說實(shí)話曾經(jīng)網(wǎng)上看到別人黑西安，立刻有一種想要反駁的沖動(dòng)，但這一次我自己都破防了。
甚至有一瞬間，我覺得他們說的都對(duì)。
西安和一線城市的差距，真的是全方位的（如果大家看了最近的新聞），一碼通崩潰，只是拉開遮羞布的一角罷了。
12月20號(hào)，算得上西安崩潰的一天。
那么今天1月4號(hào)，就是上西安市民的又又一次崩潰。
1月4號(hào)是上面定的清零日期，也就說今天在社區(qū)內(nèi)要做到無任何感染，要有病例也是在隔離區(qū)。
為此西安做了很多巨大的工作，包括免費(fèi)送菜、整棟整棟的拉出去隔離。
這個(gè)又一次關(guān)鍵時(shí)刻，在中央的領(lǐng)導(dǎo)下，西安正在打攻堅(jiān)戰(zhàn)的時(shí)候，西安一碼通又又一次崩潰了。。。
第一次出現(xiàn)問題，修復(fù)了整整一天，那么這次呢？同樣的問題過去了十幾天仍然再次出現(xiàn)了?。?！
今天小區(qū)8點(diǎn)，西安市通知開始又一輪全市核酸檢測(cè)，于是各個(gè)小區(qū)開始讓大家排隊(duì)做核酸。
結(jié)果很多小區(qū)都沒開始做的時(shí)候，大家突然發(fā)現(xiàn)一碼通打不開了，大家可要知道西安市現(xiàn)在的溫度是1度，大家排隊(duì)在外面的感受。
最諷刺的是，大家都還在排隊(duì)的過程中，收到了市里面發(fā)過來的短信，而一碼通仍然處于崩潰中。
剛開始還讓等待，結(jié)果等了30分鐘之后，發(fā)現(xiàn)仍然沒有一點(diǎn)恢復(fù)的跡象，于是通知大家回家等待。
因?yàn)榉雷o(hù)服穿上就不能脫，到現(xiàn)在還有很多醫(yī)護(hù)人員和一線的志愿者，穿著防護(hù)服在寒風(fēng)中等著系統(tǒng)恢復(fù)。
西安現(xiàn)在防疫壓力有多大，我這里不需要再復(fù)述了，嚴(yán)重程度僅次于當(dāng)年的武漢。
關(guān)鍵是這個(gè)問題有那么難嗎？
關(guān)鍵時(shí)刻、關(guān)系到國計(jì)民生的事情，如果負(fù)責(zé)的技術(shù)團(tuán)隊(duì)解決不了，能不能請(qǐng)求一下 BAT 的專家過來幫忙支援。
到現(xiàn)在這個(gè)程度，已經(jīng)不是錢的問題了，嚴(yán)重影響整個(gè)西安防控的進(jìn)展了。
吐槽歸吐槽，估計(jì)一碼通的程序員，現(xiàn)在壓力巨大，希望他們可以沉下心來盡快將問題解決吧。
這個(gè)級(jí)別的問題和干活的程序員關(guān)系不大，主要的責(zé)任人都在負(fù)責(zé)的相關(guān)領(lǐng)導(dǎo)身上。
希望相關(guān)領(lǐng)導(dǎo)負(fù)起責(zé)任來，將類似的問題一次性解決好，西安真的已經(jīng)經(jīng)不起再次再次的折騰了。。。
下面這篇文章是我在12月20號(hào)，一碼通崩潰的時(shí)候?qū)懙?/span>，只能從局外人給出一些淺薄的見解。
我真的沒想到，這么快曾經(jīng)寫的這篇文章，就可以再發(fā)第二遍，希望不要發(fā)第三遍。。。
2
產(chǎn)品分析
西安一碼通其它業(yè)務(wù)我們暫且不分析，那并不是重點(diǎn)，并且當(dāng)天也沒有完全崩潰，崩潰的僅有掃碼功能。
其實(shí)這是一個(gè)非常典型的大量查詢、少數(shù)更新的業(yè)務(wù)，閉著眼睛分析一下，可以說， 90% 以上的流量都是查詢。
我們先來看看第一版的產(chǎn)品形態(tài)，掃碼之后展示個(gè)人部分姓名和身份證信息，同時(shí)下面展示綠、黃、紅碼。
這是西安一碼通最開始的樣子，業(yè)務(wù)流程僅僅只需要一個(gè)請(qǐng)求，甚至一個(gè)查詢的 SQL 就可以搞定。
到了后來，這個(gè)界面做了2次比較大的改版。
第一次改版新增了疫苗接種信息，加了一個(gè)邊框；第二次改版新增了核酸檢測(cè)信息，在最下方展示核酸檢測(cè)時(shí)間、結(jié)果。
整個(gè)頁面增加了2個(gè)查詢業(yè)務(wù)，如果系統(tǒng)背后使用的是關(guān)系數(shù)據(jù)庫，可能會(huì)多增加至少2個(gè)查詢SQL。
基本上就是這樣的一個(gè)需求，據(jù)統(tǒng)計(jì)西安有1300萬人口，按照最大10%的市民同時(shí)掃碼（我懷疑不會(huì)有這么多），也就是百萬的并發(fā)量。
這樣一個(gè)并發(fā)量的業(yè)務(wù)，在互聯(lián)網(wǎng)公司很常見，甚至比這個(gè)復(fù)雜的場(chǎng)景也多了去了。
那怎么就崩了呢？
3
技術(shù)分析
在當(dāng)天晚上的官方回復(fù)中，我們看到有這樣一句話：
12月20日早7:40分左右，西安“一碼通”用戶訪問量激增，每秒訪問量達(dá)到以往峰值的10倍以上，造成網(wǎng)絡(luò)擁塞，致使包括“一碼通”在內(nèi)的部分應(yīng)用系統(tǒng)無法正常使用。“
一碼通”后臺(tái)監(jiān)控第一時(shí)間報(bào)警，各24小時(shí)駐場(chǎng)通信、網(wǎng)絡(luò)、政務(wù)云、安全和運(yùn)維團(tuán)隊(duì)立即開展排查，平臺(tái)應(yīng)用系統(tǒng)和數(shù)據(jù)庫運(yùn)行正常，判斷問題出現(xiàn)在網(wǎng)絡(luò)接口側(cè)。
根據(jù)上面的信息，數(shù)據(jù)庫和平臺(tái)系統(tǒng)都正常，是網(wǎng)絡(luò)出現(xiàn)了問題。
我之前在文章《一次dns緩存引發(fā)的慘案》畫過一張?jiān)L問示意圖，用這個(gè)圖來和大家分析一下，網(wǎng)絡(luò)出現(xiàn)問題的情況。
一般用戶的請(qǐng)求，會(huì)先從域名開始，經(jīng)過DNS服務(wù)器解析后拿到外網(wǎng)IP地址，經(jīng)過外網(wǎng)IP訪問防火墻和負(fù)載之后打到服務(wù)器，最后服務(wù)器響應(yīng)后將結(jié)果返回到瀏覽器。
如果真的是網(wǎng)絡(luò)出現(xiàn)問題，一般最常見的問題就是 DNS 解析錯(cuò)誤，或者外網(wǎng)的寬帶被打滿了。
DNS解析錯(cuò)誤一定不是本次的問題，不然可能不只是這一個(gè)功能出錯(cuò)了；外網(wǎng)的寬帶被打滿，直接增加帶寬就行，不至于一天都沒搞定。
如果真的是網(wǎng)絡(luò)側(cè)出現(xiàn)問題，一般也不需要改動(dòng)業(yè)務(wù)，但實(shí)際上系統(tǒng)恢復(fù)的時(shí)候，大家都發(fā)現(xiàn)界面回到文章開頭提到了第一個(gè)版本了。
也就是說系統(tǒng)“回滾”了。
界面少了接種信息和核酸檢測(cè)信息的內(nèi)容，并且在一碼通的首頁位置，新增加了一個(gè)核酸查詢的頁面。
4
個(gè)人分析
根據(jù)我以往的經(jīng)驗(yàn)，這是一個(gè)很典型的系統(tǒng)過載現(xiàn)象，也就是說短期內(nèi)請(qǐng)求量超過服務(wù)器響應(yīng)。
說人話就是，外部請(qǐng)求量超過了系統(tǒng)的最大處理能力。
當(dāng)然了，系統(tǒng)最大處理能力和系統(tǒng)架構(gòu)息息相關(guān)，同樣的服務(wù)器不同的架構(gòu)，系統(tǒng)負(fù)載量差異極大。
應(yīng)對(duì)這樣的問題，解決起來無非有兩個(gè)方案，一個(gè)是限流，另外一個(gè)就是擴(kuò)容了。
限流就是把用戶擋在外面，先處理能處理的請(qǐng)求；擴(kuò)容就是加服務(wù)器、增加數(shù)據(jù)庫承載能力。
上面提到官方讓大家沒事別刷一碼通，也算是人工限流的一種方式；不過在技術(shù)體系上基本上不會(huì)這樣做。
技術(shù)上的限流方案有很多，但最簡(jiǎn)單的就是前面掛一個(gè) Nginx 配置一下就能用；復(fù)雜一點(diǎn)就是接入層自己寫算法。
當(dāng)然了限流不能真正的解決問題，只是負(fù)責(zé)把一部分請(qǐng)求擋在外面；真正解決問題還是需要擴(kuò)容，滿足所有用戶。
但實(shí)際上，根據(jù)解決問題的處理和產(chǎn)品回滾的情況來看，一碼通并沒有第一時(shí)間做擴(kuò)容，而是選擇了回滾。
這說明，在系統(tǒng)架構(gòu)設(shè)計(jì)上，沒有充分考慮擴(kuò)容的情況，所以并不能支持第一時(shí)間選擇這個(gè)方案。
5
理想的方案？
上面說那么多也僅僅是個(gè)人推測(cè)，實(shí)際上可能他們會(huì)面臨更多現(xiàn)實(shí)問題，比如工期緊張、老板控制預(yù)算等等...
話說回來，如果你是負(fù)責(zé)一碼通公司的架構(gòu)師，你會(huì)怎么設(shè)計(jì)整個(gè)技術(shù)方案呢？歡迎大家留言，這里說說我的想法。
第一步，讀寫分離、緩存。
至少把系統(tǒng)分為2大塊，滿足日常使用的讀業(yè)務(wù)單獨(dú)抽取出來，用于承接外部的最大流量。
單獨(dú)抽出一個(gè)子系統(tǒng)負(fù)責(zé)業(yè)務(wù)的更新，比如接種信息的更新、核酸信息的變化、或者根據(jù)業(yè)務(wù)定時(shí)變更碼的顏色。
同時(shí)針對(duì)用戶大量的單查詢，上緩存系統(tǒng)，優(yōu)先讀取緩存系統(tǒng)的信息，防止壓垮后面的數(shù)據(jù)庫。
第二步，分庫分表、服務(wù)拆分。
其實(shí)用戶和用戶之間的單個(gè)查詢是沒有關(guān)系的，完全可以根據(jù)用戶的屬性做分庫分表。
比如就用用戶ID取模分64個(gè)表，甚至可以分成64個(gè)子系統(tǒng)來查詢，在接口最前端將流量分發(fā)掉，減輕單個(gè)表或者服務(wù)壓力。
上面分析沒有及時(shí)擴(kuò)容，可能就是沒有做服務(wù)拆分，如果都是單個(gè)的業(yè)務(wù)子服務(wù)的話，遇到過載的問題很容易做擴(kuò)容。
當(dāng)然，如果條件合適的話，上微服務(wù)架構(gòu)就更好了，有一套解決方案來處理類似的問題。
第三步，大數(shù)據(jù)系統(tǒng)、容災(zāi)。
如果在一個(gè)頁面中展示很多信息，還有一個(gè)技術(shù)方案，就是通過異步的數(shù)據(jù)清洗，整合到 nosql 的一張大表中。
用戶掃描查詢等相關(guān)業(yè)務(wù)，直接走 nosql 數(shù)據(jù)庫即可。
這樣處理的好處是，哪怕更新業(yè)務(wù)完全掛了，也不會(huì)影響用戶掃碼查詢，因?yàn)閮商紫到y(tǒng)、數(shù)據(jù)庫都是完全分開的。
使用異地雙機(jī)房等形式部署服務(wù)，同時(shí)做好整體的容災(zāi)、備災(zāi)方案，避免出現(xiàn)極端情況，比如機(jī)房光纜挖斷等。
還有很多細(xì)節(jié)上的優(yōu)化，這里就不一一說明了，這里也只是我的一些想法，歡迎大家留言補(bǔ)充。
6
最后
不管怎么分析，這肯定是人禍而不是天災(zāi)。
系統(tǒng)在沒有經(jīng)過嚴(yán)格測(cè)試之下，就直接投入到生產(chǎn)，在強(qiáng)度稍微大一點(diǎn)的環(huán)境中就崩潰了。
比西安大的城市很多，比西安現(xiàn)在疫情還要嚴(yán)重的情況，其它城市也遇到過，怎么沒有出現(xiàn)類似的問題？
西安做為一個(gè)科技大城，出現(xiàn)這樣的問題真的不應(yīng)該，特別是我看了這個(gè)小程序背后使用的域名地址之后。
有一種無力吐槽的感覺，雖然說這和程序使用沒有關(guān)系，但是從細(xì)節(jié)真的可以看出一個(gè)技術(shù)團(tuán)隊(duì)的實(shí)力。
雖然大家都不容易，但還是希望這次能夠吸取教訓(xùn)，避免再次出現(xiàn)類似的問題！
西安，長(zhǎng)安，加油！
希望疫情盡快結(jié)束！大家早日恢復(fù)到正常的生活來。
< END >
沒有什么使我停留——除了目的，縱然岸旁有玫瑰、有綠蔭、有寧靜的港灣，我是不系之舟。
推薦閱讀：