半個(gè)月崩兩次，從技術(shù)角度聊聊一碼通
最近西安疫情特別嚴(yán)重，還出現(xiàn)了一碼通崩潰的事件，網(wǎng)絡(luò)上對(duì)此也有各種各樣的評(píng)論和說(shuō)法。
對(duì)于各種言論和說(shuō)法我們沒(méi)有權(quán)力去評(píng)頭論足，但是可以從技術(shù)的角度聊一聊，如果是我們接到了這樣的需求，應(yīng)該來(lái)如何設(shè)計(jì)這個(gè)系統(tǒng)。使得它可以在關(guān)鍵時(shí)刻經(jīng)得住考驗(yàn)，為防疫工作提供方便做出貢獻(xiàn)。
首先我們分析一碼通大致有哪些基本需求需要實(shí)現(xiàn)，應(yīng)該會(huì)有個(gè)人信息登記注冊(cè)以及修改的需求。還會(huì)有個(gè)人健康信息查詢(xún)需求，也就是健康碼了。也有個(gè)人行程信息記錄需求，也就是平時(shí)我們進(jìn)出小區(qū)，商場(chǎng)，乘坐公共交通等等的時(shí)候掃碼操作。應(yīng)該還有后臺(tái)修改個(gè)人數(shù)據(jù)的需求，例如更改個(gè)人的紅綠黃碼，個(gè)人核酸檢測(cè)結(jié)果等?？梢詫?duì)上面需求做一個(gè)如下總結(jié)：
個(gè)人信息登記注冊(cè)以及修改：由用戶(hù)端驅(qū)動(dòng)，既有讀操作也有寫(xiě)操作，實(shí)時(shí)性要求較高，寫(xiě)操作需要立即得到結(jié)果，但是并發(fā)量不大(畢竟大家同時(shí)修改個(gè)人信息的概率比較低)。
個(gè)人健康信息查詢(xún)：由用戶(hù)端驅(qū)動(dòng)，只有讀操作，實(shí)時(shí)性要求較高，并發(fā)量比較大(大家同時(shí)刷健康碼的概率非常大，這次崩潰的就是這個(gè)服務(wù))。
個(gè)人行程信息記錄：由用戶(hù)端驅(qū)動(dòng)，只有寫(xiě)操作，寫(xiě)操作不需要立即得到結(jié)果給用戶(hù)，實(shí)時(shí)性要求較不高，并發(fā)量不大(畢竟疫情期間蜂擁而出情況不多)。
后臺(tái)修改個(gè)人數(shù)據(jù)：非用戶(hù)驅(qū)動(dòng)，應(yīng)該是由后臺(tái)的 job 或者相關(guān)工作人員來(lái)驅(qū)動(dòng)的。只有寫(xiě)操作，并發(fā)量不大(畢竟非用戶(hù)驅(qū)動(dòng)的操作還是可控的)。
數(shù)據(jù)中心
對(duì)于這種 mission critical 的系統(tǒng)還是建議從數(shù)據(jù)中心的角度建立多個(gè) site，每個(gè)數(shù)據(jù)中心的接入點(diǎn)都申請(qǐng)不同的 FQDN 域名，從接入層就利用 DNS 的來(lái)分流到多個(gè)數(shù)據(jù)中心。當(dāng)然這個(gè)可以不必那么復(fù)雜，不必引入 GTM 把流量基于地理位置分發(fā)到不同的地區(qū)的數(shù)據(jù)中心，畢竟大家都在一個(gè)地區(qū)。
接入層負(fù)載均衡以及 CDN
對(duì)于每個(gè)數(shù)據(jù)中心的服務(wù)來(lái)說(shuō)一定是有負(fù)載均衡的，負(fù)載均衡基于不同的維度有很多種類(lèi)。有三四層負(fù)載均衡，七層負(fù)載均衡，基于應(yīng)用的負(fù)載均衡，基于操作系統(tǒng)內(nèi)核的負(fù)載均衡，還有基于硬件的負(fù)載均衡。這個(gè)系統(tǒng)在接入層也不需有復(fù)雜的負(fù)載均衡策略，可以追求速度，所以可以選擇更快的三四次負(fù)載均衡，或者硬件負(fù)載均衡。另外系統(tǒng)一定是有靜態(tài)資源的，例如圖片或者 html/css 等等，這些資源可以完全放在 CDN 來(lái)管理，以減輕系統(tǒng)負(fù)載，加速靜態(tài)資源訪(fǎng)問(wèn)。
服務(wù)層拆分
根據(jù)上面的需求分析，可以根據(jù)基本需求的讀寫(xiě)特性和并發(fā)量從業(yè)務(wù)上拆分不同的服務(wù)。
個(gè)人信息登記注冊(cè)以及修改：讀寫(xiě)實(shí)時(shí)性較高，但是并發(fā)量不大，所以這個(gè)服務(wù)可以直接訪(fǎng)問(wèn)我們的存儲(chǔ) storage。
個(gè)人健康信息查詢(xún)：并發(fā)量比較大，這個(gè)服務(wù)不可以直接訪(fǎng)問(wèn)我們的存儲(chǔ)，需要引入緩存來(lái)加速訪(fǎng)問(wèn)。
個(gè)人行程信息記錄：寫(xiě)操作不需要立即得到結(jié)果給用戶(hù)，實(shí)時(shí)性要求較不高，并發(fā)量不大，所以可以引入消息隊(duì)列 MQ 來(lái)加速并解耦這個(gè)服務(wù)和存儲(chǔ)。
后臺(tái)修改個(gè)人數(shù)據(jù)：和上面的個(gè)人行程信息記錄一樣。
上面的服務(wù)層一定需要有快速的動(dòng)態(tài)擴(kuò)容和發(fā)布的能力，所以可以考慮基于當(dāng)前比較流行的 kunbernetes 平臺(tái)或者 service mesh 平臺(tái)。另外對(duì)于服務(wù)的協(xié)議，如果追求速度可以考慮使用二進(jìn)制的 RPC 協(xié)議(例如GRPC)來(lái)代替?zhèn)鹘y(tǒng)的 HTTPS + JSON 格式的協(xié)議。
緩存的引入
上面的分析指出，對(duì)于只讀的，并且流量大的服務(wù)，例如個(gè)人健康信息查詢(xún)，我們是一定需要引入分布式緩存的。對(duì)于分布式緩存我們可以考慮下面的幾點(diǎn)：
緩存容量：西安常住人口大約1200萬(wàn)人，一個(gè)人分配10KB的緩存估算，大約就需要120GB，在加上25%的 Buffer，所以需要大約總共150GB的緩存。當(dāng)然這么大的緩存不可能是單機(jī)的，一定是分布式的的，需要利用一些基于緩存數(shù)據(jù)分片的 sharding 方式把他們均勻的緩存在不同的機(jī)器上。
緩存預(yù)加載：我們不可以指望通過(guò)應(yīng)用程先查詢(xún)緩存，沒(méi)有數(shù)據(jù)在去存儲(chǔ)里取并放到緩存里，這樣在并發(fā)大的時(shí)候依然會(huì)有問(wèn)題。所以需要有緩存的預(yù)加載過(guò)程，當(dāng)然我們可以基于數(shù)據(jù) sharing 分片的方式去加載，例如可以基于人所屬的區(qū)域，分不同的批次做，這樣也提高效率。
緩存擊穿：如果查詢(xún)一個(gè)不存在的對(duì)象，例如不存在的緩存 key，那么由于緩存里沒(méi)有也依然會(huì)去訪(fǎng)問(wèn)存儲(chǔ)的。所以對(duì)于緩存擊穿的情況，我們可以給它設(shè)置一個(gè)短暫的緩存時(shí)間，以及一個(gè)空的值。
緩存雪崩：當(dāng)我們?cè)O(shè)置緩存的時(shí)候，如果不注意緩存過(guò)期時(shí)間，如果在同一時(shí)刻大批量的緩存失效，就會(huì)有大量的訪(fǎng)問(wèn)同時(shí)進(jìn)入存儲(chǔ)。所以我們可以基于數(shù)據(jù) sharing 分片設(shè)置不同的緩存時(shí)間。另外我們還可以有一個(gè)緩存續(xù)約服務(wù)，對(duì)于那些沒(méi)有數(shù)據(jù)更新的緩存，定期批量的延長(zhǎng)緩存時(shí)間。當(dāng)然這個(gè)服務(wù)也可以基于數(shù)據(jù) sharing 分片提高效率。
緩存同步：有緩存就有緩存同步的問(wèn)題，我們可以引入緩存同步服務(wù)，來(lái)定期把有更改的數(shù)據(jù)批量同步到緩存里。當(dāng)然這里的數(shù)據(jù)一定不是哪種實(shí)時(shí)性要求高的數(shù)據(jù)，比方說(shuō)紅綠碼變更，近期核算檢測(cè)結(jié)構(gòu)等。對(duì)于實(shí)時(shí)性高的數(shù)據(jù)，例如個(gè)人信息登記和修改，一定是要同時(shí)更新存儲(chǔ)和緩存的。
存儲(chǔ)的引入
對(duì)于存儲(chǔ)這個(gè)塊，數(shù)據(jù)量一定是比較大的，而且根據(jù)不同時(shí)期的防御政策一定會(huì)有不同的動(dòng)態(tài)數(shù)據(jù)加入，數(shù)據(jù)結(jié)構(gòu)變化可能比較頻繁，所以可以引入 NoSql 來(lái)做數(shù)據(jù)存儲(chǔ)。另外不僅僅是存儲(chǔ)的問(wèn)題，一定會(huì)有大數(shù)據(jù)的分析需求，有基于實(shí)時(shí)性要求比較高的流處理和可以有等待的批處理，以及將數(shù)據(jù)匯報(bào)給國(guó)家防疫平臺(tái)的處理等，這里我們做不展開(kāi)討論。
監(jiān)控和預(yù)警的引入
對(duì)于這種 mission critical 的系統(tǒng)一定需要有完善的監(jiān)控和預(yù)警的引入，需要從不同維度上來(lái)對(duì)整個(gè)系統(tǒng)來(lái)監(jiān)控和預(yù)警，例如：
基礎(chǔ)設(shè)施和操作系統(tǒng)維度：也就是我們經(jīng)常會(huì)提到的計(jì)算維度的 CPU, 存儲(chǔ)維度的 Memory/Disk，網(wǎng)絡(luò)維度的吞吐量等等。
中間件維度：對(duì)各種中間件的監(jiān)控，例如緩存，線(xiàn)程池，連接池，數(shù)據(jù)庫(kù)，消息隊(duì)列，應(yīng)用服務(wù)器，負(fù)載均衡器等等。
應(yīng)用程序維度：對(duì)應(yīng)用程序本身的監(jiān)控，也就是我們常常所說(shuō)的 APM 這個(gè)概念，可以更細(xì)節(jié)的了解應(yīng)用本身的運(yùn)行。
總體架構(gòu)設(shè)計(jì)
莫名其妙的9443端口
莫名其妙的消息
可以看到前端調(diào)試信息按鈕等
友情提示一下證書(shū)還有半年多就要過(guò)期了，可以盡快換證書(shū)。 
簡(jiǎn)歷指導(dǎo)/Java 學(xué)習(xí)/面試指導(dǎo)/面試小冊(cè)，歡迎加入我的知識(shí)星球（公眾號(hào)后臺(tái)回復(fù)“星球”即可）。
如果本文對(duì)你有幫助的話(huà)，歡迎點(diǎn)贊&在看&分享，這對(duì)我繼續(xù)分享&創(chuàng)作優(yōu)質(zhì)文章非常重要。感謝????