[[183716]]

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

循證與決策路徑

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

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

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

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

初一看這個(gè)模型多了一層通知再拉取的冗余，為什么不直接把消息推下去?對，最早期我們自己做 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)樾枰紤]舊終端版本的支持，還得直接推消息本身而并不容易簡化成消息通知來取消掉消息的接收確認(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ù)很多份，通過犧牲空間來換取了每個(gè)人拉取群消息的效率。

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

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

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

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

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

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

這里面的黑科技在于 C++ 技術(shù)棧的優(yōu)勢，同一臺(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í)離你的網(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 的長連接接入系統(tǒng)，到底單機(jī)接入多少長連接算合適的?很早時(shí)運(yùn)維對于長連接有個(gè)報(bào)警指標(biāo)是單機(jī) 1 萬，但當(dāng)時(shí)我用 Java NIO 開 2G ***堆內(nèi)存，在可接受的 GC 停頓下，在一臺(tái) 4 核物理機(jī)上測試極限支撐 10 萬長連接是可用的。那么平時(shí)保守點(diǎn)，使用測試容量的一半 5 萬應(yīng)該是可以的。

之后一次機(jī)會(huì)去拜訪了當(dāng)時(shí)阿里旺旺的后端負(fù)責(zé)人，我們也討論到了這個(gè)長連接的數(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ì)加長，這會(huì)對淘寶的訂單交易成交產(chǎn)生明顯的影響。

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

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

簡單算一下，大概就是 228.8 萬單機(jī)長連接的容量規(guī)劃，14.6 億怕是以當(dāng)時(shí)全國人口作為預(yù)估上限了。實(shí)際當(dāng)然沒有那么多，但估計(jì)單機(jī)百萬長連接左右應(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è)針對同一個(gè)問題或場景，將你已知的部分連結(jié)上新的知識和實(shí)踐，形成更大的網(wǎng)，再去探索更多的未知。

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

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

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