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