微信上雲，一切不動聲色

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

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

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

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

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

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

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

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

事後看來，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遷移。

轉向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後，能給微信帶來什麼了。

Coder到Owner

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年之後。屆時的微信將真正把整個身體搬上雲端。

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