疫情爆發已兩年有余，數字化防疫早已深入工作生活的每個角落。“請出示您的健康碼”，成為人們日常聽到的高頻詞語。承載了千千萬萬甚至上億人群防疫碼查詢的IT系統如何穩定、高效、安全的運行，便成了各地精準防疫的重點課題。下面是UCloud優刻得根據近兩年對部分城市和地區防疫碼的服務經驗，總結的一些實踐建議：

一、防疫碼系統主要模塊

“點擊手機小程序、輸入手機號、輸入驗證碼、展示健康碼”這看似簡單的動作，其實在防疫碼系統內是拆分為多個步驟執行的，包括：

»用戶身份驗證：通過短信動態驗證、人臉識別驗證等形式，落實一人一碼。

»號碼段驗證：通過手機號識別歸屬運營商，便于運營商短信自動化同步用戶。

»用戶行程信息查詢：根據運營商提供的用戶行程情況，結合國家衛健委疫情風險數據，提供更為清晰的行程信息。

»紅/黃/綠碼的顯示：依托來自于衛健、公安、通管等部門匯聚的數據，經過防控規則和數據建模，分析評估后，測算出紅色、黃色、綠色三種風險狀態。

»疫苗/核酸信息的查詢：根據衛健等部門提供的信息，便于用戶即時查看接種記錄及疫苗信息。

從以上步驟可以看出，防疫碼功能看似簡單，其實背后涉及到許多模塊，需要多部門信息高頻調用(跨部門信息高頻率互通)，再加上人們早晚高峰出行的集中性，因此系統具有高復雜度、高并發性、高依賴度的特點。同時由于疫情爆發的突發性，絕不是通過固定部署幾臺服務器就能夠滿足未來不確定的需求。因此靈活方便、即時擴展、算力豐富的云平臺便成了部署防疫碼系統一個極佳的選擇。

二、系統容量規劃：

云平臺雖然可以對IT資源快速進行橫向擴容，但一昧地堆資源，并不能有效提升系統的穩定性。所以，系統各個模塊構建合理的容量規劃才是穩定之基。

1.容量規劃

整套系統的容量規劃，除了基于每日用戶訪問量峰值來建模進行估算外，同時也需對整體訪問鏈路中涉及到的各類模塊分別進行計算評估，比如：互聯網帶寬、負載均衡鏈接數、應用服務并發數、數據庫連接池等。

與很多人的認知不同，其實，每個模塊的容量規劃并不是越大越好，這主要是因為各模塊之間存在依賴關系，一個模塊容量過大，可能會導致該調用鏈路上的其他模塊服務雪崩。

舉個例子，上圖中的數據庫類似餐廳大廚，假定只能同時服務5個用戶。應用集群如同餐廳，能同時容納100人。如果用戶以20人/分鐘的速度進入餐廳，由于前面的用戶還未就餐完畢，后續的用戶不斷涌入，最終會導致超出餐廳的同時服務能力，整個系統也就崩潰了。

2.限流管控

鑒于防疫碼的高并發訪問場景，為了保障防疫碼系統的正常運轉。必要時還需用到一些限流措施。

限流的目的不僅是為了控制訪問的總并發量，而且還要盡量讓訪問的流量來的更均衡，這樣才不會讓系統的負載大起大落，因此又稱為"流量整形" 。

常見的限流手段包括互聯網入口處針對單個運營商級別的網絡限流，或者負載均衡器上的新建連接數和并發連接數的流控，以及應用服務的參數調整等。

限流雖說是有損的，比如它會造成部分用戶的請求失敗，但在用戶重試的情況下，若干次嘗試后，請求便會成功。限流引起的重試確實會對用戶體驗造成影響，但相比較于應用集群的崩潰而言，是可以接受的。

三、防疫碼模塊的關鍵點：

1.用戶身份驗證模塊

在日常生活中，進入某辦公樓會先檢查對方的證件，確定身份后才能進入。防疫碼也有著類似的用戶身份驗證場景。常用驗證方法有兩種：手機短信驗證和人臉識別驗證。

其中手機短信驗證大致過程為：用戶請求發送短信驗證碼，應用集群調用第三方短信平臺發送驗證碼給用戶，驗證碼和用戶信息(手機號)可存放到緩存中，并設置驗證碼失效時間。當用戶接收到短信，輸入驗證碼即可完成身份驗證。

一般而言，應用集群對這類信息不需要進行持久化存儲，建議使用緩存產品如Redis等。而且，用戶身份驗證的超時機制很關鍵，當用戶發現驗證失敗時會頻繁發起驗證，在高峰期這個過程會形成雪崩效應，加劇系統的負荷，不控制的話，有可能造成系統處理能力下降，累計下來，會造成系統崩潰。

2、用戶行程查詢模塊：

行程查詢是防疫碼系統的關鍵模塊，首先系統核驗用戶所屬的運營商，再利用運營商的接口來查詢行程信息。在高峰時期會有大量的查詢，這也是系統容易造成崩潰的地方。

防疫碼系統是通過互聯網訪問各大運營商數據，依賴于互聯網傳輸的質量，在實際使用過程中，網絡的擁塞可能會造成接口超時的情況，系統超時設置也要特別注意，超時重試時間不宜過短，避免頻繁重試加劇系統的負載。如果可以和運營商互聯專線，也能更好地解決網絡擁塞的情況，但專線的價格較高，成本會有一定上升。

整個請求鏈路上很可能設置防火墻設備，由于防火墻的問題，可能造成系統訪問異常，但只要做一些基本的壓力測試就能發現這類問題，同時解決防火墻的問題也不復雜。

3.紅/黃/綠碼的顯示

大部分防疫碼都是依托國家及當地公共管理機構的數據，并結合行程信息和當地政府的防疫措施，經過數據建模，分析評估后，從而展現出紅色、黃色、綠色三種風險狀態碼。

部分地區防疫政策系統構建于防疫碼系統之外，因此相應的容量規劃也需要參考防疫碼每日最高訪問量進行設計。

4.疫苗/核酸信息的查詢

疫苗和核酸信息的查詢服務，目前以紙質為主，一般不會對整體系統壓力造成影響。但目前來看部分地域的系統化查詢已經在逐步落實，后續需對相應的容量規劃進行評估，同時控制好信息查詢的超時設置。

當前疫情防控形勢仍比較嚴峻，防疫碼的穩定運行對于疫情防控至關重要?；诙嗄陙淼脑朴嬎氵\營技術和經驗，UCloud優刻得希望通過本次技術分享，為防疫工作提供一定的參考和助力，更好地發揮出云計算的社會價值。

責任編輯：劉沙