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

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

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

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

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

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

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

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

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

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

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

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

第三個1億用戶，微信只用了不到四個月，一個近在眼前的爆發期已可以預見。微信內部一個新的資源分發邏輯呼之欲出，文杰和整個技術架構部將會主導這一場變革性的研發。2013年底，自研云平臺系統Yard開始出現在內部討論中。

圖源：微信官方

Yard是四個英文單詞的首字母縮寫，分別是Yet，Another，Resource和Dispatcher，合在一起即“僅僅是另一個資源分發系統”。或者稱之為一套容器管理體系，Yard利用容器技術對微信服務器CPU做了精細化隔離后，可以實現在同一臺服務器上分割部署多個功能模塊。

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

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

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

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

但隨著更多業務的涌入，不開源的Yard像一個非標品，

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

930變革后，剝離物理機成為上云的開始，但這只是第一步。基礎架構整體搬上云端，微信這次勢必要走到一個開源的環境里，Kubernetes系統看起來是最合適的路。

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

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

圖源：The Verge

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

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

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

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

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

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

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

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

圖源：The New Stack

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

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

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

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

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

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

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

這個事故最終追溯到一個書寫不規范的任務，一行不起眼的錯誤代碼導致網關負載過高，直接把網關跑掛了。

在剛轉入K8S的初期，這個遷移過程并不成熟，整個架構團隊都要時常在這種巨大的潛在風險下工作。

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

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

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

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

騰訊清遠數據中心 圖源：微信團隊

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

“K8S對三園區的支持能不能做好，這是當時首先考慮的事。”謹慎起見，微信團隊內部對這次遷移過一個明確的要求，每一步遷移操作都要能夠回退Yard。“YARD平臺的容量要隨時能承受K8S平臺回退帶來的流量，確保業務無損”，微信團隊表示。

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

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

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

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

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

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

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

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

騰訊整體的K8S環境搭建在微信遷移之前，這意味著后者從Yard跳脫出來后，將在基礎架構研發上進一步更融入進騰訊云原生的設施體系，無論從資源調度還是系統工具的適配性上來看，新業務的決策成本都變得更低了。

這樣復雜的基礎架構，最終指向一種釋放人的價值的，更先進的生產力工具。

微信技術架構負責人Stephen Liu對于一個完全云原生的微信的期待是，它最終能成為一種資源調度意義上的“自動駕駛”。

“如果在2014之前的微信是Level 0的話，有了Yard之后現在是Level 1，經過2021年整個去挖掘K8S的各種能力之后，我覺得我們現在應該處在Level 2的狀態。”Stephen Liu設想中未來的微信春節保供調度將完全由系統調度主導，而這一定基于一個完全云原生的微信。

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

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

總結

以上是生活随笔為你收集整理的你可能不知道 微信的服务器今天才彻底搬到云上的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。