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從一位接近西安“一碼通”項目人士處獲悉，整個故障的大致原因已基本清晰，就是一起因流量過載、系統架構應對高并發不足，最終導致防火墻攔截數據無法返回的系統性故障。

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

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

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

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

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

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

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

然后是在招標執行的時候，要確保投標公司有足夠的能力，這時候不光要看他們承諾的能力，更要看他們做過哪些案例；

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

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

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

關鍵詞： 流量 李明 防火墻 架構 西安 閾值 疫情 系統 服務器 私有云