天天看點

危情時刻,健康碼如何遠離“崩潰”?

危情時刻,健康碼如何遠離“崩潰”?

圖:葉映橙

來源:21tech

作者:白楊

編輯:李清宇

1月10日上午,廣東省的粵康碼突然通路異常,給很多正在上班的人帶來諸多不便。

事後,粵康碼釋出公告稱,“10日上午8:31,平台監測到粵康碼流量異常增大,最高達每分鐘140萬次,超出承載極限,觸發系統保護機制,導緻部分使用者通路粵康碼緩慢或異常,運作保障團隊緊急處置,于9:04部分緩解,9:56完全恢複順暢運作”。

一周前,西安一碼通更是在短短半個月内連續兩次崩潰。2021年12月20日早上,西安一碼通出現通路異常,修複工作持續一整天;2022年1月4日上午,西安一碼通再次崩潰,至中午恢複正常。

第一次故障,西安官方給出的回複是“每秒通路量達到以往峰值的10倍以上,造成網絡擁塞”,而第二次故障,同樣是因為“通路量過大”。

近兩年,随着疫情防控進入常态化,健康碼已成為人們出行的一個“必需品”。這導緻健康碼一旦出現問題,也會給人民群衆的生活帶來較大影響,尤其是像西安,正處于抗擊疫情的關鍵時刻,健康碼的失靈也直接妨礙了防疫工作的開展。

有了前車之鑒,各地政府亟需思考的一個重要問題是——如何防止健康碼出現崩潰。

安全與效率的博弈

不過,行業專家李明告訴21世紀經濟報道,如果從技術的角度,健康碼營運支援已經非常成熟,但面對突如其來的通路壓力,保證百分之百的不出現問題并不現實。

且不說從理論上,就不存在絕對穩定的系統,從目前健康碼最常見的崩潰原因——流量過載來看,這背後尚存在效率、成本、安全的博弈問題。

李明表示,一般的系統架構都存在承載門檻值,當使用者流量超過這個門檻值,系統便會出現崩潰。實際上,這個問題在很多産品中都出現過,比如此前的微網誌,便多次遇到因某明星突然曝出八卦新聞,使用者量瞬時增加導緻産品崩潰。

很多人會好奇,那為什麼不提高這個門檻值,避免出現過載情況?這便涉及到通路效率和成本的平衡問題。因為提高門檻值,需要更多的伺服器,也意味着更多的成本。

李明透露,以健康碼為例,承載千萬人口的通路需要的成本大概是千萬級别。假如一個城市健康碼日常的并發量峰值隻有10萬,為此卻準備50萬并發量的伺服器,也會造成資源浪費。

是以在實際操作中,每個城市的健康碼都會根據當地情況,設定一個合理的門檻值,至少能保證日常的使用。但這也會留下一個隐患,即當地居民集中大規模使用健康碼時,便會導緻使用者流量超出門檻值。

雖然是小機率事件,但這也說明健康碼因為突然的流量增加出現崩潰,也算是一個意料之中的事情。是以,真正要解決的問題應該是,系統出現過載之後,能否快速恢複。

李明稱,從技術的角度,目前也已經具備了快速應對的能力。其提到了幾個設計原則:

首先在設計系統架構的時候,要考慮極端情況,比如某城市人口1000萬,那架構設計就至少要考慮到1000萬人可能出現的極端情況。

在架構之下,要具備彈性伸縮的能力。比如平時隻需要使用100台伺服器,在遇到特殊情況時,100台伺服器不夠用了,需要支援快速彈性擴充。這個場景其實也是雲計算的一項核心能力,目前也十分成熟。

另外,系統也需要做災備。這是確定使用者通路出現過載且彈性伸縮能力沒有發揮作用的情況下,至少有一套備案可以及時啟用。

除此之外,像是對系統流程進行解耦,把整個業務過程分割成不同層級,防止流量集中湧入;或者是通過分布式的架構,将流量拆分到不同處理區。這些都能夠有效避免整個系統的崩潰。

西安一碼通的警示

是以,健康碼遇到問題并不可怕,隻要能快速恢複,便基本能滿足群衆所需。但西安一碼通這次備受關注,一方面是第一次崩潰時間長達一天,另一方面則是短時間内連續出現兩次問題。

按照上文提到的一些解決方案,西安一碼通在第一次遇到通路量過載的時候,正常的操作應該是通過彈性伸縮的方式來應對,但一碼通系統最終崩潰,這說明在系統架構上,設計之初沒有充分考慮負載均衡和彈性伸縮的情況。

據钛媒體App從一位接近西安“一碼通”項目人士處獲悉,整個故障的大緻原因已基本清晰,就是一起因流量過載、系統架構應對高并發不足,最終導緻防火牆攔截資料無法傳回的系統性故障。

李明向記者表示,防火牆也有吞吐量的限制,如果流量太大超出吞吐量上限,那防火牆也将無法響應。正常來說,防火牆也應該有負載均衡機制,當一個防火牆無法支撐的時候,就啟用其他防火牆分擔其流量。

當然,這個背後又涉及到公有雲和私有雲的問題。李明稱,目前整個政務市場都傾向于使用私有雲,如果防火牆是私有雲架構,那災備的防火牆平時即使不用,買來也需要成本,但這個成本往往不能省。

系統架構無法滿足快速擴容,這也造成西安一碼通遇到高并發的流量時,處理能力變得僵化。至于為何出現這樣的情況,李明認為,這說明整個系統在設計時,就沒有充分考慮到各種可能出現的情況。而且在已經出現全城範圍的疫情防控時,也應該提前做系統的抗壓力測試和演練準備。

此外,有些地區的健康碼建設的分包情況,也出現了一些不合理的問題。一般而言,作為總包商,核心子產品不應該再分包出去。

這裡的核心子產品包括整個健康碼的接入、生成、驗碼等關鍵引擎。“當然,至于其他一些簡單的業務子產品,分包出去是沒問題的,幾乎所有健康碼項目,也都存在分包的情況”,李明說。

對于健康碼項目,李明認為,首先要明确項目的邊界,比如承載的并發量是多大,遇到突發情況能容忍的處理時間是多少;

其次,要有嚴格的審查機制。整個系統架構要經過認真的審查,并且審查人員應該實行終身負責制,而不是走個形式,導緻出現問題不知道找誰;

然後是在招标執行的時候,要確定投标公司有足夠的能力,這時候不光要看他們承諾的能力,更要看他們做過哪些案例;

最後是有預警機制,比如當流量達到峰值的一定比例時,就要提前啟動預案。再比如某地突發局部疫情,這時候也要提前采取措施。

西安一碼通因兩次崩潰而引發的巨大輿論,已給其他地方政府敲響了警鐘。比如北京在近日的防控疫情工作會議上便提出,用好“北京健康寶”,加強壓力測試和系統運作維護,確定正常運作。

在疫情反複無常的常态下,我們希望健康碼不要出現任何異常,如果發生了異常,也希望能夠以最快的速度恢複,而不是讓人們等待一天甚至半天那麼久。

(應采訪者要求,李明為化名)

編輯:盧陶然

繼續閱讀