[[183716]]

本篇算是我閱讀完微信后臺(tái)技術(shù)相關(guān)的干貨文章后得到的一些啟發(fā)，如果去年中那篇屬于技術(shù)干貨的選擇問題，這篇大概就是選擇之后的消化吸收問題了。

循證與決策路徑

在前文中提過，循證大概是我們讀技術(shù)干貨文章的一個(gè)原始訴求，通過分析別人走過的路徑，來?yè)荛_自己技術(shù)道路探索上的迷霧。

關(guān)于 IM 類消息應(yīng)用最重要的一個(gè)技術(shù)決策就是關(guān)于消息模型，微信采用了存儲(chǔ)轉(zhuǎn)發(fā)模型，其具體描述如下(參考[1])：

簡(jiǎn)單描述這個(gè)模型就是三個(gè)步驟：

1. 消息接收后在服務(wù)端臨時(shí)存儲(chǔ)，并通知發(fā)送端已發(fā)送成功。
2. 通知接收端有消息，請(qǐng)來拉取。
3. 接收端收到通知后，再來拉取真正的消息。

初一看這個(gè)模型多了一層通知再拉取的冗余，為什么不直接把消息推下去?對(duì)，最早期我們自己做 IM 就設(shè)計(jì)的先嘗試直接推消息下去，若接收端沒有確認(rèn)收到，再臨時(shí)存儲(chǔ)的模型。后者減少了臨時(shí)存儲(chǔ)的量和時(shí)間，也沒有一個(gè)多余的通知。

但后面這個(gè)模型增加了另一層復(fù)雜度，在早期的 PC 互聯(lián)網(wǎng)時(shí)期，推送并確認(rèn)效率還算挺高的，但在移動(dòng)環(huán)境下，就不太行了。而且引入了移動(dòng)端，實(shí)際就導(dǎo)致了另一層復(fù)雜性，多終端在線，多終端確認(rèn)，多終端已讀和未讀，都需要在服務(wù)端記錄各個(gè)端的狀態(tài)。所以，之后我們也就慢慢演變成同時(shí)存儲(chǔ)和推送消息的并行模型，存儲(chǔ)是為了方便各終端拉取各自的離線消息，但推送因?yàn)樾枰紤]舊終端版本的支持，還得直接推消息本身而并不容易簡(jiǎn)化成消息通知來取消掉消息的接收確認(rèn)過程。

循證，即便你看到了一個(gè)更好的方式，但也要結(jié)合自身的實(shí)際情況去思考實(shí)踐的路徑。所以，如今我們的模型相比微信是一個(gè)更妥協(xié)的版本，若是五年多前要改成微信這樣的模型，也許只需要一兩個(gè)程序員一周的時(shí)間。但如今也許需要好幾個(gè)不同的開發(fā)團(tuán)隊(duì)(各終端和后端)配合弄上一兩個(gè)季度也未必能將所有用戶切換干凈了。

切磋與思考方式

IM 中還有個(gè)大家特別常用和熟悉的功能 —— 群消息。關(guān)于群消息模型，微信采用的是寫擴(kuò)散模型，也就是說發(fā)到群里的一條消息會(huì)給群里的每個(gè)人都存一份(消息索引，參考[1])。這個(gè)模型的***缺點(diǎn)就是要把消息重復(fù)很多份，通過犧牲空間來?yè)Q取了每個(gè)人拉取群消息的效率。

好多年前我們剛開始做群時(shí)，也是采用了的寫擴(kuò)散模型，后來因?yàn)榇鎯?chǔ)壓力太大，一度又改成了讀擴(kuò)散模型。在讀擴(kuò)散模型下，群消息只存一份，記錄每個(gè)群成員讀取群消息的偏移量(消息索引號(hào)，單調(diào)增長(zhǎng))。之所以存儲(chǔ)壓力大在于當(dāng)時(shí)公司還沒有一個(gè)統(tǒng)一的存儲(chǔ)組件，我們直接采用的 Redis 的內(nèi)存存儲(chǔ)，當(dāng)時(shí)原生的 Redis 在橫向和縱向上的擴(kuò)展性上都比較受限。這在當(dāng)時(shí)屬于兩害相權(quán)取其輕，選擇了一個(gè)對(duì)我們研發(fā)團(tuán)隊(duì)來說成本更低的方案。

再后來公司有了擴(kuò)展性和性能都比較好的統(tǒng)一存儲(chǔ)組件后，實(shí)際再換回寫擴(kuò)散模型則更好。畢竟讀擴(kuò)散模型邏輯比較復(fù)雜，考慮自己不知道加了多少個(gè)群了，每次打開應(yīng)用都要檢查每個(gè)群是否有消息，性能開銷是呈線程遞增的。唯一的問題是，寫好、測(cè)好、上線運(yùn)行穩(wěn)定幾年的程序，誰也不想再去換了對(duì)吧，每一次的技術(shù)升級(jí)和架構(gòu)優(yōu)化其實(shí)是需要一個(gè)契機(jī)的。

另外一個(gè)是所有分布式后臺(tái)系統(tǒng)都有的共性問題 —— 性能問題。只要你的用戶量到了一定規(guī)模，比如 100 萬，以后每上一個(gè)量級(jí)，對(duì)技術(shù)支撐的挑戰(zhàn)實(shí)際上并不是呈線性的。微信春晚紅包的案例(參考[2])給出了一個(gè)很好的參考和啟發(fā)，因?yàn)槭忻嫔蠋缀鹾苌儆邢到y(tǒng)能到這個(gè)量級(jí)了。

微信 2015 年春節(jié)的紅包峰值請(qǐng)求是 1400 萬每秒，而微信后臺(tái)其實(shí)也采用了微服務(wù)的架構(gòu)，其拆分原則如下(參考[1])：

服務(wù)拆散了，在自動(dòng)化基礎(chǔ)設(shè)施的輔助下，運(yùn)維效率下降不大，而開發(fā)協(xié)作效率會(huì)提升很多，但性能會(huì)下降。那么在面對(duì)微信春晚紅包這樣的極端性能場(chǎng)景下，該如何應(yīng)對(duì)?在電商里，正常下單和秒殺下單多是分離的兩套系統(tǒng)來支撐，秒殺專為性能優(yōu)化，簡(jiǎn)化了很多正常流程，而且秒殺本身需要支持的 sku 不多，所以它具備簡(jiǎn)化的基礎(chǔ)。而微信給出的方案中實(shí)際也是類似的思路，但它有個(gè)特殊點(diǎn)在于，能把拆散的服務(wù)為了性能又合并回去。

在如此海量請(qǐng)求之下，在這個(gè)分布式系統(tǒng)中，任何一點(diǎn)網(wǎng)絡(luò)或服務(wù)的波動(dòng)都可能是災(zāi)難性的。最終我們選擇把搖一搖服務(wù)去掉，把一千萬每秒的請(qǐng)求干掉了，把這個(gè)服務(wù)挪入到接入服務(wù)。但這樣做，有一個(gè)前提：不能降低接入服務(wù)的穩(wěn)定性。因?yàn)椴粏问谴和頁(yè)u一搖請(qǐng)求，微信消息收發(fā)等基礎(chǔ)功能的請(qǐng)求也需要通過接入服務(wù)來中轉(zhuǎn)，假如嵌入的搖一搖邏輯把接入服務(wù)拖垮，將得不償失。

這里面的黑科技在于 C++ 技術(shù)棧的優(yōu)勢(shì)，同一臺(tái)接入服務(wù)器上實(shí)際由不同的進(jìn)程來處理不同的功能，達(dá)到了隔離的效果。而不同進(jìn)程間又可以通過共享內(nèi)存來通信，這比用 Socket 網(wǎng)絡(luò)通信高效多了，又有效的規(guī)避了網(wǎng)絡(luò)層帶來的波動(dòng)性影響，這是我們用 Java 做后臺(tái)沒法做到的事。

切磋，你不能看見別人的功夫套路好，破解難題手到擒來，就輕易決定改練別人的功夫。表面的招式相同，內(nèi)功可能完全不同，就像金庸小說里的鳩摩智非要用小無相功催動(dòng)少林七十二絕技，***弄的自廢武功的結(jié)局。切磋主要是帶給你不同的思維方式，用自己的功夫?qū)で笃平庵馈?/p>

連結(jié)與有效提取

如何選擇干貨，我在前文《技術(shù)干貨的選擇性問題》中***給出的結(jié)論是，給自己結(jié)一張網(wǎng)，形成知識(shí)體系。暫時(shí)離你的網(wǎng)太遠(yuǎn)的技術(shù)潮流性的東西，可以暫不考慮，結(jié)合功利性和興趣原則去不斷編織和擴(kuò)大自己的技術(shù)之網(wǎng)。在編織了一些新結(jié)點(diǎn)入網(wǎng)后，就需要進(jìn)一步有效提取這些結(jié)點(diǎn)的價(jià)值。

剛做 IM 時(shí)，曾經(jīng)有個(gè)疑惑，就是 IM 的長(zhǎng)連接接入系統(tǒng)，到底單機(jī)接入多少長(zhǎng)連接算合適的?很早時(shí)運(yùn)維對(duì)于長(zhǎng)連接有個(gè)報(bào)警指標(biāo)是單機(jī) 1 萬，但當(dāng)時(shí)我用 Java NIO 開 2G ***堆內(nèi)存，在可接受的 GC 停頓下，在一臺(tái) 4 核物理機(jī)上測(cè)試極限支撐 10 萬長(zhǎng)連接是可用的。那么平時(shí)保守點(diǎn)，使用測(cè)試容量的一半 5 萬應(yīng)該是可以的。

之后一次機(jī)會(huì)去拜訪了當(dāng)時(shí)阿里旺旺的后端負(fù)責(zé)人，我們也討論到了這個(gè)長(zhǎng)連接的數(shù)量問題。當(dāng)時(shí)淘寶有 600 萬賣家同時(shí)在線，另外大概還有 600 萬買家實(shí)時(shí)在線。所以同時(shí)大概有 1200 萬用戶在線，而當(dāng)時(shí)他們后端的接入服務(wù)器有 400 臺(tái)，也就是每臺(tái)保持 3 萬連接。他說，這不是一個(gè)技術(shù)限制，而是業(yè)務(wù)限制。因?yàn)閱螜C(jī)故障率高，一旦機(jī)器掛了，上面的所有用戶會(huì)短暫掉線并重連。若一次性掉線用戶數(shù)太多，恢復(fù)時(shí)間會(huì)加長(zhǎng)，這會(huì)對(duì)淘寶的訂單交易成交產(chǎn)生明顯的影響。

他還說了一次事故，整個(gè)機(jī)房故障，導(dǎo)致單機(jī)房 600 萬用戶同時(shí)掉線。整個(gè)故障和自動(dòng)切換恢復(fù)時(shí)間持續(xù)了數(shù)十分鐘，在此期間淘寶交易額也同比下降了約 40% 左右。因?yàn)檫@種旺旺在線和交易的高度相關(guān)性，所以才限制了單機(jī)長(zhǎng)連接的數(shù)量，而當(dāng)時(shí)已經(jīng)有***的單機(jī)長(zhǎng)連接實(shí)驗(yàn)證明是可行的。

在微信春晚紅包的那篇文章里提到：

簡(jiǎn)單算一下，大概就是 228.8 萬單機(jī)長(zhǎng)連接的容量規(guī)劃，14.6 億怕是以當(dāng)時(shí)全國(guó)人口作為預(yù)估上限了。實(shí)際當(dāng)然沒有那么多，但估計(jì)單機(jī)百萬長(zhǎng)連接左右應(yīng)該是有的。這是一個(gè)相當(dāng)不錯(cuò)的數(shù)量了，而采用 Java 技術(shù)棧要實(shí)現(xiàn)這個(gè)單機(jī)數(shù)量，恐怕也需要多進(jìn)程，不然大堆的 GC 停頓就是一個(gè)不可接受和需要單獨(dú)調(diào)優(yōu)的工作了。

連結(jié)，便是這樣一個(gè)針對(duì)同一個(gè)問題或場(chǎng)景，將你已知的部分連結(jié)上新的知識(shí)和實(shí)踐，形成更大的網(wǎng)，再去探索更多的未知。

如何去吸收和消化信息，這是一個(gè)智者見智的事情，但在信息爆炸的時(shí)代都在忙于過濾和收集信息，卻從不分配點(diǎn)時(shí)間去處理和提煉信息，也許你已經(jīng)忘記了收集的初心了。

【本文是51CTO專欄作者胡峰的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)聯(lián)系作者本人獲取授權(quán)】

戳這里，看該作者更多好文