建站
咨詢
售后
建站咨詢
新聞中心
作為9月2日成都核酸檢測的親歷者， 也跟所有的成都市民一樣，經歷了核酸系統(tǒng)崩潰之后的排隊崩潰和心理崩潰。
西藏網站制作公司哪家好，找創(chuàng)新互聯(lián)！從網頁設計、網站建設、微信開發(fā)、APP開發(fā)、響應式網站開發(fā)等網站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)公司2013年成立到現(xiàn)在10年的時間，我們擁有了豐富的建站經驗和運維經驗，來保證我們的工作的順利進行。專注于網站建設就選創(chuàng)新互聯(lián)。
昨天，在至少排了一個小時的隊之后，前面還沒有動靜。我跑到志愿者掃碼登記的地方觀察了很久，也看了網上各種各樣的分析，聲音很多。
作為一個程序猿，也來說說我的看法
在發(fā)出這個內容之前，我看到 東軟已經發(fā)出了聲明 ，概括起來主要是這樣：第一次崩潰是成都政府的系統(tǒng)不行，第二次則是因為網絡不行?？偠灾?，都不是東軟自己軟件的問題。
對于這個聲明，你問我怎么看？我最后再告訴你。
我先從技術角度對這個問題做一個整體分析。 首先是網上的幾個傳說，但傳說也僅僅只是傳說，這個鍋應該都不歸它們。
首先：是說網絡信號有問題，這個說法很明顯在打臉。 運營商的資源非常豐富。從事實上看，當時排隊的人那么多，大家也都在刷視頻、聊天，都非常流暢，完全無卡頓。呼吁大家讓出信號通道，設置為飛行模式，完全是想多了，運營商表示不答應。
其次：有人認為是天府健康通的問題
這個問題也有人澄清，成都的核酸檢測可以通過刷身份證，或者掃天府健康通的健康碼進行。
如果說真的是健康碼有了故障，那市民們完全可以刷身份證來做核酸。但從市民們的反饋來看，這兩種方法都無法成功。
那很明顯，問題自然出現(xiàn)在了核酸系統(tǒng)這一端。我們也可以看到，這兩套系統(tǒng)也是兩個不同廠家提供的支持，另外根據熱心人士提供信息，天府健康通規(guī)劃的容量是完全足夠的。
第三：有人認為是數(shù)據庫的問題
這個確實有可能，但不是數(shù)據庫本身的問題，而是數(shù)據設計的問題。 即便用了MySQL，也不能就說是數(shù)據庫本身的問題，比如說，有一個灶臺和一口小鍋，一次不能炒很多，但可以多幾口鍋，分開炒，所以也不能把這個鍋甩給MySQL數(shù)據庫，同時這個數(shù)據庫的設計一定是核酸系統(tǒng)廠家（迷之廠商）設計的才對。
分析完了幾個傳言，那么核酸系統(tǒng)是哪里出現(xiàn)了問題？
成都市民不外出小區(qū)，檢測點全部進入小區(qū)，所以一下子要多出好幾倍的業(yè)務量，的確對核酸系統(tǒng)提出了非常高的要求。針對這類高并發(fā)的業(yè)務系統(tǒng)，如何提高系統(tǒng)穩(wěn)定性，可靠性，確實是一個技術活，這也不是簡單某一點上的問題，而是一個系統(tǒng)工程，在多個環(huán)節(jié)上都需要進行控制，否則很難達到目標。
我接著從程序員的角度，來列舉幾個可能存在問題的環(huán)節(jié)。
第一：接入網關
這個能力非常重要，也是互聯(lián)網架構中不可缺少的環(huán)節(jié)，主要的能力是鑒權和限流。鑒權的目的是防止被非法訪問，不合規(guī)不合法的訪問請求被阻止掉；其次是限流，我們的系統(tǒng)設計一定有一個上限，超過上限怎么辦？與其讓系統(tǒng)崩潰還不如把請求控制在設計的流量范圍內，系統(tǒng)還可以運行。
例如：我們設計的交通是四車道，當車流量達到四車道的負荷時，就進行限制，控制車輛進入，這樣可以保障四車道的車流繼續(xù)進行運轉，如果不限流，其結果就是將四車道變成停車場，全部都堵死，誰也跑不了。這就是有些系統(tǒng)設計時考慮了這個環(huán)節(jié)時的情況是可能較慢，但不至于崩盤，不至于都不能用。
成都核酸系統(tǒng)，就很可能存在這種問題，在2號之前在區(qū)縣使用的時候沒有問題，2號進行大面積使用時，系統(tǒng)經?？ㄋ?，一直轉圈，操作人員被迫終止程序重新登錄。
高速公路變成停車場
第二：應用服務器擴展能力
擴展分為垂直擴展和水平擴展。 所謂的垂直擴展，大家容易理解，就是將處理能力低的服務器升級到高配置，例如：增加CPU，增加內存等，但是這種往往比較受限，服務器垂直擴展能力是有限的，不能無限制的擴展。
其次是水平擴展，就是說增加數(shù)量，就是一臺服務不夠，再增加一臺，10臺不夠，就增加到20臺，這個就和架構設計有關系了，能做到水平擴展才行，不然想通過資源來擴展都沒有辦法使上力。
成都核酸系統(tǒng)根據2號的情況來看，無論是掃描身份證讀取身份基本信息， 還是讀取天府健康通健康碼獲取用戶信息都比較慢，比較懷疑這里處理的服務器能力也不足 ，如果架構上非常靈活支持水平擴展，通過申請政務云資源，應該很快可以提升。
第三：業(yè)務緩存
大家都知道數(shù)據存放在數(shù)據庫中，每次的讀寫都需要產生大量的磁盤IO，這是性能的瓶頸，可以將高頻使用的數(shù)據存放在內存中，大大提升讀寫的效率，同時也不用每次都訪問數(shù)據庫，既減輕了數(shù)據庫的壓力，也大大提升效率。
但是內存的數(shù)據不是長久存放，最終還必須要寫到磁盤中，所以在架構設計的時候要充分考慮數(shù)據一致性和安全問題，防止數(shù)據丟失以及不一致。
根據2號的表現(xiàn)來看，成都的核酸系統(tǒng)在獲取完待檢測人員信息之后， 加入到檢測人員列表時，也需要較長時間，并且還容易在這個環(huán)節(jié)卡死，所以大概率是在寫入數(shù)據時出現(xiàn)異常， 有可能是直接采用寫入數(shù)據庫的方式，產生了數(shù)據庫擁塞，所以是否使用了緩存技術無法判斷。
第四：數(shù)據庫的性能優(yōu)化
這是最后一個環(huán)節(jié)，包括：分庫、分表、讀寫分離，也是最容易出現(xiàn)問題的地方。
一是采用分庫，就是給數(shù)據庫瘦身，不要把所有的數(shù)據都放在一個庫中， 類似不能把高新區(qū)的人都安排在一個小區(qū)一樣，安排在一個小區(qū)，所有人都要通過小區(qū)大門進出，容易導致阻塞，就是說的請求擁堵。
二是采用分表，就是讓單個的表中的數(shù)據不能太多，也是避免讀寫時產生擁堵， 類似一個小區(qū)中的不同樓棟一樣，如果所有的人都住在一棟樓，這些人員的進出就會很擁堵，進門要堵，電梯要堵，所以可以分成不同的樓棟，大家分開進行，減低擁堵可能性。分表的方式很多，可以按照日期來分表，每天一套表，也可以按照區(qū)域來分表，不同區(qū)域的數(shù)據存在不同的表中，結果就是單表的數(shù)據量會變小，讀寫擁堵可能性大大減低，這也是提升數(shù)據庫性能的很好的手段。
三是采用讀寫分離，就是分成不同的庫， 有些庫主要負責寫入數(shù)據，有些數(shù)據庫是負責查詢數(shù)據，一個主庫負責寫，然后復制幾個庫來支持查詢，這樣可以將數(shù)據庫的負荷進行分擔，也可以大大提升性能。
成都的核酸系統(tǒng)也有可能是在寫入數(shù)據時出現(xiàn)異常，很大可能是沒有采用分庫、分表的技術，導致在數(shù)據寫入時產生大量的并發(fā)，寫入不了。
其實，核酸系統(tǒng)的業(yè)務并不復雜。
主要流程就是： 登錄人員登錄到對應的檢測點之后，然后就是選擇單檢、混檢1（10混）、混檢2（20混）。假如選擇混檢1，然后掃描試管上條碼，生成一組，再掃描檢測人員，滿10人后，選擇封管，就能完成一組操作。
但就算業(yè)務邏輯不復雜，還能出現(xiàn)如此差的表現(xiàn)，那我分析主要問題還是出現(xiàn)在架構設計上，沒有考慮高并發(fā)場景。
很大可能性是：
沒有考慮限流機制（應該根據壓測的容量進行設置閾值）；
沒有考慮緩存機制，導致都需要直接讀寫數(shù)據庫，給數(shù)據庫造成極大壓力；
沒有考慮數(shù)據庫的分庫分表，導致數(shù)據庫異常繁忙，并發(fā)量大時，沒有辦法正常寫入。
所以我認為與網絡沒有太大關系，和天府健康通也沒有關系，和政務云資源也沒有關系 （按照需求進行分配，政務云的資源是動態(tài)分配，滿足業(yè)務需求不會太大挑戰(zhàn)）。
真心建議核酸系統(tǒng)開發(fā)公司認真分析，找出問題根源，進行認真優(yōu)化，不要讓我們再經歷這樣的情況！
(本文系投稿，作者是一名來自成都的程序員）
名稱欄目：成都程序員分析，核酸系統(tǒng)一崩再崩，到底誰的鍋？
文章分享：http://www.dlmjj.cn/article/djdhjho.html
