前言

聊天室是一類非常重要的 IM 系統，不同於單聊和群聊，聊天室是一種大規模的實時訊息分發系統。

聊天室有多種技術實現方案，業界也有一些開源的實現，每種實現都有自己的特點和應用場景。網易雲信作為 PaaS 平臺，其聊天室的系統架構和方案有幾個突出的特點：

• 水平擴充套件能力：主要體現在兩方面，一個是聊天室數量，一個是單個聊天室的人數。
• 功能豐富：作為一個平臺，聊天室提供底層通訊能力，提供了豐富的功能集，來適配各種各樣的業務場景，使用方可以根據自己的業務要求按需使用。
• 支援全球化：雲信目前提供了覆蓋全球的通訊網路，通過接入雲信自研的 WE-CAN 大網，全球範圍內延遲不超過 250ms。

本文我們來詳細介紹一下網易雲信大規模聊天室系統的具體架構以及實踐應用案例。

網易雲信聊天室系統架構

首先，我們先來看一下網易雲信當前聊天室的詳細技術架構，以及我們在架構升級優化過程中做的一些事情。

整體架構圖

如下圖，是網易雲信聊天室的技術架構：

主要包括以下部分：

• 接入層的 ChatLink
• 網路傳輸層的 WE-CAN、WE-CAN bridge
• 排程層的 Dispatcher
• 服務層的 Callback、Queue、Presence、Tag、History 等
• CDN 分發層的 CDN Manager、CDN Pusher、CDN Source

下面，我們針對每一層展開詳細分析。

接入層

接入層根據客戶端的型別不同會有不同的實現，例如常見客戶端（iOS、Andriod、Windows、Mac 等）基於私有二進位制協議，Web 端基於 Websocket 協議實現。接入層作為距離客戶端的最後一公里，其接入速度、質量以及資料安全都是至關重要的：

接入速度和質量

目前我們搭建了覆蓋全國各省份以及全世界各大洲的邊緣節點，縮短最後一公里，減少不確定性，提升服務的穩定性。

資料安全

基於對稱+非對稱加密，客戶端與伺服器之前實現 0-RTT，完成祕鑰交換和登入，同時也支援 RSA/AES/SM2/SM4 等各種加密演算法。

接入層除了接受來自客戶端的請求，還負責進行訊息的單播和廣播，因此接入層需要管理本節點的所有長連線，包括每個聊天室房間的連線以及每個連線的標籤屬性。此外接入層會上報自己的負載資訊給後端服務，方便排程層進行合理的排程。

當流量洪峰來臨時，因為需要進行訊息的廣播，接入層往往是壓力最大的，為了保證服務的穩定性，我們做了很多優化策略：

自適應的流控策略

• 單機流控：接入層服務會監控本機整體的網路頻寬使用情況，並設定 2 個閾值 T1 和 T2，當頻寬使用率超過 T1 時，觸發流控，如果進一步超過了 T2，則不僅觸發流控還會不斷的調整流控的強度。最終的目標是使頻寬使用率穩定在 T1 和 T2 之間。
• 單連線流控：除此之外，接入層服務還會記錄每個長連線的訊息分發速度，並進行細粒度的調整，避免單機粗粒度流控導致單個連線分發過少或者過多，做到訊息分發的平滑，即減少了頻寬流量的波動尖刺，也改善了端側的體驗。

效能優化

ChatLink 高負載執行時，除了網路頻寬，呼叫鏈路上的各個環節都可能成為效能的瓶頸。我們通過減少編解碼的次數（包括序列化、壓縮等）、多執行緒併發、減少記憶體拷貝、訊息合併等多種方式，顯著地提升了服務效能。

網路傳輸層

網易雲信聊天室系統最初的架構是將接入層和後端服務層部署在同一個機房的，大部分使用者都是直連 BGP 機房的 ChatLink，對於偏遠地區或者海外，則通過專線的方式部署代理節點完成加速。該方案存在明顯的缺點就是服務能力上限受制於單機房的容量，此外，專線也是一筆不小的開銷。

在我們接入 WE-CAN 大網後，接入層 ChatLink 可以做到客戶端就近接入，提高服務質量的同時降低了成本。此外，多機房的架構也使得我們的服務能力上升了一個臺階。

為了適配 WE-CAN 大網，我們設計了 WE-CAN Bridge 層，作為大網接入協議和聊天室協議的橋接層，負責協議轉換、會話管理、轉發接收。通過這種分層架構，接入層和後端業務層可以少修改或者不修改，減少對已有系統的改造成本，也降低了架構升級帶來的風險。

排程層

排程層是客戶端接入聊天室系統的前提。客戶端登入聊天室之前需要先獲取接入地址，分配服務我們稱之為 Dispatcher。

Dispatcher 是中心化的，會接受來自 WE-CAN 和 ChatLink 的心跳資訊，根據心跳情況來選擇最佳接入點，排程系統設計主要考慮的幾個關鍵點是：

排程精度

排程系統會根據請求方的 IP 判斷地域和運營商資訊，對比各個邊緣節點的所屬區域、運營商以及節點本身的負載（如 CPU、網路頻寬等），此外還考慮邊緣節點到中心機房的鏈路情況（來自 WE-CAN），計算綜合打分，並把最優的若干節點作為排程結果。

排程效能

面對高併發場景，比如一個大型聊天室，活動初期往往伴隨著大量人員的同時進入，此時就需要排程系統做出快速的反應。為此，我們會將上述的排程規則以及原始資料進行本地快取優化，此外，為了避免心跳資訊滯後導致分配不合理引起節點過載，分配服務時還會動態調整負載因子，在保證排程效能的前提下，儘量做到分配結果的平滑。

服務層

服務層實現了各種業務功能，包括：線上狀態、房間管理、雲端歷史、第三回調、聊天室佇列、聊天室標籤等。其中最基礎的是線上狀態管理和房間管理：

• 線上狀態管理：管理某個賬號的登入狀態，包括登入了哪些聊天室、登入在了哪些接入點等
• 房間管理：管理某個聊天室房間的狀態，包括房間分佈在哪些接入點，房間裡有哪些成員等

線上狀態管理和房間管理的難點在於如何有效管理海量使用者和房間。網易雲信 PaaS 平臺的特性，使得我們可以根據不同的租戶來進行 Region 劃分，從而做到水平擴充套件。此外，由於狀態資料有快速變化的特點（短 TTL），當某些核心使用者或者某個客戶報備了大型活動時，雲信可以在短時間內進行相關資源的快速拆分和隔離。

服務層除了要支援海量客戶接入、水平擴充套件外，還有一個很重要能力，就是需要提供各種各樣的擴充套件性功能來適配客戶各種應用場景。為此雲信提供了各種各樣豐富的功能，比如：

• 第三方回撥：方便客戶干預 C 端使用者的登入、發訊息等核心環節，自定義實現各種業務邏輯。因為涉及到服務呼叫，而這個呼叫是跨機房甚至是跨地區的，為了避免第三方服務故障導致雲信服務異常，我們設計了隔離、熔斷等機制來減少對關鍵流程的影響；
• 聊天室佇列：可以方便使用者實現一些諸如麥序、搶麥等業務場景需求；
• 聊天室標籤：作為雲信業內首創的特色功能，支援訊息的個性化分發。其實現原理是通過客戶端登入時設定標籤組以及發訊息時設定標籤表示式，來定義訊息分發和接收的規則。標籤資訊會同時儲存在服務層以及接入層，通過將部分標籤計算下推到接入層，節省了中心服務的頻寬和計算資源。

CDN 分發層

當我們評價一個聊天室系統時，常用的一個詞是無上限。架構支援無上限不代表真的無上限。一個聊天室系統，在邏輯上，各個組成單元都是可以水平擴充套件的，但是每個服務所依賴的物理機、交換機、機房頻寬等都是有容量上限的。因此，能夠合理地調配多個地域的多個機房，甚至是外部的其他資源，才能真正體現出一個聊天室系統所能支撐的容量上限。

在網易雲信的聊天室系統中，使用者所有的接入點遍佈各地機房，天然的將各地的資源進行了整合，所能支撐的容量上限自然高於單機房或者單地區多機房的部署模式。

進一步的，當面臨一個更大規模的聊天室，此時如果能利用一些外部的通用能力不失為一種合適的選擇。融合 CDN 彈幕方案就是這樣一種技術實現方案，它可以利用各大 CDN 廠商部署在各地的邊緣節點，利用靜態加速這樣的通用能力來支援超大規模的聊天室訊息分發。

基於融合 CDN 彈幕分發方案，其核心點就是彈幕的分發和管理，這是一個可選的模組，雲信內部對此進行了封裝，可以根據不同的業務特點來選擇是否開啟而不需要修改任何業務程式碼。

在開啟融合 CDN 彈幕分發方案的情況下，所有的彈幕廣播會劃分成 兩條鏈路：

• 重要的且需要實時送達的訊息會走長連線到達客戶端
• 其他的海量訊息則會進入 CDN Pusher，通過各種策略進行聚合後送達 CDN Source

客戶端 SDK 會採取一定的策略定時從 CDN 邊緣節點獲取彈幕訊息。SDK 會聚合不同來源的訊息，排序後回撥給使用者，App 層無需關係訊息來自哪裡，只需根據自己的業務需求進行處理即可。

如上圖，展示了 CDN 彈幕分發鏈路的訊息流轉過程：CDN Manager 負責管理不同 CDN 廠商的分配策略（登入時會通過長連線下發，且能動態調整）。此外，還負責管理平臺上各個聊天室融合 CDN 模式的開啟和關閉，以及對應的 CDN Pusher 資源的調配和回收。CDN Pusher 實際負責接收來自客戶端訊息，並根據訊息的型別、訊息的優先順序等，組裝成以一個一個的靜態資源，推給 CDN Source，等待 CDN 回源拉取。

落地實踐案例

下面，我們介紹應用了網易雲信聊天室系統的典型應用場景。

大規模場景應用案例

在2020年8月，網易雲音樂 TFBoys 的 7 週年線上演唱會就是一個聊天室大規模場景應用的典型案例。在這場活動創造了 78w+ 的線上付費演唱會的世界紀錄，其彈幕互動的實現方式採用了網易雲信基於融合 CDN 彈幕分發方案。事實上，在籌備環節，我們的聊天室系統達成了 20 分鐘完成從 0 到 1000w 線上，上行訊息 tps 達到 100w 的效能指標。

如上圖，是支援本次活動彈幕分發的架構圖，普通彈幕和禮物訊息分別通過客戶端 SDK 以及伺服器 API 到達雲信伺服器，並最終進入彈幕廣播服務，隨後分流到長連線和 CDN 上，再通過 pull / push 混合的方式送達客戶端。

特色功能 - 聊天室標籤應用案例

近年來，隨著網際網路的發展，線上教育越來越火爆，最近又興起了“超級小班課”模式。所謂超級小班課，指的是大型多人課堂與小班互動模式結合。

線上直播場景下，文字互動作為其中重要的一環，是聊天室的典型應用場景。但在超級小班課的模式下，常規的聊天室系統卻存在各種各樣的問題，不管是建立多個聊天室，還是單個聊天室進行訊息過濾，都存在一些嚴重的問題。

網易雲信首創的聊天室標籤功能，完美支援了上述業務場景，基於聊天室標籤，我們可以靈活地支援聊天室訊息定向收發、聊天室許可權定向管理、聊天室成員定向查詢等個性化功能，真正實現大型直播下多場景的分組互動，比如對學生進行分組標籤後，方便進行因材施教；分小組討論，小組間內部討論和組間 PK 等等。

如上圖，展示了超級小班課的一個場景：1 個主講教師+ N 個互動小班+ N 個助教，所有學生被劃分成了一個一個的小班，由對應的助教完成預習提醒、課後答疑、作業監督、學員學習情況反饋等工作，同時又接收來自主講老師的直播畫面，做到了大課的規模，小課的效果。

總結

以上，就是本文的全部分享，主要介紹了網易雲信構建一個大型聊天室系統的主要技術以及架構原理。任何系統的搭建都不是一蹴而就的，雲信也會繼續打磨底層技術，就像引入 WE-CAN 來提升網路傳輸效果，也會繼續豐富完善我們的功能圖譜，如業內首創的聊天室標籤功能等。網易雲信將持續在 IM 領域深耕，為各種場景和行業的使用者提供最優質的服務。

作者介紹

曹佳俊，網易雲信資深服務端開發工程師，中科院研究生畢業後加入網易，一直在網易雲信負責 IM 伺服器相關的開發工作。對 IM 系統構建以及相關中介軟體的開發有豐富的實戰經驗。

更多技術乾貨，歡迎關注【網易智企技術+】微信公眾號