本文原文內(nèi)容來自InfoQ的技術(shù)分享，本次有修訂、勘誤和加工，感謝原作者的分享。
1、前言
自從2018年8月20日子彈短信在錘子發(fā)布會露面之后（詳見《老羅最新發(fā)布了“子彈短信”這款I(lǐng)M，主打熟人社交能否對標微信？》），關(guān)于它的討論不絕于耳，7 天融資 1.5 億的傳聞更是將它推到了風(fēng)口浪尖（請見《[資訊] “子彈短信”發(fā)布一周即融得1.5億資金》）。
同時很多技術(shù)人開始分析它的代碼，挖出了它的 IM 系統(tǒng)其實不是自研，而是使用網(wǎng)易云信提供的第三方服務(wù)（即時通訊網(wǎng)注：其實子彈短信租用網(wǎng)易云信的SDK是共開的秘密，子彈短信官方并沒有回避）。
▲ 子彈短信火了之后，網(wǎng)易云信也狠狠地蹭了幾次熱點
有人質(zhì)疑說，第三方的 SDK 做一個 demo 跑跑還可以，能拿來開發(fā)正式產(chǎn)品嗎？其實，在實時通信領(lǐng)域，近年來的研發(fā)重點并不是即時通訊技術(shù)本身，而是由直播帶火的實時音視頻技術(shù)。隨著 5G 的到來，WebRTC、SD-RTN、AV1 等新興技術(shù)正在快速的發(fā)展當(dāng)中。相對來說，即時通訊的技術(shù)已經(jīng)比較成熟了，據(jù)了解，從子彈短信上線以來，到現(xiàn)在近 800 萬激活用戶，其服務(wù)一直保持穩(wěn)定運行中。
子彈短信背后的網(wǎng)易云信即可作為一個研究的案例，本文內(nèi)容來自對網(wǎng)易云信首席架構(gòu)師周梁偉的采訪，采訪內(nèi)容主要圍繞網(wǎng)易云信這種海量用戶IM云平臺的關(guān)鍵技術(shù)難點以及對應(yīng)的技術(shù)實踐。
言歸正傳，我們往下看正經(jīng)內(nèi)容。。。
學(xué)習(xí)交流：
- 即時通訊開發(fā)交流3群：185926912[推薦]
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
（本文同步發(fā)布于：http://www.52im.net/thread-1961-1-1.html）
2、IM 開發(fā)當(dāng)中的技術(shù)難點
周梁偉介紹，子彈短信目前主要使用網(wǎng)易云信的功能有：
1）即時通信的核心功能，比如 IM 的移動通信，包括圖片、文件等等；
2）同時也使用了視頻通話的功能，包括點對點，以及群聊形式的視頻和語音通話。
在發(fā)布會的介紹中重點演示的語言轉(zhuǎn)文字功能并非網(wǎng)易云信提供，據(jù)猜測應(yīng)該使用的是錘子手機之前使用過的語音處理服務(wù)提供商科大訊飛提供的功能。
對于 IM，更關(guān)注的是社交產(chǎn)品用戶體驗層面的東西。具體來說就是怎么構(gòu)建一個更好的溝通邏輯，更快速的幫助用戶達到更好的溝通效果？這其實也是子彈短信瞬間能夠火起來的重要原因。所以，IM 開發(fā)中的技術(shù)難點就在于對用戶體驗的追求。
首先：IM 核心關(guān)注點一是消息傳輸?shù)乃俣纫欤婕把訒r方面的問題；第二個是要保證消息的送達率。同時，現(xiàn)在用戶的設(shè)備多樣化，IM 通常需要支持多設(shè)備，又涉及到一個多終端消息同步的問題。
其次：IM 產(chǎn)品的用戶量和活躍度通常都很大，在一些特殊的時間點經(jīng)常容易造成流量的波峰，因此技術(shù)上需要能夠應(yīng)對突發(fā)的量級。所以在前期需要設(shè)計好彈性擴容，對系統(tǒng)的伸縮能力提前做好設(shè)計。
最后：IM 包含用戶的大量隱私，一旦被黑客攻破不堪設(shè)想，同時在公共安全方面的影響也越來越受重視，因此很多 IM 產(chǎn)品都投入精力做內(nèi)容安全、平臺可控方面的工作。
本節(jié)內(nèi)容中，涉及IM消息送達保證方面的技術(shù)，請深入閱讀以下文章：
《從客戶端的角度來談?wù)勔苿佣薎M的消息可靠性和送達機制》
《IM消息送達保證機制實現(xiàn)(一)：保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(xiàn)(二)：保證離線消息的可靠投遞》
《IM群聊消息如此復(fù)雜，如何保證不丟不重？》
《完全自已開發(fā)的IM該如何設(shè)計“失敗重試”機制？》
涉及IM消息送達效率的資料，請深入閱讀以下文章：
《現(xiàn)代移動端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請求速度、弱網(wǎng)適應(yīng)、安全保障》
《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡(luò)的“弱”和“慢”》
《移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》
《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？》
涉及IM高性能架構(gòu)方面的資料，請深入閱讀以下文章：
《淺談IM系統(tǒng)的架構(gòu)設(shè)計》
《簡述移動端IM開發(fā)的那些坑：架構(gòu)設(shè)計、通信協(xié)議和客戶端》
《一套海量在線用戶的移動端IM架構(gòu)設(shè)計實踐分享(含詳細圖文)》
《一套原創(chuàng)分布式即時通訊(IM)系統(tǒng)理論架構(gòu)方案》
《從零到卓越：京東客服即時通訊系統(tǒng)的技術(shù)架構(gòu)演進歷程》
《蘑菇街即時通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇》
《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進之路PPT》
《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計實踐》
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計的方方面面》
《以微博類應(yīng)用場景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計步驟》
《快速理解高性能HTTP服務(wù)端的負載均衡技術(shù)原理》
有關(guān)IM通信安全的資料，請深入閱讀以下文章：
《即時通訊安全篇（二）：探討組合加密算法在IM中的應(yīng)用》
《傳輸層安全協(xié)議SSL/TLS的Java平臺實現(xiàn)簡介和Demo演示》
《理論聯(lián)系實際：一套典型的IM通信協(xié)議設(shè)計詳解（含安全層設(shè)計）》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通訊服務(wù)的技術(shù)實踐分享》
《通俗易懂：一篇掌握即時通訊的消息傳輸安全原理》
《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》
>> 更多同類文章 ……
3、IM 通信協(xié)議設(shè)計的考量
其實在上面沒有提到一點，也是在 IM 中最為核心的一點，就是通信協(xié)議的開發(fā)。
在這方面，目前行業(yè)里有一些開源的方案如 XMPP、MQTT 等（MQTT請見《掃盲貼：認識MQTT通信協(xié)議》）。但是，這些開源的方案對后期產(chǎn)品的增長，用戶量級的突發(fā)式爆增是非常不利的。
開源通信協(xié)議的劣勢主要有幾方面：
1）這些開源項目出現(xiàn)的較早，其實并沒有考慮到移動互聯(lián)網(wǎng) 2/3/4G 等復(fù)雜的網(wǎng)絡(luò)情況，包括應(yīng)對電信運營商在信令等方面的復(fù)雜設(shè)置；
2）目前鮮有對這些開源技術(shù)軟件和服務(wù)把控度比較強的技術(shù)團隊，難以進行源碼級的擴展和修改，出現(xiàn)問題也難以及時解決；
3）商業(yè)化 IM 里消息的傳遞在過程中是否安全可控是非常核心的要求，如果使用一些標準的協(xié)議，就代表了這個東西是開放的，也就是說是有能夠被破解的潛在風(fēng)險，在企業(yè)服務(wù)場景里有些企業(yè)也因此而拒絕通信協(xié)議的開源。
有鑒于此，市面上注流的IM包括 QQ、微信等在內(nèi)的,通信協(xié)議都是自研的。
▲ 市面上部分主流IM的通信協(xié)議（本圖來自《史上最全即時通訊軟件簡史（精編大圖版）[附件下載]》）
一個成熟的通信協(xié)議都是多年經(jīng)驗沉淀下來的，網(wǎng)易云信的 IM 服務(wù)并不是憑空產(chǎn)生，而是繼承了之前網(wǎng)易泡泡、易信的技術(shù)。對于通信協(xié)議需要關(guān)注的地方，周梁偉介紹，云信的私有協(xié)議首先關(guān)注幾個層面，一是安全性，也就是通信過程中所有數(shù)據(jù)序列化的算法、加密的機制，以及加密的級別，全都是自己定義的。同時也考慮到，在整個傳輸?shù)倪^程中可能長期存在的安全風(fēng)險，比方第三方的攻擊，以及數(shù)據(jù)在網(wǎng)絡(luò)流轉(zhuǎn)過程中被拷貝和重放的潛在安全風(fēng)險，這些在設(shè)計過程中都需要被規(guī)避掉。
第二個，因為現(xiàn)在即時通信更多的往移動互聯(lián)網(wǎng)方向發(fā)展，用戶的網(wǎng)絡(luò)環(huán)境具有非常強的多變性，經(jīng)常屬于跨網(wǎng)和弱網(wǎng)的環(huán)境下，所以傳輸協(xié)議非常關(guān)注對消息的壓縮，以及網(wǎng)絡(luò)帶寬的占用，網(wǎng)易云信在這方面也做了很多的工作。這也和標準協(xié)議有差別，標準協(xié)議的消息結(jié)構(gòu)都是 JSON 或 XML 格式，承載同樣的有效內(nèi)容，最終呈現(xiàn)出來的消息體會變得非常龐大，但在這一塊私有協(xié)議可以做得非常好。
還有一個很重要的方面是私有協(xié)議對擴展性的支持，傳統(tǒng)的協(xié)議不能做到很好的擴展，或者做完擴展后整個消息會變得非常大。對私有協(xié)議來說，可以隨時的做各種場景的定義、各種新協(xié)議的增加和各種版本的兼容。
其實目前業(yè)務(wù)主流IM，使用的私有協(xié)議格式基本都是基于Google開源的Protobuf（或者改進優(yōu)化分支，比如微信就是基本Profobuf優(yōu)化后的分支）。
有關(guān)Protobuf的文章，請深入閱讀以下內(nèi)容：
《Protobuf通信協(xié)議詳解：代碼演示、詳細原理介紹等》
《如何選擇即時通訊應(yīng)用的數(shù)據(jù)傳輸格式》
《強列建議將Protobuf作為你的即時通訊應(yīng)用數(shù)據(jù)傳輸格式》
《全方位評測：Protobuf性能到底有沒有比JSON快5倍？》
《移動端IM開發(fā)需要面對的技術(shù)問題（含通信協(xié)議選擇）》
《金蝶隨手記團隊分享：還在用JSON? Protobuf讓數(shù)據(jù)傳輸更省更快(原理篇)》
《金蝶隨手記團隊分享：還在用JSON? Protobuf讓數(shù)據(jù)傳輸更省更快(實戰(zhàn)篇)》
4、如何做到IM消息的高到達率和低延遲
對一個 IM 平臺來說，到達率和即時性是兩個核心功能點。對于消息傳輸機制的設(shè)計來說，首先設(shè)計的時候把 100% 的送達率作為一個核心要求，關(guān)鍵性的指標，要抱著必須要達到的態(tài)度來設(shè)計。
主要的技術(shù)手段是通過不同消息類型的相互組合來補充。
消息類型分為以下幾種：
1）一種是在線消息：在線消息是指雙方用戶都處于實時在線的情況，在網(wǎng)絡(luò)中實時送達；
2）另一個是離線消息：如果用戶當(dāng)時不在線，可能處于暫時離線的狀態(tài)，我們把消息在緩存中存下來，緩存的消息可以保證更高的讀取效率，用戶下次上線的時候可以很快的取回來。
但僅僅靠在線和緩存是不夠的，因為緩存可能會丟，網(wǎng)絡(luò)可能出現(xiàn)會丟包，所以我們在數(shù)據(jù)庫里儲存關(guān)鍵消息。這類的消息是強一致性的要求，用戶發(fā)送完成之后，服務(wù)端必須要確認數(shù)據(jù)被存入關(guān)鍵數(shù)據(jù)庫里，否則客戶端上的表現(xiàn)是消息未發(fā)送成功，是可以觸發(fā)到上層去從事這種機制的。
存在數(shù)據(jù)庫里的消息，用戶可以在更長時間的離線以后實時同步，即使緩存里沒有也可以拿到。另外還要考慮更長時間范疇的消息存儲，應(yīng)用的場景是什么呢？用戶可能一個月以前開始使用這個 IM 產(chǎn)品，或者 1 年前使用了這個 IM 產(chǎn)品，現(xiàn)在更換手機了，更換手機以后消息如何在新手機上拿到？這種稱為云端的歷史消息（詳見《淺談移動端IM的多點登陸和消息漫游原理》）。
在所有消息的流轉(zhuǎn)的過程中，這個消息到最后被存儲在數(shù)據(jù)倉庫里，數(shù)據(jù)倉庫存儲消息的時間維度可能是 1 年或者幾年。在用戶跨平臺或者更換新設(shè)備之后，可以隨時從云端再獲取到這部分的消息。通過不同消息的相互組合之后，我們是可以達到消息 100% 送達的效果。
另外，從即時性的角度來說，現(xiàn)在的 IM 基本都采用長連接的方案作為消息實時送達的渠道。因為現(xiàn)在的移動設(shè)備對于 App 在后臺的服務(wù)有限制，以前 Android 上還流行過后臺保活、互相喚醒等等方式（請見《應(yīng)用保活終極總結(jié)(三)：Android6.0及以上的?；顚嵺`(被殺復(fù)活篇)》、《Android進程?；钤斀猓阂黄恼陆鉀Q你的所有疑問》、《深入的聊聊Android消息推送這件小事》）。
不過，在 Android 系統(tǒng)的不斷更新和手機廠商打壓下，App 在后臺的保活能力逐漸消失，現(xiàn)在基本都是接入各大推送平臺，IM 消息即時性在 App 開發(fā)者這里能做的不多，主要看推送服務(wù)的實力了（Android高版本對后臺保活越來越嚴格了，比如AndroidP的《Android P正式版即將到來：后臺應(yīng)用?；?、消息推送的真正噩夢》）。
5、IM 實時消息監(jiān)控和分析
有一個以前人們不怎么提，但實際存在的問題，就是 IM 的合規(guī)。IM 是謠言等不良信息的高發(fā)地，在印度，WhatsApp 上謠言流傳致使私刑案頻發(fā)，到目前印度官方仍束手無策。
周梁偉介紹，IM 通信平臺目前承載很多很重要的功能是傳統(tǒng)運營商做的部分業(yè)務(wù)。以前我們用短信、電話，現(xiàn)在大家轉(zhuǎn)移到即時通信的工具上，對監(jiān)管層來說是有要求的。從平臺角度來說，本身做的是一個消息通道的功能，消息就代表了會有輿論的傳播，特別在群組或者聊天室這樣參與者眾多的狀態(tài)下，所以輿論監(jiān)管對平臺來說是必須承擔(dān)的責(zé)任，這是監(jiān)管層面對平臺運營方的要求。平臺必須具備內(nèi)容審核的能力，云信會按照開發(fā)者的配置把平臺上產(chǎn)生的內(nèi)容在云端保存起來，以備監(jiān)管層隨時做內(nèi)容的審核。
同時在開發(fā)者 APP 運營的層面，內(nèi)容運營或者內(nèi)容審核、內(nèi)容安全運營都是非常重要的范疇，目前網(wǎng)易云信和子彈短信在一起合作解決這樣的問題。網(wǎng)易云信有一個專門的團隊會負責(zé)內(nèi)容審核的工作，包括會對所有的數(shù)據(jù)提取特征，會去做同步的、實時的內(nèi)容審核，以及異步的內(nèi)容審核，甚至涉及到機器學(xué)習(xí)的功能和人工介入審核的工作。
從技術(shù)層面來說，關(guān)于內(nèi)容審核，目前用到產(chǎn)品上有兩種場景，一種是同步審核，在消息發(fā)送過程中，這個消息就可以直接進入到內(nèi)容審核系統(tǒng)里進行識別，如果識別出來有敏感詞或者安全風(fēng)險，會直接攔截掉。在第一時間避免消息的傳播。還有一種內(nèi)容，用戶發(fā)的視頻文件和非常大的圖片，像這樣的內(nèi)容做實時審核會帶來比較高的時間成本，這種情況下云信目前的做法是采用異步審核，消息投遞出去了會進入審核系統(tǒng)，里面有機器算法的部分和人工審核的部分去進行鑒別，一旦審核出此消息違規(guī)，會觸發(fā) IM 消息撤回和刪除的能力，避免風(fēng)險的二次傳播。
6、如何保證IM消息安全性
對 IM 來說，除了用戶數(shù)據(jù)需要做安全防范外，還需要關(guān)注消息內(nèi)容的安全，包括兩個層面：
1）一個是：消息傳輸層面的安全，在傳輸過程中，通過協(xié)議和加密，以保證傳輸過程中的消息是不可逆的。惡意用戶即使抓到網(wǎng)絡(luò)傳輸?shù)陌矝]有辦法破譯出來；
2）另一個：加密級別做到會話級別，是指一個用戶的一次長鏈接行為，即使同一個用戶多次登錄，或者在不同時間點登錄，加密的密鑰都是不一樣的。所以能夠保證傳輸過程中是安全的。
第二個維度是，消息存儲過程中是安全的，這里分為幾個角度：
1）是對數(shù)據(jù)做自定義的序列化的方式，包括數(shù)據(jù)存儲后，序列化或反序列化過程中的效率更高；
2）是如果泄露，是不可見、不可讀的。另外，對于關(guān)鍵數(shù)據(jù)需要做加密，避免出現(xiàn)拖庫之類的行為。
即時通訊網(wǎng)注：什么是黑客拖庫？
拖庫本來是數(shù)據(jù)庫領(lǐng)域的術(shù)語，指從數(shù)據(jù)庫中導(dǎo)出數(shù)據(jù)。到了黑客攻擊泛濫的今天，它被用來指網(wǎng)站遭到入侵后，黑客竊取其數(shù)據(jù)庫。
拖庫可以通過數(shù)據(jù)庫安全防護技術(shù)解決，數(shù)據(jù)庫安全技術(shù)主要包括：數(shù)據(jù)庫漏掃、數(shù)據(jù)庫加密、數(shù)據(jù)庫防火墻、數(shù)據(jù)脫敏、數(shù)據(jù)庫安全審計系統(tǒng)。
另外，周梁偉表示，用戶怎么使用云平臺才能在過程中保證業(yè)務(wù)數(shù)據(jù)的安全，一般他們會建議，在使用平臺的時候?qū)I(yè)務(wù)數(shù)據(jù)做脫敏。比如說開發(fā)者自己的平臺是用用戶的手機號作為用戶賬號的，在云信里面注冊用戶的賬號的時候，可以在業(yè)務(wù)層做一個關(guān)聯(lián)。使用隨機數(shù)或者隨機的、無意義的字符串作為云平臺數(shù)據(jù)庫里的 ID，手機號的映射關(guān)系僅僅在業(yè)務(wù)方。通過這種脫敏保證數(shù)據(jù)的安全。
有關(guān)IM安全方面的文章，請深入閱讀：
《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
《即時通訊安全篇（二）：探討組合加密算法在IM中的應(yīng)用》
《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》
《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風(fēng)險》
《即時通訊安全篇（五）：對稱加密技術(shù)在Android平臺上的應(yīng)用實踐》
《即時通訊安全篇（六）：非對稱加密技術(shù)的原理與應(yīng)用實踐》
《傳輸層安全協(xié)議SSL/TLS的Java平臺實現(xiàn)簡介和Demo演示》
《理論聯(lián)系實際：一套典型的IM通信協(xié)議設(shè)計詳解（含安全層設(shè)計）》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通訊服務(wù)的技術(shù)實踐分享》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端安全通信的利器——端到端加密（E2EE）技術(shù)詳解》
《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《通俗易懂：一篇掌握即時通訊的消息傳輸安全原理》
《IM開發(fā)基礎(chǔ)知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《快速讀懂量子通信、量子加密技術(shù)》
《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》
>> 更多同類文章 ……
7、本文小結(jié)
看完上面的內(nèi)容，想必你對 IM 系統(tǒng)研發(fā)會遇到哪些問題，以及相應(yīng)的解決方案有了大致的概念。當(dāng)然這里只提到了其中的一些，還有其它方面，比如不同用戶量級的系統(tǒng)需要不同的架構(gòu)，QQ 在它的發(fā)展過程中就經(jīng)歷多次重構(gòu)，感興趣的可以繼續(xù)閱讀下面的文章。
《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進之路PPT》
《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計實踐》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》
《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進歷程（一）》
《17年的實踐：騰訊海量產(chǎn)品的技術(shù)方法論》
《WhatsApp技術(shù)實踐分享：32人工程團隊創(chuàng)造的技術(shù)神話》
《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實踐總結(jié)》
《王者榮耀2億用戶量的背后：產(chǎn)品定位、技術(shù)架構(gòu)、網(wǎng)絡(luò)方案等》
《以微博類應(yīng)用場景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計步驟》
《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計實踐》
《微信后臺團隊：微信后臺異步消息隊列的優(yōu)化升級實踐分享》
《一份微信后臺技術(shù)架構(gòu)的總結(jié)性筆記》
《架構(gòu)之道：3個程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》
《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進歷程（一）》
《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進歷程（二）》
（本文同步發(fā)布于：http://www.52im.net/thread-1961-1-1.html）