昨天早上,天津和深圳兩個進行全員核酸檢測的城市,健康碼都崩了一次,服務在幾小時後恢復,但是我想說,健康碼在一天內進行全員核酸檢測的大背景下,因為流量洪峰而發生崩潰的事,其實挺正常的。
因為流量洪峰帶來的高併發壓力,是小公司無法承受的。非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人。阿里的全鏈路壓測技術已經成熟,壓測可以在影子系統中進行全天候的測試,而不會影響核心系統。
可對於一個城市的一碼通來說,是不具備這樣的海量資源的。所以,隨著春節帶來的人流量,很可能在某些城市爆發疫情,然後政府仍然會進行全員核酸全員亮碼,那時候也一定會有健康碼被流量洪峰打爆。
友情建議各大中型城市趕緊升級一下一碼通的軟硬體配置,天津(直轄市)和西安(獨立一碼通)的硬體配置就是最好的參考指標,粵康碼支援整個廣東,其實參考性不大。
畢竟,如果能花一兩千萬避免一碼通在關鍵時刻碼不亮,其實也是蠻值得的。
春節快到了,祝各位讀者大大都能過上一個安定、祥和、闔家歡樂的新年!