昨天早上，天津和深圳兩個進行全員核酸檢測的城市，健康碼都崩了一次，服務在幾小時後恢復，但是我想說，健康碼在一天內進行全員核酸檢測的大背景下，因為流量洪峰而發生崩潰的事，其實挺正常的。
因為流量洪峰帶來的高併發壓力，是小公司無法承受的。非IT人士，可能對流量洪峰的力量一無所知，我舉幾個例子說明一下就能感受了。
1、對於雙十一來說，壓力最大的是什麼？是流量洪峰，以及隨之而來的海量訂單以及支付結算的任務。
對於流量洪峰，大家可以回憶一下春晚的盛況。微信紅包在2015年初次在春晚亮相，結果流量洪峰直接打爆了微信的服務，0點到1點，紅包根本發不出去；
然後在2018年春晚，阿里搶五福給全國人民發紅包的時候， 準備了三倍於“雙11”的伺服器資源。
2019年春晚，百度發紅包的時候，按照每秒峰值流量5000萬，準備了10萬臺伺服器，其中採購了5萬臺伺服器，資源不足的部分，甚至讓自己的現金牛業務——鳳巢系統（廣告）熄火，把伺服器資源讓出來給春晚紅包。
然而，就在8點半前後，在春晚主持人口播大家可以下載百度APP領紅包之後，連蘋果的軟體商店也被流量洪峰瞬間打爆了；其他安卓應用商店也紛紛跪倒在流量洪峰下，絕無例外。所以大家可以體驗到流量洪峰的威力。
我們剛剛說的還僅僅是伺服器端的資源消耗量；為了給大家提供服務，網際網路公司還要採購大量的頻寬資源，比如騰訊為了給10億使用者提供遊戲、影片和公有云服務，在全球採購了超過100TB的頻寬。
但一碼通的實際情況比這複雜得多，解決流量洪峰的難度也會更大。就以粵康碼自己釋出的，在1月10日最高峰值流量達到140萬/分鐘來簡化分析，問題可能出在接入閘道器上（我儘量說得淺顯易懂，所以請專家輕噴）。
1、粵康碼每分鐘140萬次訪問請求經過微信小程式，第一步會抵達騰訊RIO智慧閘道器，智慧閘道器作為公網到政務網的第一道入口，就像醫院的分診臺一樣，實現流量控制、負載均衡等功能。
根據廣州日報的報道，因為2021年5-6月的廣州疫情，粵康碼進行了系統調優升級，將「閘道器每分鐘可承載的訪問量從原來的10萬+提升至60萬+，每天的呼叫量從原來的10億+提升至80億+。」
打個簡單的比方，我們在銀行排隊的時候，如果取錢的人多，哪怕銀行金庫裡有足夠的現金，也需要銀行多開幾個視窗，才能儘快給所有使用者辦完業務。
而粵康碼的智慧閘道器承載量是每分鐘60萬，突然漲到140萬，怎麼可能不卡呢？而且作為終端使用者來說，如果健康碼重新整理失敗，那一定會反覆重新整理，也會帶來新的使用者請求。
當閘道器的承載量超出設計值的時候，就像在高速公路收費站入口處排起了長龍一樣，除非能夠瞬間變出一排收費站，否則堵車就無法避免，就像下圖的2019年廣東高速收費站堵車一樣。
騰訊RIO智慧閘道器的硬體，包括邏輯伺服器和儲存伺服器兩部分，雖然支援橫向擴充套件的，但是橫向擴充套件智慧閘道器硬體資源同樣需要時間。
需要哪些時間呢？我們看看下面這張圖就能明白了。
運維團隊突然發現服務卡頓甚至崩潰，他們首先需要定位問題，到底是流量洪峰的問題，應用伺服器宕機，還是後端資料庫讀寫故障，這需要時間。
當問題定位出來，是因為移動裝置訪問量突然暴增，流量經過網際網路區的防火牆到達接入閘道器後，接入閘道器被流量洪峰打爆，這才找到了問題的解決方案——急需擴容。
但是擴容並不是領導下個命令就能一分鐘搞定的，運維人員需要先協調出可以使用的DMZ區伺服器資源（很可能沒有現成的，需要硬擠出來），然後在上面開通智慧閘道器服務，所以安裝部署需要時間，10分鐘左右。
新的伺服器需要開通防火牆策略，按照政務網的安全要求，防火牆策略需要由政府側的安全團隊負責，並且完成一個申請-審批-開通的流程，最後由某個網路管理員開通防火牆策略，這需要時間，15分鐘左右。
現在的業務應用前端大多采用微服務架構，支援彈性伸縮，但是彈性伸縮同樣需要時間，比如1分鐘左右；
現在的業務應用後端仍然有一個支援高併發的關係型資料庫，比如騰訊的TDSQL，資料庫可能需要做例項升級（擴容分片、例項分片），升級完成後還需要校驗，確保資料一致。這大約需要10分鐘左右。
在這個過程中，還會有各級領導打來電話詢問情況，關心進度；操作人員忙裡出錯，敲錯程式碼；關鍵時刻電腦卡頓重啟；硬體資源協調不到位等各種問題——倒黴事絕對不會只發生一件的。
所以如果一碼通因為流量洪峰導致宕機，需要擴容的話，能在兩個小時裡恢復服務的，背後都肯定有一支召之即來來之能戰的靠譜運維團隊，一個各級負責人能快速反應審批的政府機構，一批相對冗餘的硬體和頻寬資，還有效能穩定可快速橫向擴充套件的軟體系統，比如騰訊里約RIO智慧閘道器和TDSQL分散式資料庫這種。
為什麼不多準備一點資源？
因為面對千萬量級的使用者，開發者必須在使用者體驗（可用性、響應速度、一致性）和服務成本（頻寬、伺服器、交換機、防火牆、運維人員）之間去做平衡。
根據CAP理論，這種面對網際網路海量使用者的分散式系統，是不可能同時滿足一致性、可用性和容錯性的；一碼通這種使用政府預算建設，又要求容錯性的，開發者只能在一致性和可用性中做平衡。
而一個城市突如其來的疫情，會導致城市管理者快速做出「全員核酸檢測」、「全員亮碼」、「全員展示核酸檢測結果」這樣的決策，這樣的決策必然會帶來流量洪峰，而且是無法預測的——建設者和開發者沒法為了無法預測的事情去無限制的申請預算。
開發者只能採用一些變通的方式。比如2020年阿里的雙十一，訂單峰值為6100萬/秒，但是整體的購物感受卻比較順滑，原因就是技術人員用時間換取了空間。
比如2020雙十一，所有預付定金的商品都要等到1點後才能付款，這就有效地降低了0點開始時的支付和結算的資料處理洪峰。
零點，工程師先把大部分計算資源分配給交易等應用，讓大家愉快地清空購物車；過了1點後，再把這部分資源空出來，重新拉起交易和結算的微服務，供預付定金的使用者下單結算，這樣就有效分擔了壓力。
另外，透過雙十一二十多天的預熱，很多使用者領了優惠券，預付了定金，收藏好了購物車，這就有了預測的一句，工程師可以有預見性地準備足量的前端計算資源、快取資源、訊息佇列、資料庫等資源，並做好一定的冗餘。
在零點之前，工程師已經進行了資料庫、快取、訊息、前端的預熱，有效避免零點大量流量湧入時，前端、中臺和後端之間還要浪費2ms握手建立連線，以免使用者體驗到卡頓。
可阿里能做得好的原因，是因為雙十一是一場在固定時間固定地點開打的戰役，整個團隊在之前就做好了充足的演練。
阿里會在10月進行3次全鏈路壓測驗證；每次全鏈路壓測，都會有跨多個事業群的技術人員參加，保底1000人。阿里的全鏈路壓測技術已經成熟，壓測可以在影子系統中進行全天候的測試，而不會影響核心系統。
可對於一個城市的一碼通來說，是不具備這樣的海量資源的。所以，隨著春節帶來的人流量，很可能在某些城市爆發疫情，然後政府仍然會進行全員核酸全員亮碼，那時候也一定會有健康碼被流量洪峰打爆。
友情建議各大中型城市趕緊升級一下一碼通的軟硬體配置，天津（直轄市）和西安（獨立一碼通）的硬體配置就是最好的參考指標，粵康碼支援整個廣東，其實參考性不大。
畢竟，如果能花一兩千萬避免一碼通在關鍵時刻碼不亮，其實也是蠻值得的。
春節快到了，祝各位讀者大大都能過上一個安定、祥和、闔家歡樂的新年！
