疫情爆發(fā)已兩年有余,數(shù)字化防疫早已深入工作生活的每個角落。“請出示您的健康碼”,成為人們?nèi)粘B牭降母哳l詞語。承載了千千萬萬甚至上億人群防疫碼查詢的IT系統(tǒng)如何穩(wěn)定、高效、安全的運行,便成了各地精準防疫的重點課題。下面是UCloud優(yōu)刻得根據(jù)近兩年對部分城市和地區(qū)防疫碼的服務經(jīng)驗,總結(jié)的一些實踐建議:
一、防疫碼系統(tǒng)主要模塊
“點擊手機小程序、輸入手機號、輸入驗證碼、展示健康碼”這看似簡單的動作,其實在防疫碼系統(tǒng)內(nèi)是拆分為多個步驟執(zhí)行的,包括:
»用戶身份驗證:通過短信動態(tài)驗證、人臉識別驗證等形式,落實一人一碼。
»號碼段驗證:通過手機號識別歸屬運營商,便于運營商短信自動化同步用戶。
»用戶行程信息查詢:根據(jù)運營商提供的用戶行程情況,結(jié)合國家衛(wèi)健委疫情風險數(shù)據(jù),提供更為清晰的行程信息。
»紅/黃/綠碼的顯示:依托來自于衛(wèi)健、公安、通管等部門匯聚的數(shù)據(jù),經(jīng)過防控規(guī)則和數(shù)據(jù)建模,分析評估后,測算出紅色、黃色、綠色三種風險狀態(tài)。
»疫苗/核酸信息的查詢:根據(jù)衛(wèi)健等部門提供的信息,便于用戶即時查看接種記錄及疫苗信息。
從以上步驟可以看出,防疫碼功能看似簡單,其實背后涉及到許多模塊,需要多部門信息高頻調(diào)用(跨部門信息高頻率互通),再加上人們早晚高峰出行的集中性,因此系統(tǒng)具有高復雜度、高并發(fā)性、高依賴度的特點。同時由于疫情爆發(fā)的突發(fā)性,絕不是通過固定部署幾臺服務器就能夠滿足未來不確定的需求。因此靈活方便、即時擴展、算力豐富的云平臺便成了部署防疫碼系統(tǒng)一個極佳的選擇。
二、系統(tǒng)容量規(guī)劃:
云平臺雖然可以對IT資源快速進行橫向擴容,但一昧地堆資源,并不能有效提升系統(tǒng)的穩(wěn)定性。所以,系統(tǒng)各個模塊構(gòu)建合理的容量規(guī)劃才是穩(wěn)定之基。
1.容量規(guī)劃
整套系統(tǒng)的容量規(guī)劃,除了基于每日用戶訪問量峰值來建模進行估算外,同時也需對整體訪問鏈路中涉及到的各類模塊分別進行計算評估,比如:互聯(lián)網(wǎng)帶寬、負載均衡鏈接數(shù)、應用服務并發(fā)數(shù)、數(shù)據(jù)庫連接池等。
與很多人的認知不同,其實,每個模塊的容量規(guī)劃并不是越大越好,這主要是因為各模塊之間存在依賴關(guān)系,一個模塊容量過大,可能會導致該調(diào)用鏈路上的其他模塊服務雪崩。
舉個例子,上圖中的數(shù)據(jù)庫類似餐廳大廚,假定只能同時服務5個用戶。應用集群如同餐廳,能同時容納100人。如果用戶以20人/分鐘的速度進入餐廳,由于前面的用戶還未就餐完畢,后續(xù)的用戶不斷涌入,最終會導致超出餐廳的同時服務能力,整個系統(tǒng)也就崩潰了。
2.限流管控
鑒于防疫碼的高并發(fā)訪問場景,為了保障防疫碼系統(tǒng)的正常運轉(zhuǎn)。必要時還需用到一些限流措施。
限流的目的不僅是為了控制訪問的總并發(fā)量,而且還要盡量讓訪問的流量來的更均衡,這樣才不會讓系統(tǒng)的負載大起大落,因此又稱為"流量整形" 。
常見的限流手段包括互聯(lián)網(wǎng)入口處針對單個運營商級別的網(wǎng)絡(luò)限流,或者負載均衡器上的新建連接數(shù)和并發(fā)連接數(shù)的流控,以及應用服務的參數(shù)調(diào)整等。
限流雖說是有損的,比如它會造成部分用戶的請求失敗,但在用戶重試的情況下,若干次嘗試后,請求便會成功。限流引起的重試確實會對用戶體驗造成影響,但相比較于應用集群的崩潰而言,是可以接受的。
三、防疫碼模塊的關(guān)鍵點:
1.用戶身份驗證模塊
在日常生活中,進入某辦公樓會先檢查對方的證件,確定身份后才能進入。防疫碼也有著類似的用戶身份驗證場景。常用驗證方法有兩種:手機短信驗證和人臉識別驗證。
其中手機短信驗證大致過程為:用戶請求發(fā)送短信驗證碼,應用集群調(diào)用第三方短信平臺發(fā)送驗證碼給用戶,驗證碼和用戶信息(手機號)可存放到緩存中,并設(shè)置驗證碼失效時間。當用戶接收到短信,輸入驗證碼即可完成身份驗證。
一般而言,應用集群對這類信息不需要進行持久化存儲,建議使用緩存產(chǎn)品如Redis等。而且,用戶身份驗證的超時機制很關(guān)鍵,當用戶發(fā)現(xiàn)驗證失敗時會頻繁發(fā)起驗證,在高峰期這個過程會形成雪崩效應,加劇系統(tǒng)的負荷,不控制的話,有可能造成系統(tǒng)處理能力下降,累計下來,會造成系統(tǒng)崩潰。
2、用戶行程查詢模塊:
行程查詢是防疫碼系統(tǒng)的關(guān)鍵模塊,首先系統(tǒng)核驗用戶所屬的運營商,再利用運營商的接口來查詢行程信息。在高峰時期會有大量的查詢,這也是系統(tǒng)容易造成崩潰的地方。
防疫碼系統(tǒng)是通過互聯(lián)網(wǎng)訪問各大運營商數(shù)據(jù),依賴于互聯(lián)網(wǎng)傳輸?shù)馁|(zhì)量,在實際使用過程中,網(wǎng)絡(luò)的擁塞可能會造成接口超時的情況,系統(tǒng)超時設(shè)置也要特別注意,超時重試時間不宜過短,避免頻繁重試加劇系統(tǒng)的負載。如果可以和運營商互聯(lián)專線,也能更好地解決網(wǎng)絡(luò)擁塞的情況,但專線的價格較高,成本會有一定上升。
整個請求鏈路上很可能設(shè)置防火墻設(shè)備,由于防火墻的問題,可能造成系統(tǒng)訪問異常,但只要做一些基本的壓力測試就能發(fā)現(xiàn)這類問題,同時解決防火墻的問題也不復雜。
3.紅/黃/綠碼的顯示
大部分防疫碼都是依托國家及當?shù)毓补芾頇C構(gòu)的數(shù)據(jù),并結(jié)合行程信息和當?shù)卣姆酪叽胧?jīng)過數(shù)據(jù)建模,分析評估后,從而展現(xiàn)出紅色、黃色、綠色三種風險狀態(tài)碼。
部分地區(qū)防疫政策系統(tǒng)構(gòu)建于防疫碼系統(tǒng)之外,因此相應的容量規(guī)劃也需要參考防疫碼每日最高訪問量進行設(shè)計。
4.疫苗/核酸信息的查詢
疫苗和核酸信息的查詢服務,目前以紙質(zhì)為主,一般不會對整體系統(tǒng)壓力造成影響。但目前來看部分地域的系統(tǒng)化查詢已經(jīng)在逐步落實,后續(xù)需對相應的容量規(guī)劃進行評估,同時控制好信息查詢的超時設(shè)置。
當前疫情防控形勢仍比較嚴峻,防疫碼的穩(wěn)定運行對于疫情防控至關(guān)重要?;诙嗄陙淼脑朴嬎氵\營技術(shù)和經(jīng)驗,UCloud優(yōu)刻得希望通過本次技術(shù)分享,為防疫工作提供一定的參考和助力,更好地發(fā)揮出云計算的社會價值。
(免責聲明:本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性,但不保證有關(guān)資料的準確性及可靠性,讀者在使用前請進一步核實,并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏,概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時,應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明,并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后,將會依法盡快聯(lián)系相關(guān)文章源頭核實,溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 )