亚洲中文字幕无码日韩精品,亚洲一区制服无码中字,亚洲精品第一国产综合精品99 ,一本大道中文日本香蕉

1

崩潰的一天

12月20號(hào)，算得上西安崩潰的一天。

12月19號(hào)新增病例21個(gè)，20號(hào)新增病例42個(gè)，并且有部分病例已經(jīng)在社區(qū)內(nèi)傳播...

西安防疫壓力巨大，各單位公司要求，需48小時(shí)核酸檢測(cè)報(bào)告上班。

在這樣嚴(yán)峻的情況下，作為防控最核心的系統(tǒng)：西安一碼通竟然崩潰了，并且崩潰得是那么的徹底。

足足癱瘓超過(guò) 15+ 個(gè)小時(shí)！

整整一天的時(shí)間呀，多少上班族被堵在地鐵口，多少旅客被凍在半路上，進(jìn)退不能...

到了下午，新聞甚至提示：

為了減輕系統(tǒng)壓力，建議廣大市民非必要不展碼、亮碼，在出現(xiàn)系統(tǒng)卡頓時(shí)，請(qǐng)耐心等待，盡量避免反復(fù)刷新，也感謝廣大市民朋友們的理解配合。

這是解決問(wèn)題的方法嗎？

如果真的需要限流來(lái)防止系統(tǒng)崩潰，用技術(shù)手段來(lái)限流是不是會(huì)更簡(jiǎn)單一些，甚至前面加一個(gè) nginx 就能解決的問(wèn)題。

今天，我們就試著分析一下這個(gè)業(yè)務(wù)、以及對(duì)應(yīng)的技術(shù)問(wèn)題。

2

產(chǎn)品分析

西安一碼通其它業(yè)務(wù)我們暫且不分析，那并不是重點(diǎn)，并且當(dāng)天也沒(méi)有完全崩潰，崩潰的僅有掃碼功能。

其實(shí)這是一個(gè)非常典型的大量查詢(xún)、少數(shù)更新的業(yè)務(wù)，閉著眼睛分析一下，可以說(shuō)， 90% 以上的流量都是查詢(xún)。

我們先來(lái)看看第一版的產(chǎn)品形態(tài)，掃碼之后展示個(gè)人部分姓名和身份證信息，同時(shí)下面展示綠、黃、紅碼。

這是西安一碼通最開(kāi)始的樣子，業(yè)務(wù)流程僅僅只需要一個(gè)請(qǐng)求，甚至一個(gè)查詢(xún)的 SQL 就可以搞定。

到了后來(lái)，這個(gè)界面做了2次比較大的改版。

第一次改版新增了疫苗接種信息，加了一個(gè)邊框；第二次改版新增了核酸檢測(cè)信息，在最下方展示核酸檢測(cè)時(shí)間、結(jié)果。

整個(gè)頁(yè)面增加了2個(gè)查詢(xún)業(yè)務(wù)，如果系統(tǒng)背后使用的是關(guān)系數(shù)據(jù)庫(kù)，可能會(huì)多增加至少2個(gè)查詢(xún)SQL。

基本上就是這樣的一個(gè)需求，據(jù)統(tǒng)計(jì)西安有1300萬(wàn)人口，按照最大10%的市民同時(shí)掃碼（我懷疑不會(huì)有這么多），也就是百萬(wàn)的并發(fā)量。

這樣一個(gè)并發(fā)量的業(yè)務(wù)，在互聯(lián)網(wǎng)公司很常見(jiàn)，甚至比這個(gè)復(fù)雜的場(chǎng)景也多了去了。

那怎么就崩了呢？

3

技術(shù)分析

在當(dāng)天晚上的官方回復(fù)中，我們看到有這樣一句話(huà)：

12月20日早7:40分左右，西安“一碼通”用戶(hù)訪(fǎng)問(wèn)量激增，每秒訪(fǎng)問(wèn)量達(dá)到以往峰值的10倍以上，造成網(wǎng)絡(luò)擁塞，致使包括“一碼通”在內(nèi)的部分應(yīng)用系統(tǒng)無(wú)法正常使用?！?br /> 一碼通”后臺(tái)監(jiān)控第一時(shí)間報(bào)警，各24小時(shí)駐場(chǎng)通信、網(wǎng)絡(luò)、政務(wù)云、安全和運(yùn)維團(tuán)隊(duì)立即開(kāi)展排查，平臺(tái)應(yīng)用系統(tǒng)和數(shù)據(jù)庫(kù)運(yùn)行正常，判斷問(wèn)題出現(xiàn)在網(wǎng)絡(luò)接口側(cè)。

根據(jù)上面的信息，數(shù)據(jù)庫(kù)和平臺(tái)系統(tǒng)都正常，是網(wǎng)絡(luò)出現(xiàn)了問(wèn)題。

我之前在文章《一次dns緩存引發(fā)的慘案》畫(huà)過(guò)一張?jiān)L問(wèn)示意圖，用這個(gè)圖來(lái)和大家分析一下，網(wǎng)絡(luò)出現(xiàn)問(wèn)題的情況。

一般用戶(hù)的請(qǐng)求，會(huì)先從域名開(kāi)始，經(jīng)過(guò)DNS服務(wù)器解析后拿到外網(wǎng)IP地址，經(jīng)過(guò)外網(wǎng)IP訪(fǎng)問(wèn)防火墻和負(fù)載之后打到服務(wù)器，最后服務(wù)器響應(yīng)后將結(jié)果返回到瀏覽器。

如果真的是網(wǎng)絡(luò)出現(xiàn)問(wèn)題，一般最常見(jiàn)的問(wèn)題就是 DNS 解析錯(cuò)誤，或者外網(wǎng)的寬帶被打滿(mǎn)了。

DNS解析錯(cuò)誤一定不是本次的問(wèn)題，不然可能不只是這一個(gè)功能出錯(cuò)了；外網(wǎng)的寬帶被打滿(mǎn)，直接增加帶寬就行，不至于一天都沒(méi)搞定。

如果真的是網(wǎng)絡(luò)側(cè)出現(xiàn)問(wèn)題，一般也不需要改動(dòng)業(yè)務(wù)，但實(shí)際上系統(tǒng)恢復(fù)的時(shí)候，大家都發(fā)現(xiàn)界面回到文章開(kāi)頭提到了第一個(gè)版本了。

也就是說(shuō)系統(tǒng)“回滾”了。

界面少了接種信息和核酸檢測(cè)信息的內(nèi)容，并且在一碼通的首頁(yè)位置，新增加了一個(gè)核酸查詢(xún)的頁(yè)面。

所以，僅僅是網(wǎng)絡(luò)接口側(cè)出現(xiàn)問(wèn)題嗎？我這里有一點(diǎn)點(diǎn)的疑問(wèn)。

4

個(gè)人分析

根據(jù)我以往的經(jīng)驗(yàn)，這是一個(gè)很典型的系統(tǒng)過(guò)載現(xiàn)象，也就是說(shuō)短期內(nèi)請(qǐng)求量超過(guò)服務(wù)器響應(yīng)。

說(shuō)人話(huà)就是，外部請(qǐng)求量超過(guò)了系統(tǒng)的最大處理能力。

當(dāng)然了，系統(tǒng)最大處理能力和系統(tǒng)架構(gòu)息息相關(guān)，同樣的服務(wù)器不同的架構(gòu)，系統(tǒng)負(fù)載量差異極大。

應(yīng)對(duì)這樣的問(wèn)題，解決起來(lái)無(wú)非有兩個(gè)方案，一個(gè)是限流，另外一個(gè)就是擴(kuò)容了。

限流就是把用戶(hù)擋在外面，先處理能處理的請(qǐng)求；擴(kuò)容就是加服務(wù)器、增加數(shù)據(jù)庫(kù)承載能力。

上面提到官方讓大家沒(méi)事別刷一碼通，也算是人工限流的一種方式；不過(guò)在技術(shù)體系上基本上不會(huì)這樣做。

技術(shù)上的限流方案有很多，但最簡(jiǎn)單的就是前面掛一個(gè) Nginx 配置一下就能用；復(fù)雜一點(diǎn)就是接入層自己寫(xiě)算法。

當(dāng)然了限流不能真正的解決問(wèn)題，只是負(fù)責(zé)把一部分請(qǐng)求擋在外面；真正解決問(wèn)題還是需要擴(kuò)容，滿(mǎn)足所有用戶(hù)。

但實(shí)際上，根據(jù)解決問(wèn)題的處理和產(chǎn)品回滾的情況來(lái)看，一碼通并沒(méi)有第一時(shí)間做擴(kuò)容，而是選擇了回滾。

這說(shuō)明，在系統(tǒng)架構(gòu)設(shè)計(jì)上，沒(méi)有充分考慮擴(kuò)容的情況，所以并不能支持第一時(shí)間選擇這個(gè)方案。

5

理想的方案？

上面說(shuō)那么多也僅僅是個(gè)人推測(cè)，實(shí)際上可能他們會(huì)面臨更多現(xiàn)實(shí)問(wèn)題，比如工期緊張、老板控制預(yù)算等等...

話(huà)說(shuō)回來(lái)，如果你是負(fù)責(zé)一碼通公司的架構(gòu)師，你會(huì)怎么設(shè)計(jì)整個(gè)技術(shù)方案呢？歡迎大家留言，這里說(shuō)說(shuō)我的想法。

第一步，讀寫(xiě)分離、緩存。

至少把系統(tǒng)分為2大塊，滿(mǎn)足日常使用的讀業(yè)務(wù)單獨(dú)抽取出來(lái)，用于承接外部的最大流量。

單獨(dú)抽出一個(gè)子系統(tǒng)負(fù)責(zé)業(yè)務(wù)的更新，比如接種信息的更新、核酸信息的變化、或者根據(jù)業(yè)務(wù)定時(shí)變更碼的顏色。

同時(shí)針對(duì)用戶(hù)大量的單查詢(xún)，上緩存系統(tǒng)，優(yōu)先讀取緩存系統(tǒng)的信息，防止壓垮后面的數(shù)據(jù)庫(kù)。

第二步，分庫(kù)分表、服務(wù)拆分。

其實(shí)用戶(hù)和用戶(hù)之間的單個(gè)查詢(xún)是沒(méi)有關(guān)系的，完全可以根據(jù)用戶(hù)的屬性做分庫(kù)分表。

比如就用用戶(hù)ID取模分64個(gè)表，甚至可以分成64個(gè)子系統(tǒng)來(lái)查詢(xún)，在接口最前端將流量分發(fā)掉，減輕單個(gè)表或者服務(wù)壓力。

上面分析沒(méi)有及時(shí)擴(kuò)容，可能就是沒(méi)有做服務(wù)拆分，如果都是單個(gè)的業(yè)務(wù)子服務(wù)的話(huà)，遇到過(guò)載的問(wèn)題很容易做擴(kuò)容。

當(dāng)然，如果條件合適的話(huà)，上微服務(wù)架構(gòu)就更好了，有一套解決方案來(lái)處理類(lèi)似的問(wèn)題。

第三步，大數(shù)據(jù)系統(tǒng)、容災(zāi)。

如果在一個(gè)頁(yè)面中展示很多信息，還有一個(gè)技術(shù)方案，就是通過(guò)異步的數(shù)據(jù)清洗，整合到 nosql 的一張大表中。

用戶(hù)掃描查詢(xún)等相關(guān)業(yè)務(wù)，直接走 nosql 數(shù)據(jù)庫(kù)即可。

這樣處理的好處是，哪怕更新業(yè)務(wù)完全掛了，也不會(huì)影響用戶(hù)掃碼查詢(xún)，因?yàn)閮商紫到y(tǒng)、數(shù)據(jù)庫(kù)都是完全分開(kāi)的。

使用異地雙機(jī)房等形式部署服務(wù)，同時(shí)做好整體的容災(zāi)、備災(zāi)方案，避免出現(xiàn)極端情況，比如機(jī)房光纜挖斷等。

還有很多細(xì)節(jié)上的優(yōu)化，這里就不一一說(shuō)明了，這里也只是我的一些想法，歡迎大家留言補(bǔ)充。

6

最后

不管怎么分析，這肯定是人禍而不是天災(zāi)。

系統(tǒng)在沒(méi)有經(jīng)過(guò)嚴(yán)格測(cè)試之下，就直接投入到生產(chǎn)，在強(qiáng)度稍微大一點(diǎn)的環(huán)境中就崩潰了。

比西安大的城市很多，比西安現(xiàn)在疫情還要嚴(yán)重的情況，其它城市也遇到過(guò)，怎么沒(méi)有出現(xiàn)類(lèi)似的問(wèn)題？

西安做為一個(gè)科技大省，出現(xiàn)這樣的問(wèn)題真的不應(yīng)該，特別是我看了這個(gè)小程序背后使用的域名地址之后。

有一種無(wú)力吐槽的感覺(jué)，雖然說(shuō)這和程序使用沒(méi)有關(guān)系，但是從細(xì)節(jié)真的可以看出一個(gè)技術(shù)團(tuán)隊(duì)的實(shí)力。

希望這次能夠吸取教訓(xùn)，避免再次出現(xiàn)類(lèi)似的問(wèn)題！


作者：純潔的微笑
鏈接：https://www.zhihu.com/question/507219287/answer/2281316548
來(lái)源：知乎
著作權(quán)歸作者所有。