2020 年 1 月中，距離春節不到 1 周的時間，微信技術架構負責人 Stephen Liu 非常焦慮，即將到來的除夕夜是一年當中微信業務最為繁忙的時刻，好幾億的用戶會在這個時刻發送新年祝福以及微信紅包，微信伺服器也經受著一年比一年更大的沖擊。
為了保障所有人都能如期收到新年祝福，搶到微信紅包，微信技術團隊在每年年底進入「春節保障」模式，進行伺服器壓力測試，確保微信不掉鏈子。
最關鍵的時刻，很棘手的問題
但是在這一個春節的測試階段，卻出了問題。
誕生於 2014 年的微信紅包，在當年春節期間就經歷過不大不小的宕機，部分用戶在部分時間領不了紅包，也看不了紅包金額。次年，微信拿下了春晚的廣告互動權。那一年除夕當日中國微信紅包收發總量達 10.1 億次，春晚微信搖一搖總量達 110 億次，這一年微信准備充分，大體上還算平穩，偶有小規模宕機。
因此，還沒到春節就出現測試問題，不是個好現象。
Stephen Liu 說：
我們當時想壓測的（目標）值大概是每分鍾下發的消息數有幾十億條，但是我們壓測到的水平只有目標的一半，當時離春節只有兩個星期了。
所謂壓測，就是對微信線上的伺服器做擴容。擴容完之後，然後進行攻擊性模擬，模擬在除夕零點那一刻的峰值數據，看看今年有可能比去年增加多少，然後把那個量完全模擬出來，壓到系統上面去。
簡單理解，就是類似於網站對自己進行 DDoS 攻擊，測試網站能經歷多少人同時訪問而不宕機。更通俗的理解是餐廳接客，淡季一家餐廳的座位和廚師只能同時接待 100 位客人，但是旺季的時候，可能同時有 300 位客人需要就餐，這個時候就需要提前擴建餐廳招聘廚師了，也就類似於「擴容」，或者實在不行就讓客人在外面排隊等位。
但微信收發消息是不能採用排隊等位方式的。
微信技術團隊和 Stephen Liu 這次遇到的問題就好像明明擴建了餐廳多招了廚師，但是同時能接待的客人只有 150 位，沒有達到 300 名的目標，並且這個時候廚師都還挺閒，座位也很空，外面還有人排隊。
微信技術團隊在此之前已經核查了大概一兩周時間，終於定位到問題：網卡性能出現了問題。再打個比方說，就是像是餐廳門口的接待員偷懶，沒把客人往屋里帶，導致餐廳里面坐不滿，外面客人排長隊。
問題背後，是一場微信不為人知的巨變
之所以往年壓測沒問題，這一年壓測有問題，涉及到微信背後的一場巨變：自研上雲。
這場巨變從 2018 年騰訊的 930 變革開始，2018 年 9 月 30 日，騰訊再次對公司架構進行大調整，原有七大事業群重組整合，新成立雲與智慧產業事業群（CSIG）、平台與內容事業群（PCG）。其中 CSIG 承擔著騰訊 ToB 的宏偉願景，而微信事業群（WXG）則是連接了最廣大的 C 端用戶。
雲，對於騰訊來說已經是戰略支點業務，從此時開始，自有業務自研上雲成為業務調整的重要事項，而微信業務自研上雲則是重中之重。
在騰訊 930 變革之前，騰訊並未給內部自研業務提供統一的雲基礎設施，而是採用物理機伺服器的模式。宏觀上講，考慮到微信巨大的用戶量和業務量，自研上雲能夠帶來巨大的成本和效率優勢，對微信和騰訊雲兩個業務都有好處。
但微觀上講，一個涉及到 10 多億用戶的業務要做如此巨變，並且要讓用戶無感，就好像需要給高速行駛的汽車換輪子，車不能停，甚至都不能顛簸，同時輪子也要換。
前面壓測出現問題，就出現在換輪子的過程中。
實際上，輪子也確實到了該換的時候了，Stephen Liu 說：
2014 年微信只是一個部門。當時公司提了這麼一個成本優化的想法的時候，我們自己還挺緊張的，因為當時部門的人不是很多，當時只是一個部門，那個時候也就三四百號人。在 2014 年之前，微信所有的人力都撲在做功能疊代，不斷打磨新的功能，所以對於後台的伺服器用得怎麼樣，包括架構做得怎麼樣，對這些關注得比較少。
那公司又有這個要求，後來公司就安排了人對每個業務部門去看做得怎麼樣，最後選派了非常有經驗的人。像當時帶隊的也是公司的 VP，反正我非常有印象，因為我被他批了很多次。就說微信這邊的成本非常高，你們伺服器用得不好。
▲ 微信曾經的報告 PPT
這次降本增效的要求促使了微信團隊第一次進行伺服器架構的優化，當時採用了名為 YARD 的系統架構。
但是這次自研上雲則需要和騰訊公司保持一致，採用開源的 K8S 系統架構，相比於 YARD，K8S 架構更為開放，在適配人工智慧和大數據框架等等方面有先天優勢。而現在微信的諸多功能都與人工智慧和大數據有關，比如語音轉文字，還有文字翻譯功能。
或者說， 2014 年微信採用 YARD 架構目的很簡單，就是幫助靈活調度伺服器資源，節省成本，並未考慮更復雜更長遠，而當時 K8S 也沒有開源。
隨著業務發展時間前行，K8S 架構的優勢逐漸蓋過架構遷移的陣痛，又恰逢騰訊業務變革，這場改變勢在必行。
微信基礎架構工程師 Edsel Wang 告訴愛范兒微信自研上雲的宏觀步驟：
對於微信團隊來說，上雲可以分成狹義和廣義兩個層面。狹義的上雲就是 2018 年 930 變革，公司 930 變革之後公司推動了自研上雲這件事情，然後微信開始使用公司提供的統一的雲基礎設施。廣義上上雲，就是微信把整個研發模式逐漸雲原生化，這里就不單純包括把一些後台的服務從原來的物理機搬到雲上，當然這里還包括整個研發過程會跟雲做一個結合。
針對 2018 年 930 變革之後，公司推動自研上雲這件事情到目前為止也是經歷了兩個階段。第一個階段是 2018 年到 2020 年這個時間點，公司主要改變了提供伺服器的方式，就是從原來提供物理機改為 CVM（Cloud Virtual Machine，雲虛擬機）。第二個階段的時間點是從 2020 年開始，公司進一步要求各個業務部門把內部的一些調度系統統一改為 K8S，這個對我們來說，就是從 YARD 遷移到 K8S 上。 在第一個階段，從原來的物理機改為使用 CVM 這一塊，由於我們設計了 YARD 作為它的調度層，所以我們的主要工作是讓 YARD 適配雲，因為 YARD 原來是支持物理機的，現在就是 YARD 支持 CVM 虛擬機，而業務層是不需要做很多改變的。
在第二個階段，對於微信團隊來說，就是要用 K8S，就是用騰訊雲提供的 K8S 集群的調度能力替代掉自研的 YARD 平台。為了使這個遷移更加順滑，我們在用 K8S 替代 YARD 過程中規劃了三步走。 第一步，首先要解決微信能不能上 K8S 跑的問題，那個程序能不能上去跑的問題。第二步是要把 YARD 原來積累的一些經驗移植到 K8S，讓 K8S 跟 YARD 原來的能力對齊，可以接著使用原來 YARD 提供的所有能力。第三步，我們要充分發揮 K8S 的能力，因為前兩步 YARD 提供的我們都提供了，第三步我們就要更充分地使用 K8S 的能力，這塊主要體現在成本、效率上。
2020 年之前我們就完成了前兩步，從 2020 年的下半年我們開始大規模使用 K8S，2021 年開始進入到了第三步。從目前看，我們的成本和研效都有了進一步的提升，相對於原來 YARD。 還有從廣義上雲的角度來說，之前推動上 CVM 虛擬機這一塊，微信團隊還有一個標志性的事件，就是存儲團隊也在上雲這一塊有了一個突破，因為微信一直用的是自研的存儲系統，在過去十年我們經歷了很多不同的 DB（Data Base，資料庫）還有 KV（Key-Value，一種資料庫系統），最終在 infinityKV 的版本實現了存儲上雲的能力。在 2020 年下半年，infinityKV 開始上線，微信後台大概有 80% 的數據存儲在現在的 infinityKV 這個新系統里面的。
這是我提到的微信上雲（過程），就是把大象搬進冰箱有幾步（的過程）。
Edsel Wang 進一步介紹了 YARD 逐漸顯現的局限性，在 2014 年的時候整個行業對於雲平台的定義都不是很清晰，另外一方面，騰訊的硬體環境跟現在的雲硬體的環境有比較大的區別。YARD 是在當時那一種硬體環境下研發和設計的，導致它在一些核心能力上比如磁碟和網卡的虛擬化，是有所欠缺的。
開頭微信在自研上雲過程中出現的壓測問題，就定位在了網卡這里，原因是騰訊雲當時使用了一個新的機型，CVM 作業系統和硬體的適配還不夠好。
最後，微信技術架構團隊通過曲線救國的方法，短暫地解決了 CPU 負載小，但是網卡性能出現瓶頸的問題。簡單講，就是如果原來伺服器整機 CPU 有 180 個核心，切片之後 90 個核心配 1 個網卡，結果網卡負載滿了，CPU 負載只有 20% 左右。微信技術架構團隊重新對 CPU 核心進行切分，改成 48 個 CPU 核心對應 1 個網卡，讓 CPU 負載過半，充分利用性能的同時，網卡負載也不到瓶頸。
這是治標的辦法，這是治標的辦法，治本的辦法就是 CVM 優化網卡調度程序。CVM 網卡調度程序優化加上遷移到 K8S，讓微信後台能夠更有效地控制網絡流量，進一步提升了微信後台部署的靈活性和穩定性。
變化不可怕，可怕的是不變化
2013 年的時候，微信出現了時長最久的宕機。因為有挖掘機挖斷了通信光纜，導致華東數據處理中心的業務請求紛紛轉向華南和華北，進而導致長達 5 個多小時的微信服務癱瘓。
自此，在次年部署 YARD 架構的時候，微信做了一個重要功能：三園區支持。就是在每個城市建造三個機房（園區），機房的網絡和電力獨立，哪怕其中一個被挖斷光纖，還有另外 2 個作為支持。
這便是現在伺服器部署中常見的「冗餘」概念。
現在自研上雲之後，不光是伺服器資源虛擬化了，新的 K8S 架構能夠更進一步，伺服器資源屬於騰訊整個公司，這個資源量級就大多了，「冗餘」也更多了。這就像貸款一樣，之前微信是從市級支行貸款，現在則是從省總行貸款。
在微信迄今 11 年的歷史中，微信的定義也是在不斷變化的。朋友圈，微信紅包，小程序，視頻號等等節點性的功能一次次讓微信的定義拓展，它是社交網絡，是支付工具，也是內容平台。
微信背後的伺服器支撐，也正是面對的這樣一個不斷變化的過程。
早些時候，北京的一場初雪導致當地用戶拚命發朋友圈也會導致伺服器需求瞬時加大，這種時候就需要響應很快的擴容。
但某地的天氣變化和用戶行為是難以預期的，春節和除夕夜零點集體發紅包是一種必然，類似的必然還有很多，比如周杰倫的演唱會視頻號直播，數千萬的觀看是對微信伺服器的巨大考驗，但這是可以進行壓力測試，提前部署的。
回憶起去年 9 月的一場直播，視頻號後台開發工程師 Bok Zhou 依舊覺得驚險。
他介紹說，得益於上雲之後的優勢，遇到這種預期外的流量劇增，微信團隊也可以更快地上線更多伺服器資源，避免部分用戶看不了直播。
自研上雲也是個長期且不斷變化的過程，優勢也會慢慢挖掘出來，現在也不是這個過程的終點，但有些優勢和願景已經可以預料。
微信技術架構負責人 Stephen Liu 說：
在一年多以前我跟團隊有分享過一個觀點，我就拿自動駕駛 5 個 Level 來類比。Level 0 是人工駕駛，完全沒有自動化。Level 1 是有一些駕駛輔助，Level 2 是更強的駕駛輔助，Level 3 已經具備一定的自動駕駛能力了，然後還有 Level 4 和 Level5。
我的一個希望，就是將來能夠達成像自動駕駛一樣，將來春節保障的時候能夠完全由機器來自動駕駛。我們幾年前可能在 Level 0。後來有了 YARD 之後，是 Level 1。經過 2021 年整個去挖掘 K8S 的各種能力之後，我覺得我們現在應該處在 Level 2 狀態。我希望接下來能夠到 Level 3，有比較完善的自動化駕駛功能。
來源：愛范兒
