網易雲信周梁偉：聊聊無上限人數直播聊天室搭建

本文作者周梁偉，現任網易雲信IM即時通訊雲服務器端開發負責人。2011年加入網易，先後擔任網易後臺技術中心與網易大數據平臺資深開發工程師，負責即時通訊領域的產品開發。

一、直播聊天室的形式和應用場景

在一般人的理解中，直播聊天室應該就是直播畫面旁配一個聊天窗口，衆多觀看者在裏面發表自己的評論（如圖1），隨着互聯網技術的發展和消費者羣體的轉移，這種簡單的聊天室已經滿足不了廣大網民的需求。

圖1：直播聊天室形態
比如觀衆A平時就愛網紅視頻直播，進直播室就要點亮自己，發彈幕和主播對話，高興的時候要送禮，還要和其他粉絲聊天。觀衆B熱衷投資，對投資大師們的動向分析實時關注，現在大師們開直播了，不僅可以聽取知識還可以實時互動，有問題及時解答。
發展到今天，直播聊天室的展現形態已經多樣化：評論、點亮、彈幕、送禮（如圖2）。而使用直播聊天室的場景也越來越多：網紅直播、在線教育、在線金融等，使用直播聊天室也從網站端轉移到移動端，讓直播+聊天室實現了真正的全民互動，舞臺已經不屬於少數人，人人都能參與其中。

二、穩定的無上限人數直播聊天室的標準

但是事情也不總是那麼美好。以下這個畫面（圖3）是不是很熟悉，一打開直播畫面就卡住，幾萬人同時嗨翻全場，彈幕堆滿屏幕，女主播的臉卡成好幾節，有的時候甚至都進不去直播間。這樣的直播聊天室體驗是不是太差了？

圖3：彈幕卡頓
在討論聊天室之前，我們先了解下幾種常見的虛擬社羣形態。下表從參與人數、消息送達即時性、離線消息關注度等維度對論壇、IM P2P、IM羣和聊天室這幾種常見的虛擬社羣形態做了簡單對比，從這個對比可以看到聊天室是一種不同於論壇和羣模式的一種虛擬組織，聊天室的架構需要跳出傳統思維來設計。

圖4：常見虛擬社羣形態的對比
聊天室跟普通的IM羣（微信羣，QQ羣等）相比最大的不同點在於它是一個比較開放的虛擬組織。我們可以將直播聊天室比喻成一個廣場，廣場是開放無邊界的，所有的人都可以隨進隨出，而羣就像一個房間，是一個有邊界有容量上限的私密組織，並且進入這個房間需要一定條件，一般是主動申請加入或被邀請加入。聊天室對比BBS論壇這種虛擬組織來說，它既具有了IM羣消息即時送達的特性又有論壇參與人數無上限的特性。
聊天室目前比較流行的做法說都是建立在羣的架構上，但是隻要是羣就有人數和離線消息的存入上限，聊天室人數越多卡頓黑屏現象更嚴重，這裏請大家自行腦補下看電視滿屏雪花點的感受。
有人說，那跳出羣框架就好了啊，如此簡單。還真不是你想跳就能跳，有如下的難點：
客戶端多樣
數據安全需要保障
網絡抽風/單點故障
用戶量上來了，架構撐不住
消息慢
同時，我們評判一個穩定、無上限人數的聊天室架構應該具備這些條件：
跨平臺：新型的應用都是能同時跨多種設備實現消息互通的，比如網頁端，手機端和桌面端，甚至智能電視等。

數據加密：客戶端與服務器端之間的通信數據要避免泄露的風險。

高可用：任何一個節點故障都不應該引起服務不可用。

易擴展：具有水平擴展的特性，對不同量級的在線用戶數都有應變的能力。

高併發低延遲：能支持大量的用戶同時收發消息，消息從發出到送達所有在線端的延時在毫秒級。
那麼如何克服那些難點並且搭建一個符合上述條件的直播聊天室？

三、穩定的無上限人數直播聊天室，技術上如何做？

開篇闡述了直播各種應用場景以及全民互動的需求，對應的問題是：一個熱門直播間的人數可能達到幾十萬人，個人發消息幾十萬人接收，幾十萬人發消息幾十萬人接收，這個流量相當驚人，服務端要如何設計才能保證系統流暢？無上限人數和系統順暢不卡頓，這兩個條件如何在直播時同時滿足？
在設計架構時，需要分：客戶端層、網關接入層、路由層、業務層來進行分別處理。

圖5：設計架構邏輯

圖6：各分層的具體內容
1、SDK實現多平臺覆蓋，滿足客戶端多樣性：
目前的應用都存在跨平臺的需求：iOS、安卓、網頁端，甚至IOT物聯網設備，能連多少是多少，多多益善。但是不同開發平臺之間的技術差異性極大，不是所有公司都有這麼全的全棧程序猿的；如果團隊開發的話單就客戶端開發人員就不是幾個人可以完成的。
我們曾遇到過一個創業團隊，他們想自己實現TCP長連接的邏輯，iOS開發的同學沒日沒夜幹了一個禮拜，終於把第一個RPC請求調通了，結果又在數據包壓縮瘦身和加密的坑裏爬了大半個月，好不容易發了個demo版出來，結果發現移動網絡下各種掉線，最後又不斷優化弱網環境下的自動重連機制，負責安卓的同學則在邊上觀摩了一個月之後徹底放棄了，因爲他要用java重新把iOS同學的Objective-C代碼再重新實現一遍，裏面有多少坑，能不能爬出來誰也說不準。而網頁開發同學就直接懵了，因爲他根本沒法理解Web上的長連接是什麼鬼，調研半天發現只能用websocket這種方案，但是這種方案已有的服務器又根本沒法支持。
所以當你想去搭建一個無上限人數直播聊天室之前，先想想怎麼解決這個客戶端互通的問題。
因此在客戶端層要重點解決跨平臺問題。SDK需實現多平臺覆蓋，對iOS、Android、Windows和Web等開發平臺都要提供原生SDK版本，最大程度上解決開發者跨平臺需求的難題，使開發者能使用自己熟悉的開發語言和平臺快速實現產品功能。
想象一下，我們生活中在手機（iOS、Android）、平板、電腦、可穿戴設備上都能實現看直播時自由聊天以及互動，那是一件多麼美好的事情。

圖7：多平臺互通
此外對iOS和Android這種移動網絡需要進行弱網絡優化：
針對移動網絡，通過提前喚醒來降低重建連接過程中的網絡Active狀態切換、DNS解析等帶來的延時開銷，特別是針對Android等系統，通過維護後臺長連接來使手機與服務器保存連接活躍狀態，同時爲節省流量，應用在後臺時僅發送定時的心跳包來維持和檢查連接活躍；通過數據包壓縮來降低帶寬的佔用，提升請求在網絡層的傳輸速度；通過提供邊緣節點使移動客戶端總是能連接到距離最近的最優節點；通過使用CDN等來提升多媒體資源的上傳下載速度，開發者無需關心移動網絡切換時網絡斷線重連等問題，提高連接的穩定性。
現在移動直播越來越火，各類戶外直播也逐漸興起，經常會處在弱網環境中，有了弱網優化的加持，我們在看直播的時候，也會更加順暢，無需擔心看到關鍵時刻而黑屏的情況發生，同時，還能與其他粉絲一起互動聊天。
2、端到端的通信數據進行加密處理保證安全：
當前的網絡安全形勢異常複雜，開發應用時如果不在通信安全上花心思，那你的用戶就等於在互聯網上裸奔。開發者需要針對不同的平臺，不同的通信技術實現可靠的安全方案，避免用戶數據在傳輸過程中泄露。在選擇一個雲提供商時，他們應該具備哪些雲安全認證和標準？是否有匹配具體安全服務類型的認證？其實安全需求跨度非常廣，涵蓋行業甚至企業自己內部，但是確有一些共性的需求來保證雲安全認證和標準的開發。一些標準很明顯是適用的，比如C-STAR認證和ISO27001，都是國際通行的信息安全方面的認證體系。
因此在通信安全方面，對客戶端與服務器端之間的通信數據需進行加密壓縮處理，加密祕鑰的有效期控制在單次會話過程中，每次會話需要通過非對稱加密算法來協商本次會話使用的加密祕鑰，再使用此祕鑰對請求和響應包數據做流加密。一則幫用戶節省了網絡流量，提高數據傳輸效率，二則保證了通信數據的安全性，規避數據泄露或中間人攻擊等各種安全風險。
安全問題是最最重要的，誰也不希望在看直播、聊天娛樂的時候泄露太多的東西，所以加密處理是直播聊天室必須要做的，也是爲了我們能享受這個網絡虛擬環境在技術上做的努力。

圖8：數據加密
3、架構的水平擴展性應對任何用戶量級的需求
底層直播架構應該具備水平擴展的能力，當用戶量增長時隨時可以通過堆服務器來解決，而不是將架構推倒重來。
Peter剛進入團隊時跟我們分享了一個自己的故事，他和幾個小夥伴之前做了一個分享周邊美食的App，但是人手緊張啊，想着快速出成效，服務器簡單搞了幾個Tomcat，前端弄了Nginx就當高可用了，服務器和客戶端的數據通訊就用簡單的http協議實現了，開發速度是真快。iOS和安卓只要在客戶端搞個http的庫就把數據通信的事情搞完了，爲了在一個分享內容發出去之後馬上能被其他人看到，客戶端同學天真地來了一個5秒輪詢的邏輯，產品愉快地被推廣出去之後，用戶量幾百人幾千人時大家都一副很輕鬆的樣子，但當用戶量過萬的時候就發現服務器撐不住了，5秒輪詢的坑開始發威了。再然後就是競品出來了，用戶體驗被完爆，這真是個悲傷的故事。Peter淚流滿面：“架構擴展性真的好重要！”
架構必需要具備足夠的彈性，在用戶量級上來之後能支持快速的水平擴展，不會因爲架構的問題需要重構。
同時聊天室對消息的即時性要求非常高，同一條消息在投遞給不同成員時需要在毫秒級內完成，如果消息投遞慢了容易造成消息時間線錯亂，使聊天室裏的人無法理解上下文場景。
所以網關接入層面，網關接入層主要用於客戶端長連接的管理，單個節點可以維護的長連接在十萬量級。網關接入層還有一個重要功能是處理不同SDK的協議兼容問題，針對移動手機端和PC端等支持TCP長連接的SDK中實現私有通訊協議，但針對Web SDK則提供基於Socket IO的自定義協議，通過在接入服務器網關上對該協議進行雙向解析轉換來保證不同的SDK傳遞給後端業務集羣的請求響應包格式統一，比如Web端使用的WebSocket協議和iOS端使用的基於TCP的私有協議是不一樣的，這類客戶端與服務器在數據通信協議上的差異需要通過接入網關做協議轉換。另外，網關接入層還要處理數據安全邏輯和跨網絡的高可用邏輯，同時提供處於不同網絡環境的多個可用域，當單個可用域出現網絡故障時可以自動切換到備用域來保證服務不受影響。最後是廣播消息的高效下行分發，網關接入節點需要將收到的廣播消息分發到本節點上維護的客戶端。
4、備用網絡以防單點故障
任何硬件和軟件都存在故障的可能，我們無法避免應用罷工，那就需要隨時準備替補上場。
你一定聽說過“藍翔畢業生挖斷機房光纜”這樣的故事吧，也聽說過天津港爆（bao）炸（zha）引起IDC機房受損這樣的真實事件吧，當這種不可預測的天災人禍降臨的時候，如果能不影響服務的話那就更厲害了，所以現在服務提供方都在提“異地雙活”之類的高可用方案。更不用提服務器宕機之類的這種家常便飯的小故障了，所以在服務設計時都需要消除可能存在的單點。
路由層承擔了網關接入層和業務層之間解耦的功能，數據包到達接入層之後通過路由層中轉送達到正確的業務節點。同時具有負載均衡和高可用的能力，在單個業務節點處理能力達到瓶頸時能方便快速的擴容；路由層使業務層擴容對前置網關層完全透明，當一個網絡的業務集羣出現網絡故障時，可以切換到備用網絡，保證服務可用性。
5、業務節點的可替代性
從業務層上來說，聊天室功能上的業務節點主要用於處理收發聊天室消息，成員進出鑑權等具體的業務邏輯，集羣內有衆多節點，它們角色相互對等，單節點的故障可能會使集羣的業務處理能力受影響但不會引起服務的中斷，在節點故障發生時可以快速增加新的替代節點（就是新開服務器）來恢復集羣的業務處理能力，此外業務集羣有多個網絡環境的熱備（這個就是上面說的多個可用域），以應對可能出現的區域性網絡故障。
總之，以上的技術都是在爲一個穩定而安全的直播聊天室服務，沒有以上技術的加持，這一場主播和觀衆的互動聊天大戲是沒有辦法進行下去的，更別說全民參與直播、觀看直播了。