子彈簡訊背後,億級架構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 網站搜索相關的文章。


※從小程序和蘋果的生態探究應用開發者生態五大重要標準
※你會在什麼時候學習或放棄一門編程語言?
TAG:InfoQ |