微信的服務(wù)器的歷史路

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

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

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

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

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

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

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

物理機，Yard，和那個舊微信

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“K8S 對三園區(qū)的支持能不能做好，這是當時首先考慮的事?！敝斏髌鹨姡⑿艌F隊內(nèi)部對這次遷移過一個明確的要求，每一步遷移操作都要能夠回退Yard?！癥ARD平臺的容量要隨時能承受K8S平臺回退帶來的流量，確保業(yè)務(wù)無損”，微信團隊表示。

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

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

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

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

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

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

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

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

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

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

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

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

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

一切都在不動聲色中，微信成了新的微信。