0
今天上午8:30左右，不少用戶集中反映，“粵省事”小程序里的“粵康碼”打不開了。
在亮碼的過程中，頁面會出現“信號不佳”的提示，或是直接呈現黑白二維碼，表示“亮碼失敗”。
下方的“核酸檢測”和“疫苗接種”兩欄都注明“升級維護，請稍后再試”。
圖左為正常訪問；圖右為亮碼失敗
#粵康碼#、#粵康碼崩了#等詞條迅速登上微博熱搜。
事發六小時后，熱搜詞條仍然在榜
上午10:00之后，情況逐漸得到緩解。也有網友向雷峰網表示，自己的粵康碼在十點左右還是黑白，但在十點半左右已經可以正常打開。
今日午間，當市民再度打開“粵省事”小程序里的“粵康碼”，頁面會首先顯示公告稱：
8:31，監測到流量增大；
9:04，部分緩解；
9:56，完全恢復順暢運行。
而在粵康碼崩潰的90分鐘里，微信小程序“深i您”、“穗康碼”，以及由國家政務服務平臺提供服務的支付寶健康碼，均可正常使用。
微信小程序“深i您”界面
“應該只有‘粵省事’這個渠道出了問題。‘深i您’和‘穗康碼’都分別注明了‘粵康碼（深圳/廣州）’的字樣，但一樣可以正常打開。”有網友評論道。
公開資料顯示，數字廣東公司是粵康碼系統以及全省數字政府建設的運營中心。“粵省事”移動政務服務平臺，由騰訊與廣東省合作開發。
在1月7日到1月9日的三天時間里，深圳新增四例本土確診病例，深圳多區同時展開大規模核酸篩查。深圳以及廣東其他市縣的不少公共場所，都新增了入場前先亮健康碼和核酸證明的防疫要求。
而今天（1月10日）正是深圳“0107疫情”發生之后的第一個工作日，不少上班族正是在進入地鐵和辦公園區的時候，發現粵康碼打不開了。
這次故障的主要原因，多位業內人士表示，應該還是與高并發訪問有關。
官方聲明中提到：
今早的訪問量峰值一度高達140萬次/分鐘。
而根據廣州日報的報道，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。”阿鯤說。
再加上健康碼的特殊性，項目上線時間緊迫，往往未能經過完整壓測；上線后又面臨巨大的運營壓力，騰不出人手和資源進行優化。因此系統的整體架構耦合太強，健壯性不夠。
同時他也強調，全國各地各自為戰，數據未整合，且各地的數據、架構都不同，導致每個省各顯神通，也和當地的信息化基礎設施密切相關，沒有統一的標準方案。
健康碼的真正考驗，是頂層設計能力和協同一致能力，是項目內部各方、項目與其他數字基礎設施的協調。在疫情聯防聯控成為日常所需的今天，這將會是每個城市長久面對的考題。
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
