問題

以下內容源自oschina的一篇討論帖：

問題：這是在知乎上看到的關于如何搭建視頻直播系統時想到的一個問題，在此不考慮其他直播上的問題，僅考慮聊天系統，一個熱門視頻直播間人數可能達到幾十萬人，一個人發消息幾十萬人接收，幾十萬人發消息幾十萬人接收，這個流量相當驚人，服務端要如何設計才能保證系統流暢？

各路雷鋒的思(che)路(dan)

（點擊查看大圖）

于是，云信君看不下去了

1

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

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

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

高并發低延遲：能支持大量的用戶同時收發消息，消息從發出到送達所有在線端的延時在毫秒級；

客戶端兼容性：新型的應用都是能同時跨多種設備實現消息互通的，比如網頁端，手機端和桌面端，甚至智能電視等。

2

設計架構

（點擊查看大圖）

客戶端層

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

網關接入層

管理大量客戶端連接，單個節點可以維護的客戶端數量在數十萬量級；處理不同類型客戶端的協議兼容，由于客戶端實現技術的多樣性，導致客戶端與網關之間底層的數據通信協議存在差異，需要由不同的接入網關做協議轉換；處理數據安全邏輯；跨網絡的高可用邏輯，網絡級別的主備(誰知道哪天網線會被藍翔的畢業生挖斷呢?)；廣播消息的高效下行分發，將收到的廣播消息分發到所有連接在本節點上的客戶端。

路由層

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

業務層

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

3

難點在哪里

客戶端多樣性

目前的應用都存在跨平臺的需求，iOS、安卓和PC端，網頁端，甚至IOT物聯網設備，能連多少是多少，多多益善；但是不同開發平臺之間的技術差異性極大，不是所有公司都有這么全的全棧程序猿的；如果團隊開發的話單就客戶端開發人員就不是幾個人可以完成的。

數據安全的保證

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

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

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

所有環節的單點故障排除

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

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

架構級做到水平擴展的能力，當用戶量增長時隨時可以通過堆服務器來解決，而不是將架構推倒重來。

4

這么難？我做不出來

技術發展到現在已經不流行重復造輪子了，因為輪子的結構越來越復雜，功能性和非功能性的指標要求越來越高；而我們的用戶卻不會再等我們了。當我們還在畫輪子的圖紙的時候，競爭對手可能已經把車子都造好，在路上跑了。雖然我們不是非得自己造輪子，但是了解如何完成一個完美的輪子的制作過程和質量標準卻是非常有必要的，這也是我前面和你介紹了這么多的原因。

就像近幾年大數據技術非常流行，如果你對這個領域有所了解你就會發現幾乎所有公司都在使用現有的平臺，比如Hadoop；或者直接使用，或者在上面做二次改造，原因無非就是上面說的幾點。現在你遇到的也是同樣的問題，聊天室這種功能在最近兩年又火了起來，主要還是視頻直播業務的大規模擴張；所以能借用目前已有的平臺或工具是最快捷的路徑，應用需要關注的是怎么以最快的速度抓住用戶。

所以，最后一句就是硬得不能再硬的廣告了：“試試網易云信吧，我們已經把輪子造好了，而且造得還不錯！”

END

【推薦閱讀】

視頻云直播：場景、技術及優化

Po校園接入云信，多機位“有毒”直播燃爆LIVE

網易云信∣直播+聊天室一鍵打造

ID：neteaseim ?長按識別，關注精彩

總結

以上是生活随笔為你收集整理的十几万人同时在线的直播间聊天，如何设计服务端架构？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。