子彈簡訊背後，億級架構IM平臺的技術難點解析
文章內容
自從 8 月 20 號子彈簡訊在錘子釋出會露面之後，關於它的討論不絕於耳，7 天融資 1.5 億的傳聞更是將它推到了風口浪尖。同時很多技術人開始分析它的程式碼，挖出了它的 IM 系統其實不是自研，而是使用網易雲信提供的第三方服務。有人質疑說，第三方的 SDK 做一個 demo 跑跑還可以，能拿來開發正式產品嗎？本文就想來談談 IM 開發的難點以及目前第三方 IM 服務的現狀。
其實，在 RTC 實時通訊領域，近年來的研發重點並不是 IM，而是由直播帶火的實時音視訊，隨著 5G 的到來，WebRTC、SD-RTN、AV1 等新興技術正在快速的發展當中。相對來說，IM 的技術已經比較成熟了，據瞭解，從子彈簡訊上線以來，到現在近 800 萬啟用使用者，其服務一直保持穩定執行中。其背後的網易雲信即可作為一個研究的案例，InfoQ 對網易雲信首席架構師周樑偉進行了採訪，本文根據採訪內容整理成文。
IM 開發當中的技術難點
周樑偉介紹，子彈簡訊目前主要使用網易雲信即時通訊的核心功能，比如 IM 的行動通訊，包括圖片、檔案等等；同時也使用了視訊通話的功能，包括點對點，以及群聊形式的視訊和語音通話。在釋出會的介紹中重點演示的語言轉文字功能並非網易雲信提供，據猜測應該使用的是錘子手機之前使用過的語音處理服務提供商科大訊飛提供的功能。
對於 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 的合規。IM 是謠言等不良資訊的高發地，在印度，WhatsApp 上謠言流傳致使私刑案頻發，到目前印度官方仍束手無策。
周樑偉介紹，IM 通訊平臺目前承載很多很重要的功能是傳統運營商做的部分業務。以前我們用簡訊、電話，現在大家轉移到即時通訊的工具上，對監管層來說是有要求的。從平臺角度來說，本身做的是一個訊息通道的功能，訊息就代表了會有輿論的傳播，特別在群組或者聊天室這樣參與者眾多的狀態下，所以輿論監管對平臺來說是必須承擔的責任，這是監管層面對平臺運營方的要求。平臺必須具備內容稽核的能力，雲信會按照開發者的配置把平臺上產生的內容在雲端儲存起來，以備監管層隨時做內容的稽核。
同時在開發者 APP 運營的層面，內容運營或者內容稽核、內容安全運營都是非常重要的範疇，目前網易雲信和子彈簡訊在一起合作解決這樣的問題。網易雲信有一個專門的團隊會負責內容稽核的工作，包括會對所有的資料提取特徵，會去做同步的、實時的內容稽核，以及非同步的內容稽核，甚至涉及到機器學習的功能和人工介入稽核的工作。
從技術層面來說，關於內容稽核，目前用到產品上有兩種場景，一種是同步稽核，在訊息傳送過程中，這個訊息就可以直接進入到內容稽核系統裡進行識別，如果識別出來有敏感詞或者安全風險，會直接攔截掉。在第一時間避免訊息的傳播。還有一種內容，使用者發的視訊檔案和非常大的圖片，像這樣的內容做實時稽核會帶來比較高的時間成本，這種情況下雲信目前的做法是採用非同步稽核，訊息投遞出去了會進入稽核系統，裡面有機器演算法的部分和人工稽核的部分去進行鑑別，一旦稽核出此訊息違規，會觸發 IM 訊息撤回和刪除的能力，避免風險的二次傳播。
如何保證訊息安全性
對 IM 來說，除了使用者資料需要做安全防範外，還需要關注訊息內容的安全。包括兩個層面，一個是訊息傳輸層面的安全，在傳輸過程中，通過協議和加密，以保證傳輸過程中的訊息是不可逆的。惡意使用者即使抓到網路傳輸的包也沒有辦法破譯出來。同時，加密級別做到會話級別，是指一個使用者的一次長連結行為，即使同一個使用者多次登入，或者在不同時間點登入，加密的金鑰都是不一樣的。所以能夠保證傳輸過程中是安全的。
第二個維度是，訊息儲存過程中是安全的。這裡分為幾個角度，一是對資料做自定義的序列化的方式，包括資料儲存後，序列化或反序列化過程中的效率更高。二是如果洩露，是不可見、不可讀的。另外，對於關鍵資料需要做加密，避免出現脫庫之類的行為。
另外，周樑偉表示，使用者怎麼使用雲平臺才能在過程中保證業務資料的安全，一般他們會建議，在使用平臺的時候對業務資料做脫敏。比如說開發者自己的平臺是用使用者的手機號作為使用者賬號的，在雲信裡面註冊使用者的賬號的時候，可以在業務層做一個關聯。使用隨機數或者隨機的、無意義的字串作為雲平臺數據庫裡的 ID，手機號的對映關係僅僅在業務方。通過這種脫敏保證資料的安全。
結 語
看完上面的內容，想必你對 IM 系統研發會遇到哪些問題，以及相應的解決方案有了大致的概念。當然這裡只提到了其中的一些，還有其它方面，比如不同使用者量級的系統需要不同的架構，QQ 在它的發展過程中就經歷多次重構，感興趣的同學可以在 InfoQ 網站搜尋相關的文章。