扒一扒微信后臺(tái)架構(gòu).....
我知道很多同學(xué)對(duì)微信后臺(tái)很感興趣，所以打算整理一些微信后臺(tái)的技術(shù)棧，以及架構(gòu)演進(jìn)的歷程。
偶爾也會(huì)寫點(diǎn)自己在后臺(tái)開發(fā)時(shí)的一些體驗(yàn)。
下面開始第一篇吧，先給大家介紹下微信早期后臺(tái)是如何從0到1的。
2個(gè)月的開發(fā)時(shí)間，微信后臺(tái)系統(tǒng)經(jīng)歷了從0到1的過程。
從小步慢跑到快速成長(zhǎng)，經(jīng)歷了平臺(tái)化到走出國(guó)門，微信交出的這份優(yōu)異答卷，解題思路是怎樣的？
2011.1.21 微信正式發(fā)布。這一天距離微信項(xiàng)目啟動(dòng)日約為2個(gè)月。
就在這2個(gè)月里，微信從無到有，大家可能會(huì)好奇這期間微信后臺(tái)做的最重要的事情是什么？
我想應(yīng)該是以下三件事：
1. 確定了微信的消息模型
微信起初定位是一個(gè)通訊工具，作為通訊工具最核心的功能是收發(fā)消息。
微信團(tuán)隊(duì)源于廣硏團(tuán)隊(duì)，消息模型跟郵箱的郵件模型也很有淵源，都是存儲(chǔ)轉(zhuǎn)發(fā)。
上圖展示了這一消息模型，消息被發(fā)出后，會(huì)先在后臺(tái)臨時(shí)存儲(chǔ)；
為使接收者能更快接收到消息，會(huì)推送消息通知給接收者；
最后客戶端主動(dòng)到服務(wù)器收取消息。
2. 制定了數(shù)據(jù)同步協(xié)議
由于用戶的帳戶、聯(lián)系人和消息等數(shù)據(jù)都在服務(wù)器存儲(chǔ)，如何將數(shù)據(jù)同步到客戶端就成了很關(guān)鍵的問題。
為簡(jiǎn)化協(xié)議，我們決定通過一個(gè)統(tǒng)一的數(shù)據(jù)同步協(xié)議來同步用戶所有的基礎(chǔ)數(shù)據(jù)。
最初的方案是客戶端記錄一個(gè)本地?cái)?shù)據(jù)的快照(Snapshot)，需要同步數(shù)據(jù)時(shí)，將 Snapshot 帶到服務(wù)器，服務(wù)器通過計(jì)算 Snapshot 與服務(wù)器數(shù)據(jù)的差異，將差異數(shù)據(jù)發(fā)給客戶端，客戶端再保存差異數(shù)據(jù)完成同步。
不過這個(gè)方案有兩個(gè)問題：
一是 Snapshot 會(huì)隨著客戶端數(shù)據(jù)的增多變得越來越大，同步時(shí)流量開銷大；
二是客戶端每次同步都要計(jì)算 Snapshot，會(huì)帶來額外的性能開銷和實(shí)現(xiàn)復(fù)雜度。
幾經(jīng)討論后，方案改為由服務(wù)計(jì)算 Snapshot，在客戶端同步數(shù)據(jù)時(shí)跟隨數(shù)據(jù)一起下發(fā)給客戶端，客戶端無需理解 Snapshot，只需存儲(chǔ)起來，在下次數(shù)據(jù)同步數(shù)據(jù)時(shí)帶上即可。
同時(shí)，Snapshot被設(shè)計(jì)得非常精簡(jiǎn)，是若干個(gè) Key-Value 的組合，Key 代表數(shù)據(jù)的類型，Value 代表給到客戶端的數(shù)據(jù)的最新版本號(hào)。
Key 有三個(gè)，分別代表：帳戶數(shù)據(jù)、聯(lián)系人和消息。
這個(gè)同步協(xié)議的一個(gè)額外好處是客戶端同步完數(shù)據(jù)后，不需要額外的ACK協(xié)議來確認(rèn)數(shù)據(jù)收取成功，同樣可以保證不會(huì)丟數(shù)據(jù)：
只要客戶端拿最新的Snapshot到服務(wù)器做數(shù)據(jù)同步，服務(wù)器即可確認(rèn)上次數(shù)據(jù)已經(jīng)成功同步完成，可以執(zhí)行后續(xù)操作。
例如清除暫存在服務(wù)的消息等等。
此后，精簡(jiǎn)方案、減少流量開銷、盡量由服務(wù)器完成較復(fù)雜的業(yè)務(wù)邏輯、降低客戶端實(shí)現(xiàn)的復(fù)雜度就作為重要的指導(dǎo)原則，持續(xù)影響著后續(xù)的微信設(shè)計(jì)開發(fā)。
記得有個(gè)比較經(jīng)典的案例是：我們?cè)谖⑿?.2版實(shí)現(xiàn)了群聊功能，但為了保證新舊版客戶端間的群聊體驗(yàn)，我們通過服務(wù)器適配，讓1.0版客戶端也能參與群聊。
3. 定型了后臺(tái)架構(gòu)
微信后臺(tái)使用三層架構(gòu)：接入層、邏輯層和存儲(chǔ)層
接入層提供接入服務(wù)，包括長(zhǎng)連接入服務(wù)和短連接入服務(wù)。
長(zhǎng)連接入服務(wù)同時(shí)支持客戶端主動(dòng)發(fā)起請(qǐng)求和服務(wù)器主動(dòng)發(fā)起推送；
短連接入服務(wù)則只支持客戶端主動(dòng)發(fā)起請(qǐng)求。
邏輯層包括業(yè)務(wù)邏輯服務(wù)和基礎(chǔ)邏輯服務(wù)。
業(yè)務(wù)邏輯服務(wù)封裝了業(yè)務(wù)邏輯，是后臺(tái)提供給微信客戶端調(diào)用的API。
基礎(chǔ)邏輯服務(wù)則抽象了更底層和通用的業(yè)務(wù)邏輯，提供給業(yè)務(wù)邏輯服務(wù)訪問。
存儲(chǔ)層包括數(shù)據(jù)訪問服務(wù)和數(shù)據(jù)存儲(chǔ)服務(wù)。
數(shù)據(jù)存儲(chǔ)服務(wù)通過 MySQL 和 SDB(廣硏早期后臺(tái)中廣泛使用的 Key-Table 數(shù)據(jù)存儲(chǔ)系統(tǒng))等底層存儲(chǔ)系統(tǒng)來持久化用戶數(shù)據(jù)。
數(shù)據(jù)訪問服務(wù)適配并路由數(shù)據(jù)訪問請(qǐng)求到不同的底層數(shù)據(jù)存儲(chǔ)服務(wù)，面向邏輯層提供結(jié)構(gòu)化的數(shù)據(jù)服務(wù)。
比較特別的是，微信后臺(tái)每一種不同類型的數(shù)據(jù)都使用單獨(dú)的數(shù)據(jù)訪問服務(wù)和數(shù)據(jù)存儲(chǔ)服務(wù)，例如帳戶、消息和聯(lián)系人等等都是獨(dú)立的。
微信后臺(tái)主要使用C++。后臺(tái)服務(wù)使用Svrkit框架搭建，服務(wù)之間通過同步RPC進(jìn)行通訊。
Svrkit是另一個(gè)廣硏后臺(tái)就已經(jīng)存在的高性能RPC框架，當(dāng)時(shí)尚未廣泛使用，但在微信后臺(tái)卻大放異彩。
作為微信后臺(tái)基礎(chǔ)設(shè)施中最重要的一部分，Svrkit這幾年一直不斷在進(jìn)化。我們使用Svrkit構(gòu)建了數(shù)以千計(jì)的服務(wù)模塊，提供數(shù)萬個(gè)服務(wù)接口，每天RPC調(diào)用次數(shù)達(dá)幾十萬億次。
這三件事影響深遠(yuǎn)，乃至于5年后的今天，我們?nèi)岳^續(xù)沿用最初的架構(gòu)和協(xié)議，甚至還可以支持當(dāng)初 1.0 版的微信客戶端。
這里有一個(gè)經(jīng)驗(yàn)教訓(xùn)——運(yùn)營(yíng)支撐系統(tǒng)真的很重要。第一個(gè)版本的微信后臺(tái)是倉(cāng)促完成的，當(dāng)時(shí)只是完成了基礎(chǔ)業(yè)務(wù)功能，并沒有配套的業(yè)務(wù)數(shù)據(jù)統(tǒng)計(jì)等等。
我們?cè)陂_放注冊(cè)后，一時(shí)間竟沒有業(yè)務(wù)監(jiān)控頁(yè)面和數(shù)據(jù)曲線可以看。
注冊(cè)用戶數(shù)是臨時(shí)從數(shù)據(jù)庫(kù)統(tǒng)計(jì)的，在線數(shù)是從日志里提取出來的，這些數(shù)據(jù)通過每個(gè)小時(shí)運(yùn)行一次的腳本（這個(gè)腳本也是當(dāng)天臨時(shí)加的）統(tǒng)計(jì)出來，然后自動(dòng)發(fā)郵件到郵件組。
還有其他各種業(yè)務(wù)數(shù)據(jù)也通過郵件進(jìn)行發(fā)布，可以說郵件是微信初期最重要的數(shù)據(jù)門戶。
2011.1.21 當(dāng)天最高并發(fā)在線數(shù)是 491，而今天這個(gè)數(shù)字是4億。
階段二：小步慢跑
在微信發(fā)布后的4個(gè)多月里，我們經(jīng)歷了發(fā)布后火爆注冊(cè)的驚喜，也經(jīng)歷了隨后一直不溫不火的困惑。
這一時(shí)期，微信做了很多旨在增加用戶好友量，讓用戶聊得起來的功能。
打通騰訊微博私信、群聊、工作郵箱、QQ/郵箱好友推薦等等。
對(duì)于后臺(tái)而言，比較重要的變化就是這些功能催生了對(duì)異步隊(duì)列的需求。
例如，微博私信需要跟外部門對(duì)接，不同系統(tǒng)間的處理耗時(shí)和速度不一樣，可以通過隊(duì)列進(jìn)行緩沖；
群聊是耗時(shí)操作，消息發(fā)到群后，可以通過異步隊(duì)列來異步完成消息的擴(kuò)散寫等等。
這是異步隊(duì)列在群聊中的應(yīng)用。微信的群聊是寫擴(kuò)散的，也就是說發(fā)到群里的一條消息會(huì)給群里的每個(gè)人都存一份（消息索引）。
微信的群聊為什么不是讀擴(kuò)散呢？
有兩個(gè)原因：
群的人數(shù)不多，群人數(shù)上限是 10（后來逐步加到 20、40、100，目前是 500），擴(kuò)散的成本不是太大，不像微博，有成千上萬的粉絲，發(fā)一條微博后，每粉絲都存一份的話，一個(gè)是效率太低，另一個(gè)存儲(chǔ)量也會(huì)大很多；
消息擴(kuò)散寫到每個(gè)人的消息存儲(chǔ)（消息收件箱）后，接收者到后臺(tái)同步數(shù)據(jù)時(shí)，只需要檢查自己收件箱即可，同步邏輯跟單聊消息是一致的，這樣可以統(tǒng)一數(shù)據(jù)同步流程，實(shí)現(xiàn)起來也會(huì)很輕量。
異步隊(duì)列作為后臺(tái)數(shù)據(jù)交互的一種重要模式，成為了同步RPC服務(wù)調(diào)用之外的有力補(bǔ)充，在微信后臺(tái)被大量使用。
KVSvr
微信后臺(tái)每個(gè)存儲(chǔ)服務(wù)都有自己獨(dú)立的存儲(chǔ)模塊，是相互獨(dú)立的。
每個(gè)存儲(chǔ)服務(wù)都有一個(gè)業(yè)務(wù)訪問模塊和一個(gè)底層存儲(chǔ)模塊組成。
業(yè)務(wù)訪問層隔離業(yè)務(wù)邏輯層和底層存儲(chǔ)，提供基于RPC的數(shù)據(jù)訪問接口；底層存儲(chǔ)有兩類：
SDB MySQL
SDB 適用于以用戶UIN(uint32_t)為Key的數(shù)據(jù)存儲(chǔ)，比方說消息索引和聯(lián)系人。
優(yōu)點(diǎn)是性能高，在可靠性上，提供基于異步流水同步的 Master-Slave 模式，Master 故障時(shí)，Slave 可以提供讀數(shù)據(jù)服務(wù)，無法寫入新數(shù)據(jù)。
由于微信賬號(hào)為字母+數(shù)字組合，無法直接作為 SDB 的 Key，所以微信帳號(hào)數(shù)據(jù)并非使用 SDB，而是用 MySQL 存儲(chǔ)的。
MySQL 也使用基于異步流水復(fù)制的 Master-Slave 模式。
第 1 版的帳號(hào)存儲(chǔ)服務(wù)使用 Master-Slave 各1臺(tái)。
Master 提供讀寫功能，Slave 不提供服務(wù)，僅用于備份。
當(dāng) Master 有故障時(shí)，人工切讀服務(wù)到 Slave，無法提供寫服務(wù)。
為提升訪問效率，我們還在業(yè)務(wù)訪問模塊中加入了 memcached 提供 Cache 服務(wù)，減少對(duì)底層存儲(chǔ)訪問。
第 2 版的帳號(hào)存儲(chǔ)服務(wù)還是 Master-Slave各1臺(tái)，區(qū)別是Slave可以提供讀服務(wù)，但有可能讀到臟數(shù)據(jù)，因此對(duì)一致性要求高的業(yè)務(wù)邏輯，例如注冊(cè)和登錄邏輯只允許訪問Master。
當(dāng) Master有故障時(shí)，同樣只能提供讀服務(wù)，無法提供寫服務(wù)。
第 3 版的帳號(hào)存儲(chǔ)服務(wù)采用1個(gè) Master 和多個(gè) Slave，解決了讀服務(wù)的水平擴(kuò)展能力。
第 4 版的帳號(hào)服務(wù)底層存儲(chǔ)采用多個(gè) Master-Slave 組，每組由1個(gè) Master 和多個(gè) Slave 組成，解決了寫服務(wù)能力不足時(shí)的水平擴(kuò)展能力。
最后還有個(gè)未解決的問題：?jiǎn)蝹€(gè) Master-Slave 分組中，Master 還是單點(diǎn)，無法提供實(shí)時(shí)的寫容災(zāi)，也就意味著無法消除單點(diǎn)故障。
另外 Master-Slave 的流水同步延時(shí)對(duì)讀服務(wù)有很大影響，流水出現(xiàn)較大延時(shí)會(huì)導(dǎo)致業(yè)務(wù)故障。
于是我們尋求一個(gè)可以提供高性能、具備讀寫水平擴(kuò)展、沒有單點(diǎn)故障、可同時(shí)具備讀寫容災(zāi)能力、能提供強(qiáng)一致性保證的底層存儲(chǔ)解決方案，最終 KVSvr 應(yīng)運(yùn)而生。
KVSvr 使用基于 Quorum 的分布式數(shù)據(jù)強(qiáng)一致性算法，提供 Key-Value/Key-Table 模型的存儲(chǔ)服務(wù)。
傳統(tǒng) Quorum 算法的性能不高，KVSvr 創(chuàng)造性地將數(shù)據(jù)的版本和數(shù)據(jù)本身做了區(qū)分。
將 Quorum 算法應(yīng)用到數(shù)據(jù)的版本的協(xié)商，再通過基于流水同步的異步數(shù)據(jù)復(fù)制提供了數(shù)據(jù)強(qiáng)一致性保證和極高的數(shù)據(jù)寫入性能。
另外 KVSvr 天然具備數(shù)據(jù)的 Cache 能力，可以提供高效的讀取性能。
KVSvr 一舉解決了我們當(dāng)時(shí)迫切需要的無單點(diǎn)故障的容災(zāi)能力。
除了第 5 版的帳號(hào)服務(wù)外，很快所有SDB底層存儲(chǔ)模塊和大部分MySQL底層存儲(chǔ)模塊都切換到KVSvr。
隨著業(yè)務(wù)的發(fā)展，KVSvr 也不斷在進(jìn)化著，還配合業(yè)務(wù)需要衍生出了各種定制版本。
現(xiàn)在的 KVSvr 仍然作為核心存儲(chǔ)，發(fā)揮著舉足輕重的作用。
如果大家對(duì)微信后臺(tái)演化感興趣的化可以點(diǎn)個(gè)贊或者在看~ 后面我再給大家梳理文章~~
感謝您的閱讀，也歡迎您發(fā)表關(guān)于這篇文章的任何建議，關(guān)注我，技術(shù)不迷茫！小編到你上高速。
正文結(jié)束
1.不認(rèn)命，從10年流水線工人，到谷歌上班的程序媛，一位湖南妹子的勵(lì)志故事
3.從零開始搭建創(chuàng)業(yè)公司后臺(tái)技術(shù)棧
5.37歲程序員被裁，120天沒找到工作，無奈去小公司，結(jié)果懵了...
一個(gè)人學(xué)習(xí)、工作很迷茫？
點(diǎn)擊「閱讀原文」加入我們的小圈子！
