老羅在今年8月份發布了子彈短信在錘子，之后關于它的討論不絕于耳，7 天融資 1.5 億的傳聞更是將它推到了風口浪尖。FT12短網址的小編也是第一時間下載并進行了試用。同時很多技術人開始分析它的代碼，挖出了它的 IM 系統其實不是自研，而是使用網易云信提供的第三方服務。有人質疑說，第三方的 SDK 做一個 demo 跑跑還可以，能拿來開發正式產品嗎？本文就想來談談 IM 開發的難點以及目前第三方 IM 服務的現狀。

其實，在 RTC 實時通信領域，近年來的研發重點并不是 IM，而是由直播帶火的實時音視頻，隨著 5G 的到來，WebRTC、SD-RTN、AV1 等新興技術正在快速的發展當中。相對來說，IM 的技術已經比較成熟了，據了解，從子彈短信上線以來，到現在近 800 萬激活用戶，其服務一直保持穩定運行中。其背后的網易云信即可作為一個研究的案例，InfoQ 對網易云信首席架構師周梁偉進行了采訪，本文根據采訪內容整理成文。

周梁偉介紹，子彈短信目前主要使用網易云信即時通信的核心功能，比如 IM 的移動通信，包括圖片、文件等等；同時也使用了視頻通話的功能，包括點對點，以及群聊形式的視頻和語音通話。在發布會的介紹中重點演示的語言轉文字功能并非網易云信提供，據猜測應該使用的是錘子手機之前使用過的語音處理服務提供商科大訊飛提供的功能。

對于 IM，更關注的是社交產品用戶體驗層面的東西。具體來說就是怎么構建一個更好的溝通邏輯，更快速的幫助用戶達到更好的溝通效果？這其實也是子彈短信瞬間能夠火起來的重要原因。所以，IM 開發中的技術難點就在于對用戶體驗的追求。

首先，IM 核心關注點一是消息傳輸的速度要快，涉及延時方面的問題；第二個是要保證消息的送達率。同時，現在用戶的設備多樣化，IM 通常需要支持多設備，又涉及到一個多終端消息同步的問題。

其次，IM 產品的用戶量和活躍度通常都很大，在一些特殊的時間點經常容易造成流量的波峰，因此技術上需要能夠應對突發的量級。所以在前期需要設計好彈性擴容，對系統的伸縮能力提前做好設計。

最后，IM 包含用戶的大量隱私，一旦被黑客攻破不堪設想，同時在公共安全方面的影響也越來越受重視，因此很多 IM 產品都投入精力做內容安全、平臺可控方面的工作。

其實在上面沒有提到一點，也是在 IM 中最為核心的一點，就是通信協議的開發。在這方面，目前行業里有一些開源的方案如 XMPP、MQTT 等，但是，這些開源的方案對后期產品的增長，用戶量級的突發式爆增是非常不利的。原因有幾方面，一個是這些開源項目出現的較早，其實并沒有考慮到移動互聯網 2/3/4G 等復雜的網絡情況，包括應對電信運營商在信令等方面的復雜設置，另外，目前鮮有對這些開源技術軟件和服務把控度比較強的技術團隊，難以進行源碼級的擴展和修改，出現問題也難以及時解決，以及商業化 IM 里消息的傳遞在過程中是否安全可控是非常核心的要求，如果使用一些標準的協議，就代表了這個東西是開放的，也就是說是有能夠被破解的潛在風險，在企業服務場景里有些企業也因此而拒絕通信協議的開源。因此，包括 QQ、微信等在內的很多 IM 產品的通信協議都是自研的。

一個成熟的通信協議都是多年經驗沉淀下來的，網易云信的 IM 服務并不是憑空產生，而是繼承了之前網易泡泡、易信的技術。對于通信協議需要關注的地方，周梁偉介紹，云信的私有協議首先關注幾個層面，一是安全性，也就是通信過程中所有數據序列化的算法、加密的機制，以及加密的級別，全都是自己定義的。同時也考慮到，在整個傳輸的過程中可能長期存在的安全風險，比方第三方的攻擊，以及數據在網絡流轉過程中被拷貝和重放的潛在安全風險，這些在設計過程中都需要被規避掉。

第二個，因為現在即時通信更多的往移動互聯網方向發展，用戶的網絡環境具有非常強的多變性，經常屬于跨網和弱網的環境下，所以傳輸協議非常關注對消息的壓縮，以及網絡帶寬的占用，網易云信在這方面也做了很多的工作。這也和標準協議有差別，標準協議的消息結構都是 JSON 或 XML 格式，承載同樣的有效內容，最終呈現出來的消息體會變得非常龐大，但在這一塊私有協議可以做得非常好。

還有一個很重要的方面是私有協議對擴展性的支持，傳統的協議不能做到很好的擴展，或者做完擴展后整個消息會變得非常大。對私有協議來說，可以隨時的做各種場景的定義、各種新協議的增加和各種版本的兼容。

對一個 IM 平臺來說，到達率和即時性是兩個核心功能點。對于消息傳輸機制的設計來說，首先設計的時候把 100% 的送達率作為一個核心要求，關鍵性的指標，要抱著必須要達到的態度來設計。

主要的技術手段是通過不同消息類型的相互組合來補充。

消息類型分為以下幾種，一種是在線消息，在線消息是指雙方用戶都處于實時在線的情況，在網絡中實時送達。如果用戶當時不在線，可能處于暫時離線的狀態，我們把消息在緩存中存下來，緩存的消息可以保證更高的讀取效率，用戶下次上線的時候可以很快的取回來。

但僅僅靠在線和緩存是不夠的，因為緩存可能會丟，網絡可能出現會丟包，所以我們在數據庫里儲存關鍵消息。這類的消息是強一致性的要求，用戶發送完成之后，服務端必須要確認數據被存入關鍵數據庫里，否則客戶端上的表現是消息未發送成功，是可以觸發到上層去從事這種機制的。

存在數據庫里的消息，用戶可以在更長時間的離線以后實時同步，即使緩存里沒有也可以拿到。另外還要考慮更長時間范疇的消息存儲，應用的場景是什么呢？用戶可能一個月以前開始使用這個 IM 產品，或者 1 年前使用了這個 IM 產品，現在更換手機了，更換手機以后消息如何在新手機上拿到？這種稱為云端的歷史消息。在所有消息的流轉的過程中，這個消息到最后被存儲在數據倉庫里，數據倉庫存儲消息的時間維度可能是 1 年或者幾年。在用戶跨平臺或者更換新設備之后，可以隨時從云端再獲取到這部分的消息。通過不同消息的相互組合之后，我們是可以達到消息 100% 送達的效果。

另外，從即時性的角度來說，現在的 IM 基本都采用長連接的方案作為消息實時送達的渠道。因為現在的移動設備對于 App 在后臺的服務有限制，以前 Android 上還流行過后臺?；?、互相喚醒等等方式，在 Android 系統更新和手機廠商打壓下逐漸消失，現在基本都是接入各大推送平臺，IM 消息即時性在 App 開發者這里能做的不多，主要看推送服務的實力了。

有一個以前人們不怎么提，但實際存在的問題，就是 IM 的合規。IM 是謠言等不良信息的高發地，在印度，WhatsApp 上謠言流傳致使私刑案頻發，到目前印度官方仍束手無策。

周梁偉介紹，IM 通信平臺目前承載很多很重要的功能是傳統運營商做的部分業務。以前我們用短信、電話，現在大家轉移到即時通信的工具上，對監管層來說是有要求的。從平臺角度來說，本身做的是一個消息通道的功能，消息就代表了會有輿論的傳播，特別在群組或者聊天室這樣參與者眾多的狀態下，所以輿論監管對平臺來說是必須承擔的責任，這是監管層面對平臺運營方的要求。平臺必須具備內容審核的能力，云信會按照開發者的配置把平臺上產生的內容在云端保存起來，以備監管層隨時做內容的審核。

同時在開發者 APP 運營的層面，內容運營或者內容審核、內容安全運營都是非常重要的范疇，目前網易云信和子彈短信在一起合作解決這樣的問題。網易云信有一個專門的團隊會負責內容審核的工作，包括會對所有的數據提取特征，會去做同步的、實時的內容審核，以及異步的內容審核，甚至涉及到機器學習的功能和人工介入審核的工作。

從技術層面來說，關于內容審核，目前用到產品上有兩種場景，一種是同步審核，在消息發送過程中，這個消息就可以直接進入到內容審核系統里進行識別，如果識別出來有敏感詞或者安全風險，會直接攔截掉。在第一時間避免消息的傳播。還有一種內容，用戶發的視頻文件和非常大的圖片，像這樣的內容做實時審核會帶來比較高的時間成本，這種情況下云信目前的做法是采用異步審核，消息投遞出去了會進入審核系統，里面有機器算法的部分和人工審核的部分去進行鑒別，一旦審核出此消息違規，會觸發 IM 消息撤回和刪除的能力，避免風險的二次傳播。

對 IM 來說，除了用戶數據需要做安全防范外，還需要關注消息內容的安全。包括兩個層面，一個是消息傳輸層面的安全，在傳輸過程中，通過協議和加密，以保證傳輸過程中的消息是不可逆的。惡意用戶即使抓到網絡傳輸的包也沒有辦法破譯出來。同時，加密級別做到會話級別，是指一個用戶的一次長鏈接行為，即使同一個用戶多次登錄，或者在不同時間點登錄，加密的密鑰都是不一樣的。所以能夠保證傳輸過程中是安全的。

第二個維度是，消息存儲過程中是安全的。這里分為幾個角度，一是對數據做自定義的序列化的方式，包括數據存儲后，序列化或反序列化過程中的效率更高。二是如果泄露，是不可見、不可讀的。另外，對于關鍵數據需要做加密，避免出現脫庫之類的行為。

另外，周梁偉表示，用戶怎么使用云平臺才能在過程中保證業務數據的安全，一般他們會建議，在使用平臺的時候對業務數據做脫敏。比如說開發者自己的平臺是用用戶的手機號作為用戶賬號的，在云信里面注冊用戶的賬號的時候，可以在業務層做一個關聯。使用隨機數或者隨機的、無意義的字符串作為云平臺數據庫里的 ID，手機號的映射關系僅僅在業務方。通過這種脫敏保證數據的安全。

看完上面的內容，想必你對 IM 系統研發會遇到哪些問題，以及相應的解決方案有了大致的概念。當然這里只提到了其中的一些，還有其它方面，比如不同用戶量級的系統需要不同的架構，短網址在其規模不斷壯大后，對于高并發架構也是有非常大的需求，有興趣的人可以翻看ft短網址之前的文章。