幾十萬人同時在線的直播間聊天，如何設計服務端架構？

一個熱門視頻直播間人數可能達到幾十萬甚至上百萬人，幾十萬人發消息，幾十萬人接收，流量至關驚人，那麼服務端要如何設計才能保證系統流暢？本文做者將結合他在網易雲信多年IM開發的經驗進行深度分析。

推薦閱讀

• 高併發 IM 系統架構優化實踐
• IM 即時通信：如何跳出傳統思惟來設計聊天室架構？

聊天室架構應知足哪些條件

• 高可用：任何一個節點故障都不該該引發服務不可用；
• 易擴展：具備水平擴展的特性，對不一樣量級的在線用戶數都有應變的能力；
• 高併發低延遲：能支持大量的用戶同時收發消息，消息從發出到送達全部在線端的延時在毫秒級；
• 客戶端兼容性：新型的應用都是能同時跨多種設備實現消息互通的，好比網頁端，手機端和桌面端，甚至智能電視等。

聊天室架構如何設計

• 客戶端層

處理各類設備的兼容問題，包括對 iOS, Android, Windows, Web 等各類開發平臺的語言適配；消息通道的管理維護，包括移動設備上的弱網絡管理，斷線重連等；保證數據安全，全部上行下行的數據包都須要加解密處理，規避數據泄露或中間人攻擊等各類安全風險。

• 網關接入層

管理大量客戶端鏈接，單個節點能夠維護的客戶端數量在數十萬量級；處理不一樣類型客戶端的協議兼容，因爲客戶端實現技術的多樣性，致使客戶端與網關之間底層的數據通訊協議存在差別，須要由不一樣的接入網關作協議轉換；處理數據安全邏輯；跨網絡的高可用邏輯，網絡級別的主備（誰知道哪天網線會被藍翔的畢業生挖斷呢？）；廣播消息的高效下行分發，將收到的廣播消息分發到全部鏈接在本節點上的客戶端。

• 路由層

做爲業務層接入的中轉，同時承擔負載均衡和高可用的做用，單個業務節點處理能力達到瓶頸時更方便的擴容，路由層使業務層擴容對前置網關層徹底透明；當一個網絡的業務集羣出現網絡故障時，能夠切換到備用網絡，保證服務可用性。

• 業務層

處理聊天室內的業務消息，一個集羣內有衆多節點，節點角色相互對等，任何一個節點的故障會使整個集羣的處理能力降低，但不會引發服務的中斷，由於其餘節點能夠繼續接管業務數據包的處理；業務集羣一樣有多個網絡環境的熱備，以應對可能出現的區域性網絡故障。

難點在哪裏

• 客戶端多樣性

目前的應用都存在跨平臺的需求，iOS、安卓和 PC 端，網頁端，甚至 IoT 物聯網設備，能連多少是多少，多多益善；可是不一樣開發平臺之間的技術差別性極大，不是全部公司都有這麼全的全棧程序猿的；若是團隊開發的話單就客戶端開發人員就不是幾我的能夠完成的。

• 數據安全的保證

當前的網絡安全形勢異常複雜，開發應用時若是不在通訊安全上花心思，那你的用戶就是在互聯網上裸奔；開發者須要針對不一樣的平臺，不一樣的通訊技術實現可靠的安全方案，避免用戶數據在傳輸過程當中泄露，避免中間人攻擊等安全風險。

• 跨機房網絡級的高可用方案

當機房網絡出現故障時把責任推給市政施工隊或者「網絡抽風」已經不流行了，用戶須要的是故障無感知。

• 全部環節的單點故障排除

任何硬件和軟件都存在故障的可能，咱們沒法避免應用罷工，那就須要隨時準備替補上場。

• 能應對任何用戶量級的需求

架構級作到水平擴展的能力，當用戶量增加時隨時能夠經過堆服務器來解決，而不是將架構推倒重來。

看完文章仍是不知道怎麼作？那麼能夠嘗試借用目前已有的平臺或工具，如今應用須要關注的是怎麼以最快的速度抓住用戶。網易雲信是一個面對開發者的很好的 IM 雲平臺。十餘年的研發積累，使其在即時通信技術方面處於全國領先水平。網易雲信至今已申請了 60 餘項 IM 專利，遠超市場同類產品。歡迎你們與咱們討論 IM 技術，也歡迎你們多多關注網易雲信。

---

隨着即時通信以及音頻處理和壓縮技術的不斷髮展，效果更好、適用範圍更廣、性能更高的算法和新的技術必將不斷涌現，若是你有好的技術或者分享，歡迎關注網易雲信官方博客和 GitHub：

關注更多技術乾貨內容： 網易雲信博客
歡迎關注 網易雲信 GitHub
歡迎關注 網易雲信官網