從0到1：微信后臺系統(tǒng)的演進之路
發(fā)布時間：
2022-11-08
訪問量：
0
2個月的開發(fā)時間，微信后臺系統(tǒng)經(jīng)歷了從0到1的過程。從小步慢跑到快速成長，經(jīng)歷了平臺化到走出國門，微信交出的這份優(yōu)異答卷，解題思路是怎樣的？本文由張文瑞，微信后臺團隊出品。
從無到有
2011.1.21 微信正式發(fā)布。這一天距離微信項目啟動日約為2個月。就在這2個月里，微信從無到有，大家可能會好奇這期間微信后臺做的最重要的事情是什么？
我想應該是以下三件事：
1
確定了微信的消息模型
微信起初定位是一個通訊工具，作為通訊工具最核心的功能是收發(fā)消息。微信團隊源于廣硏團隊，消息模型跟郵箱的郵件模型也很有淵源，都是存儲轉(zhuǎn)發(fā)。
圖 1 微信消息模型
圖1展示了這一消息模型，消息被發(fā)出后，會先在后臺臨時存儲；為使接收者能更快接收到消息，會推送消息通知給接收者；最后客戶端主動到服務器收取消息。
2
制定了數(shù)據(jù)同步協(xié)議
由于用戶的帳戶、聯(lián)系人和消息等數(shù)據(jù)都在服務器存儲，如何將數(shù)據(jù)同步到客戶端就成了很關鍵的問題。為簡化協(xié)議，我們決定通過一個統(tǒng)一的數(shù)據(jù)同步協(xié)議來同步用戶所有的基礎數(shù)據(jù)。
最初的方案是客戶端記錄一個本地數(shù)據(jù)的快照(Snapshot)，需要同步數(shù)據(jù)時，將Snapshot帶到服務器，服務器通過計算Snapshot與服務器數(shù)據(jù)的差異，將差異數(shù)據(jù)發(fā)給客戶端，客戶端再保存差異數(shù)據(jù)完成同步。不過這個方案有兩個問題：一是Snapshot會隨著客戶端數(shù)據(jù)的增多變得越來越大，同步時流量開銷大；二是客戶端每次同步都要計算Snapshot，會帶來額外的性能開銷和實現(xiàn)復雜度。
幾經(jīng)討論后，方案改為由服務計算Snapshot，在客戶端同步數(shù)據(jù)時跟隨數(shù)據(jù)一起下發(fā)給客戶端，客戶端無需理解Snapshot，只需存儲起來，在下次數(shù)據(jù)同步數(shù)據(jù)時帶上即可。同時，Snapshot被設計得非常精簡，是若干個Key-Value的組合，Key代表數(shù)據(jù)的類型，Value代表給到客戶端的數(shù)據(jù)的最新版本號。Key有三個，分別代表：帳戶數(shù)據(jù)、聯(lián)系人和消息。這個同步協(xié)議的一個額外好處是客戶端同步完數(shù)據(jù)后，不需要額外的ACK協(xié)議來確認數(shù)據(jù)收取成功，同樣可以保證不會丟數(shù)據(jù)：只要客戶端拿最新的Snapshot到服務器做數(shù)據(jù)同步，服務器即可確認上次數(shù)據(jù)已經(jīng)成功同步完成，可以執(zhí)行后續(xù)操作，例如清除暫存在服務的消息等等。
此后，精簡方案、減少流量開銷、盡量由服務器完成較復雜的業(yè)務邏輯、降低客戶端實現(xiàn)的復雜度就作為重要的指導原則，持續(xù)影響著后續(xù)的微信設計開發(fā)。記得有個比較經(jīng)典的案例是：我們在微信1.2版實現(xiàn)了群聊功能，但為了保證新舊版客戶端間的群聊體驗，我們通過服務器適配，讓1.0版客戶端也能參與群聊。
3
定型了后臺架構
圖 2 微信后臺系統(tǒng)架構
微信后臺使用三層架構：接入層、邏輯層和存儲層。
- 接入層提供接入服務，包括長連接入服務和短連接入服務。長連接入服務同時支持客戶端主動發(fā)起請求和服務器主動發(fā)起推送；短連接入服務則只支持客戶端主動發(fā)起請求。
- 邏輯層包括業(yè)務邏輯服務和基礎邏輯服務。業(yè)務邏輯服務封裝了業(yè)務邏輯，是后臺提供給微信客戶端調(diào)用的API?；A邏輯服務則抽象了更底層和通用的業(yè)務邏輯，提供給業(yè)務邏輯服務訪問。
- 存儲層包括數(shù)據(jù)訪問服務和數(shù)據(jù)存儲服務。數(shù)據(jù)存儲服務通過MySQL和SDB(廣硏早期后臺中廣泛使用的Key-Table數(shù)據(jù)存儲系統(tǒng))等底層存儲系統(tǒng)來持久化用戶數(shù)據(jù)。數(shù)據(jù)訪問服務適配并路由數(shù)據(jù)訪問請求到不同的底層數(shù)據(jù)存儲服務，面向邏輯層提供結(jié)構化的數(shù)據(jù)服務。比較特別的是，微信后臺每一種不同類型的數(shù)據(jù)都使用單獨的數(shù)據(jù)訪問服務和數(shù)據(jù)存儲服務，例如帳戶、消息和聯(lián)系人等等都是獨立的。
微信后臺主要使用C++。后臺服務使用Svrkit框架搭建，服務之間通過同步RPC進行通訊。
圖 3 Svrkit 框架
Svrkit是另一個廣硏后臺就已經(jīng)存在的高性能RPC框架，當時尚未廣泛使用，但在微信后臺卻大放異彩。作為微信后臺基礎設施中最重要的一部分，Svrkit這幾年一直不斷在進化。我們使用Svrkit構建了數(shù)以千計的服務模塊，提供數(shù)萬個服務接口，每天RPC調(diào)用次數(shù)達幾十萬億次。
這三件事影響深遠，乃至于5年后的今天，我們?nèi)岳^續(xù)沿用最初的架構和協(xié)議，甚至還可以支持當初1.0版的微信客戶端。
這里有一個經(jīng)驗教訓——運營支撐系統(tǒng)真的很重要。第一個版本的微信后臺是倉促完成的，當時只是完成了基礎業(yè)務功能，并沒有配套的業(yè)務數(shù)據(jù)統(tǒng)計等等。我們在開放注冊后，一時間竟沒有業(yè)務監(jiān)控頁面和數(shù)據(jù)曲線可以看，注冊用戶數(shù)是臨時從數(shù)據(jù)庫統(tǒng)計的，在線數(shù)是從日志里提取出來的，這些數(shù)據(jù)通過每個小時運行一次的腳本（這個腳本也是當天臨時加的）統(tǒng)計出來，然后自動發(fā)郵件到郵件組。還有其他各種業(yè)務數(shù)據(jù)也通過郵件進行發(fā)布，可以說郵件是微信初期最重要的數(shù)據(jù)門戶。
2011.1.21 當天最高并發(fā)在線數(shù)是 491，而今天這個數(shù)字是4億。
小步慢跑
在微信發(fā)布后的4個多月里，我們經(jīng)歷了發(fā)布后火爆注冊的驚喜，也經(jīng)歷了隨后一直不溫不火的困惑。
這一時期，微信做了很多旨在增加用戶好友量，讓用戶聊得起來的功能。打通騰訊微博私信、群聊、工作郵箱、QQ/郵箱好友推薦等等。對于后臺而言，比較重要的變化就是這些功能催生了對異步隊列的需求。例如，微博私信需要跟外部門對接，不同系統(tǒng)間的處理耗時和速度不一樣，可以通過隊列進行緩沖；群聊是耗時操作，消息發(fā)到群后，可以通過異步隊列來異步完成消息的擴散寫等等。
點擊排行
1
2
3
4
5
6
7
8
9
10