<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          崩潰的一天,西安一碼通崩潰背后的技術(shù)問題

          共 3168字,需瀏覽 7分鐘

           ·

          2021-12-28 15:06


          導讀:希望這次能夠吸取教訓,避免再次出現(xiàn)類似的問題!


          作者 / 來源:純潔的微笑(ID:keeppuresmile)


          01?崩潰的一天

          12月20號,算得上西安崩潰的一天。

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

          西安防疫壓力巨大,各單位公司要求,需48小時核酸檢測報告上班。

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

          足足癱瘓超過 15+ 個小時!

          整整一天的時間呀,多少上班族被堵在地鐵口,多少旅客被凍在半路上,進退不能...

          到了下午,新聞甚至提示:

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

          這是解決問題的方法嗎?

          如果真的需要限流來防止系統(tǒng)崩潰,用技術(shù)手段來限流是不是會更簡單一些,甚至前面加一個 nginx 就能解決的問題。

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


          02?產(chǎn)品分析

          西安一碼通其它業(yè)務(wù)我們暫且不分析,那并不是重點,并且當天也沒有完全崩潰,崩潰的僅有掃碼功能。

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

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


          這是西安一碼通最開始的樣子,業(yè)務(wù)流程僅僅只需要一個請求,甚至一個查詢的 SQL 就可以搞定。

          到了后來,這個界面做了2次比較大的改版。

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


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

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

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

          那怎么就崩了呢?


          03?技術(shù)分析

          在當天晚上的官方回復中,我們看到有這樣一句話:

          12月20日早7:40分左右,西安“一碼通”用戶訪問量激增,每秒訪問量達到以往峰值的10倍以上,造成網(wǎng)絡(luò)擁塞,致使包括“一碼通”在內(nèi)的部分應(yīng)用系統(tǒng)無法正常使用。“

          一碼通”后臺監(jiān)控第一時間報警,各24小時駐場通信、網(wǎng)絡(luò)、政務(wù)云、安全和運維團隊立即開展排查,平臺應(yīng)用系統(tǒng)和數(shù)據(jù)庫運行正常,判斷問題出現(xiàn)在網(wǎng)絡(luò)接口側(cè)。

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

          我之前畫過一張訪問示意圖,用這個圖來和大家分析一下,網(wǎng)絡(luò)出現(xiàn)問題的情況。


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

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

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

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


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

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


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


          04?個人分析

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

          說人話就是,外部請求量超過了系統(tǒng)的最大處理能力。

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

          應(yīng)對這樣的問題,解決起來無非有兩個方案,一個是限流,另外一個就是擴容了。

          限流就是把用戶擋在外面,先處理能處理的請求;擴容就是加服務(wù)器、增加數(shù)據(jù)庫承載能力。

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

          技術(shù)上的限流方案有很多,但最簡單的就是前面掛一個 Nginx 配置一下就能用;復雜一點就是接入層自己寫算法。

          當然了限流不能真正的解決問題,只是負責把一部分請求擋在外面;真正解決問題還是需要擴容,滿足所有用戶。

          但實際上,根據(jù)解決問題的處理和產(chǎn)品回滾的情況來看,一碼通并沒有第一時間做擴容,而是選擇了回滾。

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


          05 理想的方案?

          上面說那么多也僅僅是個人推測,實際上可能他們會面臨更多現(xiàn)實問題,比如工期緊張、老板控制預(yù)算等等...

          話說回來,如果你是負責一碼通公司的架構(gòu)師,你會怎么設(shè)計整個技術(shù)方案呢?歡迎大家留言,這里說說我的想法。

          第一步,讀寫分離、緩存。

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

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

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

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

          其實用戶和用戶之間的單個查詢是沒有關(guān)系的,完全可以根據(jù)用戶的屬性做分庫分表。

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

          上面分析沒有及時擴容,可能就是沒有做服務(wù)拆分,如果都是單個的業(yè)務(wù)子服務(wù)的話,遇到過載的問題很容易做擴容。

          當然,如果條件合適的話,上微服務(wù)架構(gòu)就更好了,有一套解決方案來處理類似的問題。

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

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

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

          這樣處理的好處是,哪怕更新業(yè)務(wù)完全掛了,也不會影響用戶掃碼查詢,因為兩套系統(tǒng)、數(shù)據(jù)庫都是完全分開的。

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

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


          06?最后

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

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

          比西安大的城市很多,比西安現(xiàn)在疫情還要嚴重的情況,其它城市也遇到過,怎么沒有出現(xiàn)類似的問題?

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


          有一種無力吐槽的感覺,雖然說這和程序使用沒有關(guān)系,但是從細節(jié)真的可以看出一個技術(shù)團隊的實力。

          希望這次能夠吸取教訓,避免再次出現(xiàn)類似的問題!


          延伸閱讀??

          延伸閱讀《架構(gòu)師的自我修煉

          干貨直達??



          更多精彩??

          在公眾號對話框輸入以下關(guān)鍵詞
          查看更多優(yōu)質(zhì)內(nèi)容!

          讀書?|?書單?|?干貨?|?講明白?|?神操作?|?手把手
          大數(shù)據(jù)?|?云計算?|?數(shù)據(jù)庫?|?Python?|?爬蟲?|?可視化
          AI?|?人工智能?|?機器學習?|?深度學習?|?NLP
          5G?|?中臺?|?用戶畫像?|?數(shù)學?|?算法?|?數(shù)字孿生

          據(jù)統(tǒng)計,99%的大咖都關(guān)注了這個公眾號
          ??
          瀏覽 24
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  欧美成人一级在线 | 三级片网站在线观看 | 精品人妻一区二区三区视频在线 | 国产精品噜噜 | 91亚洲国产成人久久精品麻豆 |