中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

墨菲定律中有這樣一條：如果你擔心某種情況發生，那么它就更有可能發生。

1月28日，除夕前倒數第二天那個下午，“新年紅包”的圖標第一次出現在“我的銀行卡”界面中，微信紅包潮隨即引爆全國。

驚險瞬間在除夕夜一觸即發，春節紅包團隊迅速啟動了過載保護。過載用戶想發紅包時，系統會提示“當前系統繁忙”。除夕夜還在加班的程序員們就像是交警一樣，在一條堵死的十字路口上不斷控制流量。

幸好，當時騰訊FIT技術團隊臨時調來了10倍于原設計數量的服務器，最終有驚無險地扛住了考驗。

此一役后，安全、容災、性能成了每個春節紅包團隊需要長期考慮的問題。在2016年以后，騰訊FIT技術逐漸為春節紅包構建了一套“多點多活、多地多中心”的分布式交易系統。

后來的微信紅包、支付寶紅包背后的云計算團隊每年都需要“一把屎一把尿”，不斷改進春晚紅包的技術框架，除夕這天加班加點避免紅包宕機。

創業邦在2017年就曾以《支付寶17年新春紅包技術體系剖析》一文介紹螞蟻金服技術團隊在春晚前的技術準備，其中這樣一段非常值得注意：

螞蟻金服在終端上采用了限流無感知、資源預下載、用戶操作數據緩存、開獎時間離散、數據項與開關動態配置等穩定性操作；在服務端，進行了全鏈路梳理、全鏈路壓測、限流保護、應急熔斷機制等。

百度今年也不例外。2019年1月4日收到百度春晚要發紅包的消息后，百度技術團隊首先要想的問題是，如何搭建春晚紅包的技術框架，原因很復雜。

百度APP不像微信是個日常應用，它是一個剛需但低頻的工具型APP，用戶用完即走，不會保持長時間在線。但在春晚期間，用戶搶紅包、集卡會使得使用時長、操作頻次大大提高。

同時，春晚紅包涉及百度數十個產品、數百個操作場景，這會給百度APP帶來高并發、大流量，同時給百度云的服務器、帶寬等技術基礎設施帶來巨大沖擊。后果可能是用戶打開百度APP緩慢，無法登錄賬號，點擊界面無反應，甚至白屏，更別說搶紅包。

因此，百度技術團隊需要梳理的問題很多，甚至比騰訊FIT、阿里云團隊更要繁瑣：

1. 需要針對本次春晚的突發需求，讓外網骨干網可以支撐大帶寬快速接入；
2. 技術方案確定后，還要解決資源供應問題。比如要在2周內采購到貨3000臺服務器。還需要運營商資源為百度核心IDC提供近10T帶寬和數十個CDN節點等資源；
3. 準備時間過短引發運營商資源提供方面的許多問題，比如商務部門需要和50多個城市的CDN運營商資源緊急談判；
4. 外部對接結束之后，內部技術團隊還需要進行資源部署、系統聯調、壓力測試。

可以說，2019年以前，幾乎每一個春晚紅包團隊，都會遭到煉獄一般的技術考驗，從騰訊到阿里無一幸免。然而，2019年春晚，百度APP的“零宕機”紀錄是互聯網公司的首創。

你開心搶紅包時，程序員卻在心驚膽戰

春晚時，每一個人都在開心搶紅包。你以為只是頁面偶爾卡頓了一下、網絡延遲了1秒，實際上背后有著無數個技術團隊的“緊張時刻”。每一個程序員都是心驚膽戰，時時刻刻準備著對系統進行搶救。

對于2019年的春晚紅包而言，期間也是考驗頻頻，而背后的百度技術團隊總算讓這場紅包狂歡有驚無險。

簡單說，春晚紅包帶來的技術難點基本是這幾個：不可預見的峰值流量瞬間涌入，紅包系統架構復雜帶來了協調成本，春節返鄉導致地區間流量資源分配要臨時調整。

1. 不可預見的峰值流量瞬間涌入

淘寶春晚項目技術負責人此前在2018年春晚淘寶多次崩潰時曾出面解釋其中的原因——我們真的對春晚的力量一無所知。

以2018年春晚為例，當時淘寶是那年春晚的主角，主要策略是綁親情賬號、發紅包。技術團隊很早就預估到了登錄系統壓力。當時基于一些歷史數據推導出了極端情況，最終決定以2017年雙十一的容量為基礎，對登錄數擴容3倍。

結果，春晚當晚登錄的實際峰值超過了2017年雙十一的15倍，尤其新用戶的瞬時登錄更是完全超出預料。

可以說，互聯網公司上春晚，等于是往下沉市場扔了一顆炸彈——這一次據百度技術部門統計，春晚期間登錄值可達到日常用戶登錄峰值的2500倍。

大量用戶在同一時間發、搶紅包、點頁面，瞬間產生每秒千萬級，甚至億級的請求，請求如果不加以疏導處理直接到達后臺，會導致服務過載甚至崩潰。

為完成今年春晚的高并發流量考驗，百度提前進行服務流量隔離、系統升級、專線新增以及服務器擴容等工作，完善流量峰值時段的體驗，還進行了多輪全鏈路壓力測試和多輪的方案預演。

今年春晚百度APP也的確相對平穩，沒有出現崩潰的情況。

2. 紅包系統架構復雜帶來了協調成本

和淘寶注冊、登陸系統還不一樣，注冊登陸一般只有一次響應，注冊登陸之后響應就結束了。今年百度的紅包系統更多是支付系統，支付系統的響應次數往往是多次的，而且表面上看，一個紅包從發出到搶到時間不足一秒，但背后是在紅包業務系統、交易支付系統、零錢賬戶系統這三個層級之間游走——它需要多方提前溝通測試。

因為一個紅包如果是通過銀行卡發出，必須要先向銀行提出申請，銀行會進行扣款，扣款成功后，后臺會通知支付系統，紅包系統到這時才會把紅包放出。在其他用戶搶到紅包后，又會以零錢形式進入用戶賬戶中。

紅包幾秒鐘現金出出進進，都需要耗費服務器資源，由于資金頻繁進出銀行，部分銀行的技術能力又非常有限，百度也需要和銀行前期協調，進行承壓測試。

百度工程效率部對用戶剛登錄APP時的內容加載進行了優化。后臺系統還會自動檢測流量變化，快速計算資源，智能調度早已準備好的冗余資源，增加系統容量，合理分配帶寬。這些措施可以讓數億級用戶同步登錄APP，正常加載服務，不出現白屏。

3. 春節返鄉導致地區間流量資源分配要臨時調整

搶紅包的指令是從全國不同地區下達的，服務器還需要根據不同地區進行響應。

百度系統部一位負責人就提到，因為回家過年，網民會從一線城市下沉到三四線城市。這使得流量結構發生改變，DC數據中心和CDN帶寬不得不進行調整。

阿里云2017年也曾遇到過這個問題，當時的解決方案還相對簡單。螞蟻金服技術專家天鏡飛在2017年的一場活動中就曾提到阿里是如何應對流量結構變化這個問題的：

華東1機房和華南機房分別承擔40%和60%的流量，并且它們都是非云的機器。在新春紅包業務上，支付寶將60%的流量切到華東2機房中，并且將其上云。

此外，在華南機房會部署15%的云機器。也就是說，新春紅包業務中，75%的機器是在云上運行的，在活動結束后，流量又會切出。

不過，百度吸取前人教訓后，把這種應對策略進行了改進調整：提前規劃好了不同地區的所需要的網絡資源。通過智能調度系統，分鐘感知不同地區資源緊張程度，并進行相對應的資源調度和補給。也就是說，流量資源調度分配更智能了。

在這個系統中，整個體系就像一個彈性容器，可以全自動自如擴容縮容。

云計算從“雙十一時代”邁向“春晚時代”

2014年-2019年這6年間，BAT應對春晚紅包的技術一直處于進步之中。

從最早的懵懵懂懂、毫無認知，對技術難點預估不足，到后來每年都會提前做好準備，但依舊要靠熔斷機制來限制流量。再到今天限制為輔，分布式、自動化、智能化為主，云計算技術不斷在演進之中。

• 分布式：紅包系統可適性強。高度靈活，能應對多種不同環境。某個部件發生突變，不會影響整個系統。在某些部件失效的情況下，仍然能夠應對響應，抗風險能力高。
• 自動化：基于需求預期和流量模式進行自動合理規劃，不需要太多人工干預，保持相對較低的運營成本。
• 彈性化：可彈性擴展的資源用量，在高峰期可以根據需求按需所取、彈性分配，系統如同彈簧一般可以根據用戶搶紅包的需求來自動分配資源。

百度使用這樣的技術架構中，使得整個技術保障體系就像一個彈性容器，可以全自動自如擴容縮容。當遇到流量洪峰時，系統智能化調度，快速接入帶寬資源，據用戶任務的不同，匹配適應的容量。

凱文凱利在《失控》一書中曾提到蜂群的一個特征：

蜂群的能力不會因為其中幾個成員的損失而喪失機能……必須從簡單的局部控制中衍生出分布式控制，必須從已有運作良好的簡單系統上衍生出復雜系統。

這段話拿來形容春晚紅包這幾年來的技術演進再恰當不過了。

在當年的雙十一時代，互聯網公司的云計算基礎設施用來應付每年一度活動期的瞬時高峰流量，但畢竟運用電商的人還是有限的。在如今的春晚時代，流量有了數十倍的增長，互聯網公司需要更龐大的云計算基礎設施來應對。

正如我在《春晚紅包宕機史,也是半部中國互聯網技術進步史》中所說的：

春晚的流量規模，未來可能正是5G和物聯網時代的“常規需求”。提前排兵布陣，百利無一害。

要知道，2018年全球有70億臺IoT設備，有機構預測到2020年全球將有500億臺設備同時連接網絡，2023年則是有790億設備連接到物聯網。5G時代流量每小時所產生的數據高達數百GB，預計將處理比4G多1000倍的數據。

春晚紅包的挑戰，正是提前練兵的好時機。這場看不見的云計算戰爭，推動了中國互聯網技術整體演進。

如果說過去的云計算還停留在“雙十一時代”。BAT歷經的春晚紅包戰之后，云計算正在邁向“春晚時代”。

#專欄作家#

吳俊宇，微信公眾號“深幾度”。獨立撰稿人，人人都是產品經理專欄作家。關注人工智能、移動互聯網以及數碼家電的產業融合。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議