子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐
本文原文內容來自InfoQ的技術分享，本次有修訂、勘誤和加工，感謝原做者的分享。php
一、前言
自從2018年8月20日子彈短信在錘子發佈會露面以後（詳見《老羅最新發布了「子彈短信」這款IM，主打熟人社交可否對標微信？》），關於它的討論不絕於耳，7 天融資 1.5 億的傳聞更是將它推到了風口浪尖（請見《[資訊] 「子彈短信」發佈一週即融得1.5億資金》）。html
同時不少技術人開始分析它的代碼，挖出了它的 IM 系統其實不是自研，而是使用網易雲信提供的第三方服務（即時通信網注：其實子彈短信租用網易雲信的SDK是共開的祕密，子彈短信官方並無迴避）。程序員
有人質疑說，第三方的 SDK 作一個 demo 跑跑還能夠，能拿來開發正式產品嗎？其實，在實時通訊領域，近年來的研發重點並非即時通信技術自己，而是由直播帶火的實時音視頻技術。隨着 5G 的到來，WebRTC、SD-RTN、AV1 等新興技術正在快速的發展當中。相對來講，即時通信的技術已經比較成熟了，據瞭解，從子彈短信上線以來，到如今近 800 萬激活用戶，其服務一直保持穩定運行中。算法
子彈短信背後的網易雲信便可做爲一個研究的案例，本文內容來自對網易雲信首席架構師周梁偉的採訪，採訪內容主要圍繞網易雲信這種海量用戶IM雲平臺的關鍵技術難點以及對應的技術實踐。數據庫
言歸正傳，咱們往下看正經內容。。。緩存
學習交流：安全
- 即時通信開發交流3羣：185926912[推薦]服務器
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》微信
（本文同步發佈於：http://www.52im.net/thread-1961-1-1.html）網絡
二、IM 開發當中的技術難點
周梁偉介紹，子彈短信目前主要使用網易雲信的功能有：
1）即時通訊的核心功能，好比 IM 的移動通訊，包括圖片、文件等等；
2）同時也使用了視頻通話的功能，包括點對點，以及羣聊形式的視頻和語音通話。
在發佈會的介紹中重點演示的語言轉文字功能並不是網易雲信提供，據猜想應該使用的是錘子手機以前使用過的語音處理服務提供商科大訊飛提供的功能。
對於 IM，更關注的是社交產品用戶體驗層面的東西。具體來講就是怎麼構建一個更好的溝通邏輯，更快速的幫助用戶達到更好的溝通效果？這其實也是子彈短信瞬間可以火起來的重要緣由。因此，IM 開發中的技術難點就在於對用戶體驗的追求。
首先：IM 核心關注點一是消息傳輸的速度要快，涉及延時方面的問題；第二個是要保證消息的送達率。同時，如今用戶的設備多樣化，IM 一般須要支持多設備，又涉及到一個多終端消息同步的問題。
其次：IM 產品的用戶量和活躍度一般都很大，在一些特殊的時間點常常容易形成流量的波峯，所以技術上須要可以應對突發的量級。因此在前期須要設計好彈性擴容，對系統的伸縮能力提早作好設計。
最後：IM 包含用戶的大量隱私，一旦被黑客攻破不堪設想，同時在公共安全方面的影響也愈來愈受重視，所以不少 IM 產品都投入精力作內容安全、平臺可控方面的工做。
本節內容中，涉及IM消息送達保證方面的技術，請深刻閱讀如下文章：
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
涉及IM消息送達效率的資料，請深刻閱讀如下文章：
《現代移動端網絡短鏈接的優化手段總結：請求速度、弱網適應、安全保障》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的「弱」和「慢」》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
涉及IM高性能架構方面的資料，請深刻閱讀如下文章：
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
有關IM通訊安全的資料，請深刻閱讀如下文章：
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯繫實際：一套典型的IM通訊協議設計詳解（含安全層設計）》
《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通信服務的技術實踐分享》
《即時通信安全篇（七）：若是這樣來理解HTTPS原理，一篇就夠了》
>> 更多同類文章 ……
三、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性能到底有沒有比JSON快5倍？》
《金蝶隨手記團隊分享：還在用JSON? Protobuf讓數據傳輸更省更快(原理篇)》
《金蝶隨手記團隊分享：還在用JSON? Protobuf讓數據傳輸更省更快(實戰篇)》
四、如何作到IM消息的高到達率和低延遲
對一個 IM 平臺來講，到達率和即時性是兩個核心功能點。對於消息傳輸機制的設計來講，首先設計的時候把 100% 的送達率做爲一個核心要求，關鍵性的指標，要抱着必需要達到的態度來設計。
主要的技術手段是經過不一樣消息類型的相互組合來補充。
消息類型分爲如下幾種：
1）一種是在線消息：在線消息是指雙方用戶都處於實時在線的狀況，在網絡中實時送達；
2）另外一個是離線消息：若是用戶當時不在線，可能處於暫時離線的狀態，咱們把消息在緩存中存下來，緩存的消息能夠保證更高的讀取效率，用戶下次上線的時候能夠很快的取回來。
但僅僅靠在線和緩存是不夠的，由於緩存可能會丟，網絡可能出現會丟包，因此咱們在數據庫裏儲存關鍵消息。這類的消息是強一致性的要求，用戶發送完成以後，服務端必需要確認數據被存入關鍵數據庫裏，不然客戶端上的表現是消息未發送成功，是能夠觸發到上層去從事這種機制的。
存在數據庫裏的消息，用戶能夠在更長時間的離線之後實時同步，即便緩存裏沒有也能夠拿到。另外還要考慮更長時間範疇的消息存儲，應用的場景是什麼呢？用戶可能一個月之前開始使用這個 IM 產品，或者 1 年前使用了這個 IM 產品，如今更換手機了，更換手機之後消息如何在新手機上拿到？這種稱爲雲端的歷史消息（詳見《淺談移動端IM的多點登錄和消息漫遊原理》）。
在全部消息的流轉的過程當中，這個消息到最後被存儲在數據倉庫裏，數據倉庫存儲消息的時間維度多是 1 年或者幾年。在用戶跨平臺或者更換新設備以後，能夠隨時從雲端再獲取到這部分的消息。經過不一樣消息的相互組合以後，咱們是能夠達到消息 100% 送達的效果。
另外，從即時性的角度來講，如今的 IM 基本都採用長鏈接的方案做爲消息實時送達的渠道。由於如今的移動設備對於 App 在後臺的服務有限制，之前 Android 上還流行事後臺保活、互相喚醒等等方式（請見《應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)》、《Android進程保活詳解：一篇文章解決你的全部疑問》、《深刻的聊聊Android消息推送這件小事》）。
不過，在 Android 系統的不斷更新和手機廠商打壓下，App 在後臺的保活能力逐漸消失，如今基本都是接入各大推送平臺，IM 消息即時性在 App 開發者這裏能作的很少，主要看推送服務的實力了（Android高版本對後臺保活愈來愈嚴格了，好比AndroidP的《Android P正式版即將到來：後臺應用保活、消息推送的真正噩夢》）。
五、IM 實時消息監控和分析
有一個之前人們不怎麼提，但實際存在的問題，就是 IM 的合規。IM 是謠言等不良信息的高發地，在印度，WhatsApp 上謠言流傳導致私刑案頻發，到目前印度官方仍一籌莫展。
周梁偉介紹，IM 通訊平臺目前承載不少很重要的功能是傳統運營商作的部分業務。之前咱們用短信、電話，如今你們轉移到即時通訊的工具上，對監管層來講是有要求的。從平臺角度來講，自己作的是一個消息通道的功能，消息就表明了會有輿論的傳播，特別在羣組或者聊天室這樣參與者衆多的狀態下，因此輿論監管對平臺來講是必須承擔的責任，這是監管層面對平臺運營方的要求。平臺必須具有內容審覈的能力，雲信會按照開發者的配置把平臺上產生的內容在雲端保存起來，以備監管層隨時作內容的審覈。
同時在開發者 APP 運營的層面，內容運營或者內容審覈、內容安全運營都是很是重要的範疇，目前網易雲信和子彈短信在一塊兒合做解決這樣的問題。網易雲信有一個專門的團隊會負責內容審覈的工做，包括會對全部的數據提取特徵，會去作同步的、實時的內容審覈，以及異步的內容審覈，甚至涉及到機器學習的功能和人工介入審覈的工做。
從技術層面來講，關於內容審覈，目前用到產品上有兩種場景，一種是同步審覈，在消息發送過程當中，這個消息就能夠直接進入到內容審覈系統裏進行識別，若是識別出來有敏感詞或者安全風險，會直接攔截掉。在第一時間避免消息的傳播。還有一種內容，用戶發的視頻文件和很是大的圖片，像這樣的內容作實時審覈會帶來比較高的時間成本，這種狀況下雲信目前的作法是採用異步審覈，消息投遞出去了會進入審覈系統，裏面有機器算法的部分和人工審覈的部分去進行鑑別，一旦審覈出此消息違規，會觸發 IM 消息撤回和刪除的能力，避免風險的二次傳播。
六、如何保證IM消息安全性
對 IM 來講，除了用戶數據須要作安全防範外，還須要關注消息內容的安全，包括兩個層面：
1）一個是：消息傳輸層面的安全，在傳輸過程當中，經過協議和加密，以保證傳輸過程當中的消息是不可逆的。惡意用戶即便抓到網絡傳輸的包也沒有辦法破譯出來；
2）另外一個：加密級別作到會話級別，是指一個用戶的一次長連接行爲，即便同一個用戶屢次登陸，或者在不一樣時間點登陸，加密的密鑰都是不同的。因此可以保證傳輸過程當中是安全的。
第二個維度是，消息存儲過程當中是安全的，這裏分爲幾個角度：
1）是對數據作自定義的序列化的方式，包括數據存儲後，序列化或反序列化過程當中的效率更高；
2）是若是泄露，是不可見、不可讀的。另外，對於關鍵數據須要作加密，避免出現拖庫之類的行爲。
即時通信網注：什麼是黑客拖庫？
拖庫原本是數據庫領域的術語，指從數據庫中導出數據。到了黑客攻擊氾濫的今天，它被用來指網站遭到入侵後，黑客竊取其數據庫。
拖庫能夠經過數據庫安全防禦技術解決，數據庫安全技術主要包括：數據庫漏掃、數據庫加密、數據庫防火牆、數據脫敏、數據庫安全審計系統。
另外，周梁偉表示，用戶怎麼使用雲平臺才能在過程當中保證業務數據的安全，通常他們會建議，在使用平臺的時候對業務數據作脫敏。好比說開發者本身的平臺是用用戶的手機號做爲用戶帳號的，在雲信裏面註冊用戶的帳號的時候，能夠在業務層作一個關聯。使用隨機數或者隨機的、無心義的字符串做爲雲平臺數據庫裏的 ID，手機號的映射關係僅僅在業務方。經過這種脫敏保證數據的安全。
有關IM安全方面的文章，請深刻閱讀：
《即時通信安全篇（一）：正確地理解和使用Android端加密算法》
《即時通信安全篇（四）：實例分析Android中密鑰硬編碼的風險》
《即時通信安全篇（五）：對稱加密技術在Android平臺上的應用實踐》
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯繫實際：一套典型的IM通訊協議設計詳解（含安全層設計）》
《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通信服務的技術實踐分享》
《Web端即時通信安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》
《即時通信安全篇（七）：若是這樣來理解HTTPS原理，一篇就夠了》
>> 更多同類文章 ……
七、本文小結
看完上面的內容，想必你對 IM 系統研發會遇到哪些問題，以及相應的解決方案有了大體的概念。固然這裏只提到了其中的一些，還有其它方面，好比不一樣用戶量級的系統須要不一樣的架構，QQ 在它的發展過程當中就經歷屢次重構，感興趣的能夠繼續閱讀下面的文章。
《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》
《王者榮耀2億用戶量的背後：產品定位、技術架構、網絡方案等》
（本文同步發佈於：http://www.52im.net/thread-1961-1-1.html）
- 1. 子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐
- 2. 網易實戰分享｜雲信IM SDK接口設計實踐
- 3. 網易來聊聊子彈短信的消息漫遊技術
- 4. IM開發乾貨分享：網易雲信IM客戶端的聊天消息全文檢索技術實踐
- 5. 網易雲信技術分享：IM中的萬人羣聊技術方案實踐總結
- 6. 千億級互聯網平臺技術架構及背後那些事
- 7. 靈雀雲首席架構師：Docker容器的監控技術
- 8. 【轉】子彈短信內部技術分享：Redis
- 9. 子彈短信內部技術分享：Redis
- 10. 餘利華：網易大數據平臺架構實踐分享！
- 更多相關文章...
- • Hibernate的快照技術 - Hibernate教程
- • 網站主機 技術 - 網站主機教程
- • Docker容器實戰(七) - 容器眼光下的文件系統
- • 互聯網組織的未來：剖析GitHub員工的任性之源
-
每一个你不满意的现在，都有一个你没有努力的曾经。