嗯。。。
有關西安健康碼系統連着崩了兩次的新聞已經在網上發酵了好幾天，想必差友們差不多都知道了。
負責健康碼平台搭建的部門上司也在昨天被停了職，算是給了大家一個交待。
不過就在今天差評君發現，西安的健康碼又被沖上了知乎熱搜。
原因其實不複雜，就是去年 6 月份，一篇關于西安 “ 一碼通 ” （ 健康碼 ）的報道被大家給翻了出來。
報道的内容差不多就是，一碼通團隊的成員吃苦耐勞，不眠不休，解決了重重險阻，為疫情防控發揮了巨大的作用巴拉巴拉。
報道不算太長，感興趣的小夥伴有時間可以自己去搜搜看看。
假如前幾天西安的健康碼沒有兩連崩，那麼這篇報道怎麼寫都行，也不會有人在意。
“ 有了一碼通，防疫更輕松 ” ▼
但是就在疫情防控的檔口，西安的健康碼 gg 了。
于是這篇文章就成了大家分析 “一碼通為什麼會崩潰” 的一道技術資料。
結果大家讀完之後發現：哦 ~ 原來你們花了兩天兩夜，把 1 MB 的圖檔給壓縮到了 100 KB。
大小隻有原來的 1/10 ，好厲害啊。
對技術稍微有所了解的差友們可能已經聽出來了，我是在陰陽怪氣。
是的，我就是在陰陽怪氣。
不是我吹，别看我就是個臭寫字的，但是我隻用了 30 秒，就想到了兩種辦法，把一張健康碼圖檔的大小壓縮十倍：
1 ）使用 jpg/webp/heif 等格式對健康碼進行重編碼；
2 ）使用 svg 矢量圖形繪制健康碼；
第一種方法其實大家都會，就是找個圖像壓縮工具給圖檔轉個碼。
别說 100KB ， 10KB 都能壓給你看。
第二種方法則是用 HTML 代碼把圖檔元素寫出來。
最終實作的檔案大小也比普通圖檔要小。
而且最關鍵的是，以上這兩種方法，都有成熟的代碼可抄。
随便 GayHub 一搜，不論你是想跑在伺服器裡，還是跑在浏覽器裡，隻要複制粘貼幾行代碼粘貼一下。
一分鐘，什麼配套庫配套依賴都給你安排上，怎麼可能兩天兩夜守在電腦前面幹這事。。。
幾百款作業任君挑選。。。▼
而且假如 “ 一碼通 ” 的團隊真就這麼獨立純手搓，知乎大佬 DBinary 也幫他們嘗試了一下。
結果是一個人、一副鍵盤、一個半小時。。。
是以假如西安的一碼通團隊真的花了兩天兩夜研究圖檔壓縮的事。。。
我看不懂，但我大受震撼。
而且實際上，有好事的熱心網友也對西安健康碼的網頁活動做了元素審計。
結果發現健康碼本身就是以字元串的形式傳輸，然後再在手機本地根據字元串生成的二維碼圖檔。
而從一碼通伺服器傳輸過來的字元串本身，壓根不會超過 1KB 。。。
至于那篇報道裡提到的圖檔壓縮，大機率壓縮的是下面截圖裡的這兩張。。。
而不是我們腦補的健康碼本身。
其實吧。。。就像大家說的那樣，寫這篇報道的作者大機率平常是不怎麼接觸技術的。
比如說，不知道差友們還記不記得，去年我們聊過的阿裡 “ 全球第一 ” 的那個視訊編碼器。。。
是以那位記者發出來一篇看起來很厲害、但其實戳不到技術痛點的文章，還是挺正常的。
很可能可能一碼通團隊定位這個圖檔負載問題的時候是有一定技術成本的，但是落實到筆頭的時候，記者隻 get 到了第一層。。。
不過這些都是題外話了。
是以到底為什麼，西安的健康碼會連着崩了兩次呢？
我也和幾個有過類似項目開發經驗的小夥伴聊了聊，最後大家得出的結論是：資料庫沒抗住。
因為根據公開的報道看，西安的一碼通平台去年就已經把網絡出口擴容到萬兆了，今年還有可能更高。
伺服器一開始的時候隻有八台，但是這一年多的時間裡一碼通也投入了幾百萬去購買雲服務設施。
可以說從這個規模上來看，就算你真的一張圖檔有 1MB ，就算靜态資源和接口都放在同一個域名上，幾十萬人同時通路頂多卡點，不至于整個系統崩掉。
但資料庫這個玩意，就很玄學了。。。
它每秒鐘的承載能力如何，跟表單的大小、制式、内外存的讀寫速度、主控端處理器的運算速度、以及網絡的吞吐能力都有關系。
要不然美國的甲骨文（ Oracle ）公司也不能光靠研發資料庫軟體和解決方案，把自己整成了全球 500 強，市值上萬億。。。
尤其是健康碼這種數字基建，容納的幾乎是全市的人口資訊，外加上它本身還要和更上一級的健康碼系統勾連，和疫苗資料、核酸資料、行程資料等等資料庫系統對接。
拉取一個健康碼背後的邏輯，不可謂不複雜。
假如健康碼的資料庫在一開始沒選好型，隔離沒做好，那麼一旦後期負載起來了，再發現負載瓶頸的話，大機率就隻能靠燒錢的方式擴容堆伺服器的性能來解決了。
（ 不過以上這些也隻是差評君和一些小夥伴的猜測，假如有小夥伴有更準确的内幕消息，歡迎打臉 ~ ）
其實吧，差評君跟大家叭叭了這麼多，多少有那麼點馬後炮的意思。
畢竟當時國内所有開發健康碼的團隊都是第一次，沒有前車之鑒的情況下做出來的産品性能低一些，也可以了解。
但是光就這兩次全員核酸時的健康碼崩潰來說，顯然是西安一碼通對于将會有多少人同時調用服務沒個準确的估算，擴容不到位。
這種本來可以避免的徒勞為什麼會發生，我不了解。
以前，微網誌上一有點明星離婚一類的不可預測事件，伺服器就得被吃瓜群衆搞的當機。
之後胡忠想就會跑出來說，啊太突然啦，我們已經在緊急擴容了。
不出半個小時，微網誌的服務就會開始逐漸恢複，大家繼續該幹嘛幹嘛。
但是健康碼不是微網誌，全員核酸也不是什麼不可預測事件。
這個鍋，西安的一碼通還是好好背好吧。
哎，說一千道一萬，現在大家希望的，其實隻是西安的一碼通團隊能夠吸取這兩次的教訓。
畢竟， “ 助力抗疫 ” 的健康碼可不該如此跳脫，變成抗疫道路上的阻力。
撰文：米羅編輯：小鑫鑫 & 結界
參考資料：
知乎，西安電信一碼通項目此前報道中提到「兩天兩夜把 1m 圖檔優化到100kb」，圖像壓縮技術難度是怎樣的？，養貓的哈士奇、DBinary 等人的回答