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