今天上午8:30左右，不少用戶集中反映，“粵省事”小程序里的“粵康碼”打不開了。

下方的“核酸檢測”和“疫苗接種”兩欄都注明“升級維護，請稍后再試”。

圖左為正常訪問；圖右為亮碼失敗

#粵康碼#、#粵康碼崩了#等詞條迅速登上微博熱搜。

事發六小時后，熱搜詞條仍然在榜

上午10:00之后，情況逐漸得到緩解。也有網友向雷峰網表示，自己的粵康碼在十點左右還是黑白，但在十點半左右已經可以正常打開。

今日午間，當市民再度打開“粵省事”小程序里的“粵康碼”，頁面會首先顯示公告稱：

8:31，監測到流量增大；

9:04，部分緩解；

9:56，完全恢復順暢運行。

而在粵康碼崩潰的90分鐘里，微信小程序“深i您”、“穗康碼”，以及由國家政務服務平臺提供服務的支付寶健康碼，均可正常使用。

微信小程序“深i您”界面

“應該只有‘粵省事’這個渠道出了問題。‘深i您’和‘穗康碼’都分別注明了‘粵康碼（深圳/廣州）’的字樣，但一樣可以正常打開。”有網友評論道。

公開資料顯示，數字廣東公司是粵康碼系統以及全省數字政府建設的運營中心。“粵省事”移動政務服務平臺，由騰訊與廣東省合作開發。

在1月7日到1月9日的三天時間里，深圳新增四例本土確診病例，深圳多區同時展開大規模核酸篩查。深圳以及廣東其他市縣的不少公共場所，都新增了入場前先亮健康碼和核酸證明的防疫要求。

而今天（1月10日）正是深圳“0107疫情”發生之后的第一個工作日，不少上班族正是在進入地鐵和辦公園區的時候，發現粵康碼打不開了。

這次故障的主要原因，多位業內人士表示，應該還是與高并發訪問有關。

官方聲明中提到：

而根據廣州日報的報道，2021年5-6月廣東曾爆發過一輪疫情，在此期間，粵康碼進行過系統調優升級：

促使網關每分鐘可承載的訪問量從原來的10萬+提升至60萬+，每天的調用量從原來的10億+提升至80億+。

有業內人士指出，從兩組數字的對比來看，粵康碼系統今早確實顯著承壓。

“遇到高峰浪涌，爆服務器負載屬于正常現象。”資深信息安全專家吳先生向雷峰網解釋，就算有彈性資源自動擴容機制，生效也需要時間，擴容期間的請求還是會卡在隊列里。

整個擴容流程大致是：浪涌到閾值——觸發告警——觸發擴容請求——分配資源——掛載鏡像——服務啟動——負載均衡器轉發流量。

他強調：“擴容的每一步都是秒級反應，但第一步到最后一步之間，這段時間的請求，在重新請求之前都卡著。如果浪涌太快，需要連續申請資源，還是會卡不少時間。”

舉個例子：

假設隊伍負載是100（100進100出）一旦溢出，假設每次擴容20％，擴容用時10秒；某一秒的峰值到達130，觸發告警；10秒后擴容至120，不夠則繼續擴容；但在這10秒內，超出能力的請求數量可能已經累積了300個，響應還是很慢，只能等著隊列超時后重新分配，或者卡進去。這還不包括“卡了之后重新請求——造成流量異常上升”的情況。

也就是說，即便擴容只需要十秒鐘，但就在這十秒鐘之內，問題還在不斷堆積；自動擴容后的能力，也未必能應對十秒之后的新情況。

這種“訪問量激增導致亮碼失敗”的情況，可以通過提前擴容來應對嗎？

“很難，除非準確預測流量曲線。”吳先生說。

某災備廠商告訴雷峰網，此次崩潰，可能與項目方“只做了數據級容災、沒做應用級容災”有關。

但多位技術專家也給出了相反的看法，指出應用級災備是“高投入、價值低頻且難以度量”，在大多數時候“相當于服務能力成倍冗余”。

應用級容災確實更能確保業務的連續性，但不同于云服務彈性擴容，這需要長期占用固定投資，且資源平時無法通過靈活應用產生其他價值。

我們可以把彈性擴容看作是搭帳篷，用途多變，啟用和收回也十分靈活；而應用級災備就像是直接建造一處特定用途的樓房，確實穩定堅固，但成本高出不少，因此有專家認為，“建設應用級容災并不是理想的解決辦法。”

此次粵康碼無法正常訪問，也讓許多人聯想到不久前西安一碼通的兩輪崩潰。不少各地網友表示，自己所在地的健康碼也出現過亮碼緩慢的情況。

鈦媒體的報道中指出，西安一碼通是“一起因流量過載、系統架構應對高并發不足，最終導致防火墻攔截數據無法返回的系統性故障。”也有技術專家表示，相信西安一碼通存在一定的系統架構設計硬傷，沒有充分考慮擴容的情況。

有業內人士強調，粵康碼、西安一碼通的亮碼失敗，確實都與高并發訪問有關，但無論是何地的健康碼，實際情況都不可一概而論，不意味著西安一碼通的根本問題也出現在了其他地區健康碼身上。

但需要注意的是，健康碼因高并發而亮碼緩慢、甚至崩潰的背后，不只是容災、擴容這些相對淺層的技術問題。

“健康碼是一個融合多系統的產品，不是某個單一軟件公司可以覆蓋的。”IT咨詢專家阿鯤（化名）向雷峰網分析稱，健康碼系統目前的關聯方應該包括：

信通院整合的三大運營商（定位及軌跡）；

各地的疾控中心（核酸檢測結果，疫苗接種結果）；

產品前端（微信、支付寶小程序）；

產品的運營（實際健康碼的加工和生成，數據整合，日常運營等）

其他關聯方，如云服務、防火墻的提供商。

整體架構上，應當是有一個后臺和一個前端，都架在政務云上：

后臺采集各渠道數據，包括定位軌跡，核酸，疫苗等，統一加工后生成健康碼；

前端對接各渠道，從前端獲取客戶身份信息，到后臺查詢健康碼，并生成碼值展示。

“就算各方負責的部分都沒問題，合起來也可能會有一堆毛病，就像一個人四肢健全卻無法正常行走。”另一位技術專家強調。

而項目牽頭者、實施方都有可能對健康碼的定位理解不準確，“項目是按政務系統來做的，但這是面向全網C端的大流量架構——理論上是to G，實際上應該是to G to C。”阿鯤說。

再加上健康碼的特殊性，項目上線時間緊迫，往往未能經過完整壓測；上線后又面臨巨大的運營壓力，騰不出人手和資源進行優化。因此系統的整體架構耦合太強，健壯性不夠。

同時他也強調，全國各地各自為戰，數據未整合，且各地的數據、架構都不同，導致每個省各顯神通，也和當地的信息化基礎設施密切相關，沒有統一的標準方案。

健康碼的真正考驗，是頂層設計能力和協同一致能力，是項目內部各方、項目與其他數字基礎設施的協調。在疫情聯防聯控成為日常所需的今天，這將會是每個城市長久面對的考題。

總結

以上是生活随笔為你收集整理的粤康码“崩溃”的90分钟：到底发生了什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。