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