Gmail 的第一位產(chǎn)品經(jīng)理Paul Buchheit說，最好的產(chǎn)品會(huì)讓人一旦用上，就再無法想象沒有它們的生活。這句話一直貫徹在全球接近20億用戶的Gmail身上，而如果在中國找一個(gè)樣本，微信再恰當(dāng)不過。

一個(gè)在中國生活卻沒有微信帳戶的人現(xiàn)在 已足夠成為一個(gè)故事，但一個(gè)國民產(chǎn)品的煎熬也在于此。6月16日上午，微信支付短暫出現(xiàn)異常即上了熱搜，在它身上發(fā)生的任何閃失都會(huì)引發(fā)一種集體性的不適。這種謹(jǐn)慎讓微信無法成為一款在功能上嗅覺靈敏的產(chǎn)品。

但它仍然需要主動(dòng)求變以跟上這個(gè)時(shí)代，只是對(duì)于微信的開發(fā)團(tuán)隊(duì)來說，這是一條試錯(cuò)空間極窄的路。人們無法回到?jīng)]有微信的時(shí)候，而微信最好也不要提醒他們。

這樣的事情在2013年發(fā)生過，上海某施工隊(duì)的一敲讓那時(shí)候“僅有”的3億用戶在接近5個(gè)小時(shí)里不能收發(fā)信息。這條底線在2020年的春節(jié)前夕又被拉緊過一次，如果2013年那次是被動(dòng)的意外，兩年前的試探則是不得不。

彼時(shí)的微信正在離開物理服務(wù)器，處于一切轉(zhuǎn)向虛擬與云的中途。1月中旬的一場(chǎng)“春節(jié)保障”壓力測(cè)試中，微信團(tuán)隊(duì)對(duì)虛擬服務(wù)器進(jìn)行擴(kuò)容后的攻擊性測(cè)試，結(jié)果服務(wù)器在同時(shí)訪問數(shù)量才到預(yù)計(jì)一半的時(shí)候就到了極限。那年的除夕夜是1月24日，這個(gè)問題如果在兩個(gè)星期內(nèi)解決，意味著新年鐘聲敲響之前，整個(gè)微信可能將會(huì)再一次大規(guī)模宕機(jī)。

暗涌最終沒有浮出水面，現(xiàn)在提起那一天的微信，偶爾會(huì)有人記得那天是專屬紅包封面第一次上線，一切相安無事。

930 變革后，開源協(xié)同和自研上云成為騰訊新的戰(zhàn)略方向，也同樣成為微信上云的契機(jī)。微信是騰訊最謹(jǐn)慎小心的業(yè)務(wù)，這從它在騰訊內(nèi)部的上云順序里就可以看出來——最后一個(gè)。微信在兩年時(shí)間里完成了用虛擬機(jī)對(duì)物理機(jī)的替代，然后逐漸脫離原來內(nèi)部自研的云平臺(tái)系統(tǒng)，轉(zhuǎn)向更具開源屬性的K8S。對(duì)于已經(jīng)降落為生活底色的微信來說，這是一場(chǎng)無法張揚(yáng)的浩大變革。直到現(xiàn)在，微信基礎(chǔ)架構(gòu)上云的過程逐漸完成，一條復(fù)雜的道路才在身后顯現(xiàn)出來。

物理機(jī)，Yard，和那個(gè)舊微信

事后看來，2013年這個(gè)年份，在微信身上隱隱劃出一條界限。

這年的1月中旬，微信團(tuán)隊(duì)在微博上宣布了微信用戶數(shù)終于突破3億，這讓它成為當(dāng)時(shí)全球下載量和用戶量最多的通信軟件。這時(shí)候離微信首次上線的兩周年時(shí)刻甚至還差著幾天。不到兩年的時(shí)間，附近的人和搖一搖兩個(gè)功能帶著移動(dòng)互聯(lián)網(wǎng)最初的燥熱感覺給微信帶來了最早一批用戶，然后就是2012年朋友圈和視頻聊天功能的出現(xiàn)。

2013 年之前，除了那個(gè)對(duì)話框里的橙色信封，我們現(xiàn)在熟悉的那個(gè)微信已經(jīng)基本成型。

一明一暗，騰訊搜搜在2013年被賣掉。這款2006年追隨谷歌和百度而出的產(chǎn)品最終無疾而終，在七年后被打包注入搜狗。騰訊的搜索業(yè)務(wù)暫時(shí)停頓下來，其中的迷茫轉(zhuǎn)而成為明星業(yè)務(wù)上更多的心血。主導(dǎo)騰訊搜搜整個(gè)架構(gòu)建立，又把它做到賣掉了的工程師文杰，作為骨干力量同一年進(jìn)入微信技術(shù)架構(gòu)部。

微信力求簡單與用完即走，而百億級(jí)的消息日收發(fā)量，數(shù)萬個(gè)的服務(wù)器數(shù)量，是貫徹這場(chǎng)繁榮背后的另一個(gè)故事。微信的服務(wù)器能力需要滿足壓力上限，而CPU的使用率并不總在高峰，晚上九點(diǎn)是消息收發(fā)最高漲的時(shí)間段，過了幾個(gè)小時(shí)走到凌晨，CPU的使用率就剩下3%，極限落差有15倍。絕大多數(shù)服務(wù)器的運(yùn)算能力都被浪費(fèi)了。

第三個(gè)1億用戶，微信只用了不到四個(gè)月，一個(gè)近在眼前的爆發(fā)期已可以預(yù)見。微信內(nèi)部一個(gè)新的資源分發(fā)邏輯呼之欲出，文杰和整個(gè)技術(shù)架構(gòu)部將會(huì)主導(dǎo)這一場(chǎng)變革性的研發(fā)。2013年底，自研云平臺(tái)系統(tǒng)Yard開始出現(xiàn)在內(nèi)部討論中。

Yard 是四個(gè)英文單詞的首字母縮寫，分別是Yet，Another，Resource和Dispatcher，合在一起即“僅僅是另一個(gè)資源分發(fā)系統(tǒng)”?；蛘叻Q之為一套容器管理體系，Yard利用容器技術(shù)對(duì)微信服務(wù)器CPU做了精細(xì)化隔離后，可以實(shí)現(xiàn)在同一臺(tái)服務(wù)器上分割部署多個(gè)功能模塊。

這意味著在線與離線有了更有效率的混布方式，在線上了突發(fā)流量需求時(shí)，離線任務(wù)可以迅速騰出服務(wù)器資源，Yard下微信集群CPU資源的使用率達(dá)到了40%以上。

這種辦法奏效了，Yard托住了微信的下一個(gè)爆發(fā)期。2016年年底，微信和WeChat合并月活躍用戶數(shù)達(dá)到8.89億，那一年我國網(wǎng)民規(guī)模達(dá)只有7.31億。

但當(dāng)微信走完了用戶增長的最重要一程，開始把更多注意力放在業(yè)務(wù)寬度上時(shí)，Yard的劣勢(shì)也開始出現(xiàn)。

2014年初的微信離第一個(gè)小程序的上線還有三年，甚至還沒有微信支付。那扇接納天下賓客的平臺(tái)之門還未打開，Yard在研發(fā)時(shí)也并未過多考慮與外部技術(shù)工具的兼容性。事實(shí)上， Yard 出生所被賦予的目標(biāo)非常具體，針對(duì)服務(wù)器的CPU和存儲(chǔ)做虛擬化的靈活調(diào)度以降本增效，換句話說，Yard是為了解決一個(gè)指向性非常明確，與微信原有基礎(chǔ)架構(gòu)強(qiáng)關(guān)聯(lián)的需求而誕生的。

但隨著更多業(yè)務(wù)的涌入，不開源的Yard像一個(gè)非標(biāo)品，

微信的業(yè)務(wù)在幾年內(nèi)迅速拉開寬度，業(yè)務(wù)涉及的領(lǐng)域變多，每 個(gè)團(tuán)隊(duì)所依賴的技術(shù)工具各有偏好，定制化的要求帶來很多不必要的工作量 。大數(shù)據(jù)相關(guān)的業(yè)務(wù)主流上更偏向Hadoop或者Spark技術(shù)；做AI訓(xùn)練的團(tuán)隊(duì)則傾向于Tensorflow或者Pytorch，但這些框架在第一次接入Yard時(shí)都要人工重新進(jìn)行適配，甚至在每一次框架升級(jí)后，同樣的事情又要再做一遍。越多新的技術(shù)工具引入，Yard在開放性上的局限就越暴露出來。

930 變革后，剝離物理機(jī)成為上云的開始，但這只是第一步?；A(chǔ)架構(gòu)整體搬上云端，微信這次勢(shì)必要走到一個(gè)開源的環(huán)境里，Kubernetes系統(tǒng)看起來是最合適的路。
風(fēng)向

Yard 真正開始在微信內(nèi)部落地是2013、2014年前后，這也是微信上云的開始。這一年全球的開源潮流也終于開始向暖。

彼時(shí)北半球的另一只企鵝Linux風(fēng)頭正勁，2014年當(dāng)選微軟新任CEO的納德拉在上位后隨即高舉“微軟愛Linux”；同一年，上線滿六年已托管了超過1000萬個(gè)存儲(chǔ)庫的GitHub逐漸成為微軟、谷歌等硅谷巨頭科技公司的碼農(nóng)客廳。

一切早有跡象，2013年中旬白宮的一份“公開數(shù)據(jù)政策”（Open Data Policy）草案被發(fā)布在GitHub上。在此之前，將一份政府政策文件托管在在一家私人公司的服務(wù)器上從未有過。雖然這份文檔并不能被二次操作或者衍生出任何代碼項(xiàng)目，但它仍然具有極重要的象征意義。GitHub以及背后的開源思想，隨著克里斯·萬斯克拉斯而登堂入室。

此前微軟或者說整個(gè)科技主流聲音直站在開源的反面，正如Windows與Linux長時(shí)間在安全性上的對(duì)峙立場(chǎng)一樣。但技術(shù)的迷人處也在這里，開源的優(yōu)越性在這個(gè)一切場(chǎng)景都趨向于虛擬化的時(shí)代顯露無疑，一旦達(dá)成了共識(shí)，轉(zhuǎn)變?cè)谝凰查g。

從巨頭到獨(dú)立開發(fā)者們，開源的思想顯然熱起來了。讓代碼協(xié)作起來，甚至讓寫代碼這件事本身社區(qū)化，正在成為信息世界新的項(xiàng)目管理方式。

同樣在2013年，Docker項(xiàng)目的第一個(gè)版本被上傳到了GitHub，以Apache 2.0授權(quán)協(xié)議開源并在GitHub進(jìn)行維護(hù)。Docker拉開了容器作為一種虛擬化技術(shù)的歷史，在此之前，隨著硬件性能的發(fā)展，硬件性能過剩成為一種愈發(fā)顯眼的問題，而硬件虛擬化成為最先出來的解決方法。傳統(tǒng)虛擬機(jī)技術(shù)是虛擬出一套硬件后，在其上運(yùn)行一個(gè)完整操作系統(tǒng)（Guest OS），在該系統(tǒng)上再運(yùn)行所需應(yīng)用進(jìn)程。但Guest OS本身就是一個(gè)非常占內(nèi)存且需要在所有虛擬機(jī)上重復(fù)安裝的系統(tǒng)，這種方式顯得很重。相比之下，打包進(jìn)容器內(nèi)的應(yīng)用進(jìn)程可以直接在宿主內(nèi)核中運(yùn)行，而容器內(nèi)沒有自己的內(nèi)核，也不必要進(jìn)行硬件虛擬，這種封裝隔離的邏輯顯得更輕，也有更好的擴(kuò)容彈性。

由于容器的出現(xiàn)，使得硬件虛擬化，也就是虛擬機(jī)與大內(nèi)存的Guest OS，不再是實(shí)現(xiàn)資源有效配置的必要條件。但容器更偏向一種技術(shù)方法，這種技術(shù)最終要解決應(yīng)用程序端的問題，因此在龐大的容器基礎(chǔ)架構(gòu)集群之上，需要一種更高維度的調(diào)度工具。

2017 年10月的歐洲D(zhuǎn)ockerCon大會(huì)上，Docker公司CTO Solomon Hykes宣布下一個(gè)版本的Docker除了支持自有的調(diào)度引擎Swarm外，將會(huì)首次支持一個(gè)外部的調(diào)度平臺(tái)——谷歌的Kubernetes。

Kubernetes 也被叫做K8S（由于一共8個(gè)字母），是一個(gè)針對(duì)容器應(yīng)用，進(jìn)行自動(dòng)部署，彈性伸縮，和管理的開源系統(tǒng)。主要功能是生產(chǎn)環(huán)境的容器編排。2014年6月谷歌云計(jì)算專家埃里克·布魯爾（Eric Brewer）在舊金山的發(fā)布會(huì)為這款新的開源工具揭牌，2015年7月22日迭代到v 1.0后，k8s正式對(duì)外公布。

率先提出容器概念的Docker在三年后主動(dòng)靠近K8S，這一舉動(dòng)給業(yè)界帶來的震蕩不亞于那句“微軟愛Linux”。這意味著在容器調(diào)度工具的市場(chǎng)中，K8S在與Swarm和Mesos的爭鋒中勝出，成為行業(yè)標(biāo)準(zhǔn)。

某種程度上，微信Yard與Windows有些相似處，兩者都曾是技術(shù)至上但完全向內(nèi)的閉源作品。當(dāng)時(shí)不同往日，在微信長成一個(gè)平臺(tái)，連接起的業(yè)務(wù)越發(fā)復(fù)雜后，一場(chǎng)改閉源為開源的革新已經(jīng)不可避免。巧合的是，微軟在2018年以75億美元的價(jià)格收購了Github，微信在這一年決定開始從Yard開始轉(zhuǎn)向K8S。

這個(gè)過程并非一蹴而就，向K8S遷移需要硬件環(huán)境的必要支持，騰訊負(fù)責(zé)云環(huán)境搭建的團(tuán)隊(duì)從2018年開始著手建立。與此同時(shí)，以930變革為界，騰訊內(nèi)部開始改變服務(wù)器的提供模式，從原來提供物理機(jī)，改為提供CVM虛擬機(jī)。

前面已經(jīng)提到，虛擬機(jī)在性能上對(duì)比物理機(jī)并沒有優(yōu)勢(shì)，擺脫物理機(jī)的價(jià)值在于降低成本。沒有折舊，不需要購買實(shí)體服務(wù)器或者特別布置機(jī)房，這將節(jié)省出一筆上億的開支。這個(gè)步驟在2020年走完。也是從那時(shí)候開始，一個(gè)完全運(yùn)行在云端的Yard，開始向K8S遷移。
轉(zhuǎn)向K8S

2014 年Yard開始成型的時(shí)候K8S還沒有出現(xiàn)，當(dāng)時(shí)設(shè)計(jì)的時(shí)候微信內(nèi)部對(duì)于yard的定位就是只滿足自己的需求，沒有做更通用化、或者進(jìn)一步云化的需求。從兩個(gè)看上去有些脫節(jié)的系統(tǒng)中帶著一大堆復(fù)雜的功能做轉(zhuǎn)換，兼容性就成了這個(gè)遷移過程中最重要的問題。

一個(gè)最典型的沖突是，以K8S的架構(gòu)在一臺(tái)服務(wù)器上部署兩個(gè)功能模塊，這兩個(gè)功能模塊是要完全隔離的，這是K8S或者當(dāng)下云平臺(tái)從安全性角度形成的一個(gè)基本假設(shè)。但是在早期Yard的設(shè)計(jì)里并沒有特別強(qiáng)調(diào)這一點(diǎn)，Yard的分核部署邏輯完全服務(wù)于微信，一臺(tái)機(jī)器中的兩個(gè)功能模塊是可以通過共享內(nèi)存等一些方式互相通信的。

2020 年中，微信內(nèi)部在一個(gè)內(nèi)部效能工具的遷移過程中，曾經(jīng)整個(gè)平臺(tái)大范圍宕機(jī)過一次。

“ 當(dāng)時(shí)上面跑了二三十個(gè)服務(wù)，一下子所有的服務(wù)都異常了，我的電話和企業(yè)微信全部被打爆了，都在找我”，微信給微信支付業(yè)務(wù)一整年的宕機(jī)故障預(yù)算只有幾分鐘，對(duì)于微信支付平臺(tái)架構(gòu)中心的工程師lucienduan來說，這次提前在內(nèi)部試出來的雷是經(jīng)歷中少有的“烏云壓頂”時(shí)刻。

這個(gè)事故最終追溯到一個(gè)書寫不規(guī)范的任務(wù)，一行不起眼的錯(cuò)誤代碼導(dǎo)致網(wǎng)關(guān)負(fù)載過高，直接把網(wǎng)關(guān)跑掛了。

在剛轉(zhuǎn)入K8S的初期，這個(gè)遷移過程并不成熟，整個(gè)架構(gòu)團(tuán)隊(duì)都要時(shí)常在這種巨大的潛在風(fēng)險(xiǎn)下工作。

所幸的是，這次操作失誤只是僅有的幾次事故之一，也并沒有影響到外界的微信用戶，這也是微信給這次上云過程劃的底線。對(duì)于正在使用微信的10億用戶來說，他們完全不需要知道手中這個(gè)綠色的對(duì)話框背后在發(fā)生什么變化，但用K8S替換掉自研的Yard，這件事又不得不與微信日常的正常運(yùn)行同時(shí)發(fā)生。

因此在遷移過程的初期，微信團(tuán)隊(duì)預(yù)先做了冒煙測(cè)試，所有原來基于Yard形成的微信功能，都需要預(yù)先放到K8S上跑一圈，篩出一些明顯的問題。

確定兼容性是Yard向K8S遷移的第一步，之后就是在兩套系統(tǒng)中進(jìn)行所有功能的對(duì)齊，包括對(duì)于三園區(qū)容災(zāi)的支撐能力，這個(gè)在微信整個(gè)產(chǎn)品歷史中都十分顯眼的教訓(xùn)。

2013 年7月22日，微信上海數(shù)據(jù)中心的主光纖被意外挖斷，這導(dǎo)致了一場(chǎng)兩千臺(tái)服務(wù)器的集體癱瘓。微信此前一直將單一消息系統(tǒng)里核心模塊的三個(gè)互備的服務(wù)實(shí)例部署在同一機(jī)房，這個(gè)冗余的設(shè)計(jì)在微信迅速成長的初期并不顯眼，但那一次事故卻足足造成了消息收發(fā)和朋友圈服務(wù)近5個(gè)小時(shí)的中斷。

那次事故之后，微信開始將服務(wù)器分散布置，在三棟不同建筑物中分別放置機(jī)房的容災(zāi)模式由此出現(xiàn)。這也是K8S對(duì)齊Yard的一個(gè)重點(diǎn)。

“K8S 對(duì)三園區(qū)的支持能不能做好，這是當(dāng)時(shí)首先考慮的事。”謹(jǐn)慎起見，微信團(tuán)隊(duì)內(nèi)部對(duì)這次遷移過一個(gè)明確的要求，每一步遷移操作都要能夠回退Yard?！癥ARD平臺(tái)的容量要隨時(shí)能承受K8S平臺(tái)回退帶來的流量，確保業(yè)務(wù)無損”，微信團(tuán)隊(duì)表示。

剩下的就是K8S代替了Yard后，能給微信帶來什么了。
Coder到Owner

DevOps 時(shí)代的軟件開發(fā)部署，頻率迫切到每周甚至每天，但開發(fā)和運(yùn)維環(huán)節(jié)的割裂，逐漸成為微信內(nèi)部一個(gè)明顯的效率問題。雖然Dev與Ops寫在一起，實(shí)際操作起來卻由兩個(gè)團(tuán)隊(duì)完成。開發(fā)團(tuán)隊(duì)完成代碼的編寫打包后交給運(yùn)維團(tuán)隊(duì)去部署核上線，結(jié)果是運(yùn)維人員不熟悉代碼邏輯，開發(fā)人員不懂上線。這樣的問題頻繁在微信內(nèi)部發(fā)生，遇到緊急問題往往需要拉很多人員共同處理。

“ 這樣的事拉低了整個(gè)團(tuán)隊(duì)的研發(fā)效率，”微信業(yè)務(wù)團(tuán)隊(duì)中很多人同時(shí)提到了這一點(diǎn)。

遷移到K8S后對(duì)于微信開發(fā)者來說最明顯的改變就在這里，全?；牟渴鹗沟眠\(yùn)維的角色很大程度上與開發(fā)者合并到了一起。微信的開發(fā)團(tuán)隊(duì)除了要寫代碼，也可以同時(shí)完成擴(kuò)容、上線以及模塊部署，這條從開發(fā)到上線的鏈路被極大縮短，以微信基礎(chǔ)架構(gòu)工程師edselwang的話來說，“業(yè)務(wù)代碼編寫人員從純粹的Coder變成了一個(gè)業(yè)務(wù)模塊的Owner”。

并且由于K8S具備更全面的虛擬化支持，在整個(gè)研發(fā)體系完成上云之后，節(jié)點(diǎn)部署與虛擬機(jī)脫離，開發(fā)過程中CI/CD（持續(xù)集成/持續(xù)部署）流程作為流水線般的自動(dòng)交付過程可以更完整的實(shí)現(xiàn)，這可以被理解成一種“自愈”能力。

edselwang 舉了一個(gè)例子，如果部署在虛擬機(jī)上的節(jié)點(diǎn)壞了，因?yàn)樘摂M機(jī)不具備節(jié)點(diǎn)直接遷移的屬性，所以需要運(yùn)維人員人工給節(jié)點(diǎn)在兩臺(tái)虛擬機(jī)之間做轉(zhuǎn)移。但如果節(jié)點(diǎn)是部署在K8S的平臺(tái)上，系統(tǒng)可以代替人工來給節(jié)點(diǎn)做自動(dòng)調(diào)度。

曾經(jīng)年三十晚上搶紅包的高峰期，微信整個(gè)運(yùn)維團(tuán)隊(duì)加班守在服務(wù)器前的排班，在整體上云后也會(huì)輕松下來。

更大的一個(gè)層面上，微信在騰訊內(nèi)部并不是最早上K8S的，一手扶植起QQ的湯道生在930變革之后進(jìn)入新組的CSIG事業(yè)部，QQ隨后成為騰訊首個(gè)全面上云的內(nèi)部業(yè)務(wù)，眾多明星游戲工作室所在的IEG事業(yè)部也在幾年前開始將架構(gòu)擺到云上。

騰訊整體的K8S環(huán)境搭建在微信遷移之前，這意味著后者從Yard跳脫出來后，將在基礎(chǔ)架構(gòu)研發(fā)上進(jìn)一步更融入進(jìn)騰訊云原生的設(shè)施體系，無論從資源調(diào)度還是系統(tǒng)工具的適配性上來看，新業(yè)務(wù)的決策成本都變得更低了。

這樣復(fù)雜的基礎(chǔ)架構(gòu)，最終指向一種釋放人的價(jià)值的，更先進(jìn)的生產(chǎn)力工具。

微信技術(shù)架構(gòu)負(fù)責(zé)人Stephen Liu對(duì)于一個(gè)完全云原生的微信的期待是，它最終能成為一種資源調(diào)度意義上的“自動(dòng)駕駛”。

“ 如果在2014之前的微信是Level 0的話，有了Yard之后現(xiàn)在是Level 1，經(jīng)過2021年整個(gè)去挖掘K8S的各種能力之后，我覺得我們現(xiàn)在應(yīng)該處在 Level 2的狀態(tài)。”Stephen Liu設(shè)想中未來的微信春節(jié)保供調(diào)度將完全由系統(tǒng)調(diào)度主導(dǎo)，而這一定基于一個(gè)完全云原生的微信。

2019 年是微信最后一次申請(qǐng)物理服務(wù)器，按通常四到五年的折舊時(shí)間來算，不出意外的話，這最后一批物理服務(wù)器將會(huì)在2023年底左右過保，那恰好是Yard開始搭建的10年之后。屆時(shí)的微信將真正把整個(gè)身體搬上云端。

一切都在不動(dòng)聲色中，微信成了新的微信。