3、聊天室整體架構(gòu)

首先，我們先來看一下網(wǎng)易云信當(dāng)前聊天室的詳細技術(shù)架構(gòu)，以及我們在架構(gòu)升級優(yōu)化過程中做的一些事情。

如下圖，是網(wǎng)易云信聊天室的技術(shù)架構(gòu)：

主要包括以下部分：

• 1）接入層的 ChatLink；

• 2）網(wǎng)絡(luò)傳輸層的 WE-CAN、WE-CAN bridge；

• 3）調(diào)度層的 Dispatcher；

• 4）服務(wù)層的 Callback、Queue、Presence、Tag、History 等；

• 5）CDN 分發(fā)層的 CDN Manager、CDN Pusher、CDN Source。

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

4、聊天室的接入層

接入層根據(jù)客戶端的類型不同會有不同的實現(xiàn)，例如常見客戶端（iOS、Andriod、Windows、Mac 等）基于私有二進制協(xié)議，Web 端基于 Websocket 協(xié)議實現(xiàn)。

接入層作為距離客戶端的最后一公里，其接入速度、質(zhì)量以及數(shù)據(jù)安全都是至關(guān)重要的，下面我們逐一討論。

1）接入速度和質(zhì)量：

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

2）數(shù)據(jù)安全：

基于對稱+非對稱加密，客戶端與服務(wù)器之前實現(xiàn) 0-RTT，完成秘鑰交換和登錄，同時也支持 RSA/AES/SM2/SM4 等各種加密算法。

接入層除了接受來自客戶端的請求，還負責(zé)進行消息的單播和廣播，因此接入層需要管理本節(jié)點的所有長連接，包括每個聊天室房間的連接以及每個連接的標(biāo)簽屬性。

此外接入層會上報自己的負載信息給后端服務(wù)，方便調(diào)度層進行合理的調(diào)度。

當(dāng)流量洪峰來臨時，因為需要進行消息的廣播，接入層往往是壓力最大的，為了保證服務(wù)的穩(wěn)定性，我們做了很多優(yōu)化策略。

3）自適應(yīng)的流控策略：

單機流控：接入層服務(wù)會監(jiān)控本機整體的網(wǎng)絡(luò)帶寬使用情況，并設(shè)置 2 個閾值 T1 和 T2，當(dāng)帶寬使用率超過 T1 時，觸發(fā)流控，如果進一步超過了 T2，則不僅觸發(fā)流控還會不斷的調(diào)整流控的強度。最終的目標(biāo)是使帶寬使用率穩(wěn)定在 T1 和 T2 之間。

單連接流控：除此之外，接入層服務(wù)還會記錄每個長連接的消息分發(fā)速度，并進行細粒度的調(diào)整，避免單機粗粒度流控導(dǎo)致單個連接分發(fā)過少或者過多，做到消息分發(fā)的平滑，即減少了帶寬流量的波動尖刺，也改善了端側(cè)的體驗。

4）性能優(yōu)化：

ChatLink 高負載運行時，除了網(wǎng)絡(luò)帶寬，調(diào)用鏈路上的各個環(huán)節(jié)都可能成為性能的瓶頸。我們通過減少編解碼的次數(shù)（包括序列化、壓縮等）、多線程并發(fā)、減少內(nèi)存拷貝、消息合并等多種方式，顯著地提升了服務(wù)性能。

5、聊天室的網(wǎng)絡(luò)傳輸層

我們的IM聊天室系統(tǒng)最初的架構(gòu)是將接入層和后端服務(wù)層都部署在同一個機房的，大部分用戶都是直連 BGP 機房的 ChatLink，對于偏遠地區(qū)或者海外，則通過專線的方式部署代理節(jié)點完成加速。

該方案存在明顯的缺點就是服務(wù)能力上限受制于單機房的容量。此外，專線也是一筆不小的開銷。

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

為了適配 WE-CAN 大網(wǎng)，我們設(shè)計了 WE-CAN Bridge 層，作為大網(wǎng)接入?yún)f(xié)議和聊天室協(xié)議的橋接層，負責(zé)協(xié)議轉(zhuǎn)換、會話管理、轉(zhuǎn)發(fā)接收。通過這種分層架構(gòu)，接入層和后端業(yè)務(wù)層可以少修改或者不修改，減少對已有系統(tǒng)的改造成本，也降低了架構(gòu)升級帶來的風(fēng)險。

什么是WE-CAN？

WE-CAN（Communications Acceleration Network）是網(wǎng)易自研的新一代大規(guī)模分布式傳輸網(wǎng)絡(luò)，WE-CAN的根本目標(biāo)是建立一個能將任意數(shù)據(jù)從全球任一點穩(wěn)定、快速、高效地發(fā)送到全球任何其他角落的通用傳輸網(wǎng)絡(luò)，且這個網(wǎng)絡(luò)是架設(shè)在公共互聯(lián)網(wǎng)之上的 —— 即無需借助任何特殊的硬件設(shè)備或架設(shè)專線，而是通過軟件方案來達到目標(biāo)。

6、聊天室的調(diào)度層

調(diào)度層是客戶端接入聊天室系統(tǒng)的前提?？蛻舳说卿浟奶焓抑靶枰全@取接入地址，分配服務(wù)我們稱之為 Dispatcher。

Dispatcher 是中心化的，會接受來自 WE-CAN 和 ChatLink 的心跳信息，根據(jù)心跳情況來選擇最佳接入點。

調(diào)度系統(tǒng)設(shè)計主要考慮的是以下兩個關(guān)鍵點。

1）調(diào)度精度：

調(diào)度系統(tǒng)會根據(jù)請求方的 IP 判斷地域和運營商信息，對比各個邊緣節(jié)點的所屬區(qū)域、運營商以及節(jié)點本身的負載（如 CPU、網(wǎng)絡(luò)帶寬等）。

此外還考慮邊緣節(jié)點到中心機房的鏈路情況（來自 WE-CAN），計算綜合打分，并把最優(yōu)的若干節(jié)點作為調(diào)度結(jié)果。

2）調(diào)度性能：

面對高并發(fā)場景，比如一個大型聊天室，活動初期往往伴隨著大量人員的同時進入，此時就需要調(diào)度系統(tǒng)做出快速的反應(yīng)。

為此，我們會將上述的調(diào)度規(guī)則以及原始數(shù)據(jù)進行本地緩存優(yōu)化。

此外，為了避免心跳信息滯后導(dǎo)致分配不合理引起節(jié)點過載，分配服務(wù)時還會動態(tài)調(diào)整負載因子，在保證調(diào)度性能的前提下，盡量做到分配結(jié)果的平滑。

7、聊天室的服務(wù)層

服務(wù)層實現(xiàn)了各種業(yè)務(wù)功能，包括：

• 1）在線狀態(tài)；

• 2）房間管理；

• 3）云端歷史；

• 4）第三回調(diào)；

• 5）聊天室隊列；

• 6）聊天室標(biāo)簽等。

其中最基礎(chǔ)的是在線狀態(tài)管理和房間管理：

• 1）在線狀態(tài)管理：管理某個賬號的登錄狀態(tài)，包括登錄了哪些聊天室、登錄在了哪些接入點等；

• 2）房間管理：管理某個聊天室房間的狀態(tài)，包括房間分布在哪些接入點，房間里有哪些成員等。

在線狀態(tài)管理和房間管理的難點在于如何有效管理海量用戶和房間。

由于 PaaS 平臺的特性，使得我們可以根據(jù)不同的租戶來進行 Region 劃分，從而做到水平擴展。

此外：由于狀態(tài)數(shù)據(jù)有快速變化的特點（短 TTL），當(dāng)某些核心用戶或者某個客戶報備了大型活動時，可以在短時間內(nèi)進行相關(guān)資源的快速拆分和隔離。

服務(wù)層除了要支持海量客戶接入、水平擴展外，還有一個很重要能力，就是需要提供各種各樣的擴展性功能來適配客戶各種應(yīng)用場景。

為此我們還提供了豐富的功能，比如：

• 1）第三方回調(diào)：方便客戶干預(yù) C 端用戶的登錄、發(fā)消息等核心環(huán)節(jié)，自定義實現(xiàn)各種業(yè)務(wù)邏輯（因為涉及到服務(wù)調(diào)用，而這個調(diào)用是跨機房甚至是跨地區(qū)的，為了避免第三方服務(wù)故障導(dǎo)致云信服務(wù)異常，我們設(shè)計了隔離、熔斷等機制來減少對關(guān)鍵流程的影響）；

• 2）聊天室隊列：可以方便用戶實現(xiàn)一些諸如麥序、搶麥等業(yè)務(wù)場景需求；

• 3）聊天室標(biāo)簽：作為特色功能，支持消息的個性化分　　發(fā)（其實現(xiàn)原理是通過客戶端登錄時設(shè)置標(biāo)簽組以及發(fā)消息時設(shè)置標(biāo)簽表達式，來定義消息分發(fā)和接收的規(guī)則。標(biāo)簽信息會同時保存在服務(wù)層以及接入層，通過將部分標(biāo)簽計算下推到接入層，節(jié)省了中心服務(wù)的帶寬和計算資源）。

8、聊天室的CDN 分發(fā)層

當(dāng)我們評價一個牛x的IM聊天室系統(tǒng)時，常用的一個詞是無上限。

架構(gòu)支持無上限不代表真的無上限。

一個IM聊天室系統(tǒng)，在邏輯上，各個組成單元都是可以水平擴展的，但是每個服務(wù)所依賴的物理機、交換機、機房帶寬等都是有容量上限的。因此，能夠合理地調(diào)配多個地域的多個機房，甚至是外部的其他資源，才能真正體現(xiàn)出一個聊天室系統(tǒng)所能支撐的容量上限。

在我們的聊天室系統(tǒng)中，用戶所有的接入點遍布各地機房，天然的將各地的資源進行了整合，所能支撐的容量上限自然高于單機房或者單地區(qū)多機房的部署模式。

進一步的：當(dāng)面臨一個更大規(guī)模的聊天室，此時如果能利用一些外部的通用能力不失為一種合適的選擇。融合 CDN 彈幕方案就是這樣一種技術(shù)實現(xiàn)方案，它可以利用各大 CDN 廠商部署在各地的邊緣節(jié)點，利用靜態(tài)加速這樣的通用能力來支持超大規(guī)模的聊天室消息分發(fā)。

基于融合 CDN 彈幕分發(fā)方案，其核心點就是彈幕的分發(fā)和管理，這是一個可選的模塊，我們內(nèi)部對此進行了封裝，可以根據(jù)不同的業(yè)務(wù)特點來選擇是否開啟而不需要修改任何業(yè)務(wù)代碼。

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

• 1）重要的且需要實時送達的消息會走長連接到達客戶端；

• 2）其他的海量消息則會進入 CDN Pusher，通過各種策略進行聚合后送達 CDN Source。

客戶端 SDK 會采取一定的策略定時從 CDN 邊緣節(jié)點獲取彈幕消息。SDK 會聚合不同來源的消息，排序后回調(diào)給用戶，App 層無需關(guān)系消息來自哪里，只需根據(jù)自己的業(yè)務(wù)需求進行處理即可。

如上圖，展示了 CDN 彈幕分發(fā)鏈路的消息流轉(zhuǎn)過程。

CDN Manager 負責(zé)：

• 1）管理不同 CDN 廠商的分配策略（登錄時會通過長連接下發(fā)，且能動態(tài)調(diào)整）

• 2）負責(zé)管理平臺上各個聊天室融合 CDN 模式的開啟和關(guān)閉；

• 3）對應(yīng)的 CDN Pusher 資源的調(diào)配和回收。

CDN Pusher 實際負責(zé)：

• 1）接收來自客戶端消息；

• 2）并根據(jù)消息的類型、消息的優(yōu)先級等，組裝成以一個一個的靜態(tài)資源，推給 CDN Source，等待 CDN 回源拉取。

9、大規(guī)模場景應(yīng)用案例

在2020年8月，網(wǎng)易云音樂 TFBoys 的 7 周年線上演唱會就是一個聊天室大規(guī)模場景應(yīng)用的典型案例。

在這場活動創(chuàng)造了 78w+ 的在線付費演唱會的世界紀(jì)錄，其彈幕互動的實現(xiàn)方式采用了我們基于融合 CDN 彈幕分發(fā)方案。

事實上：在籌備環(huán)節(jié)，我們的聊天室系統(tǒng)達成了 20 分鐘完成從 0 到 1000w 在線，上行消息 tps 達到 100w 的性能指標(biāo)。

如上圖：是支持本次活動彈幕分發(fā)的架構(gòu)圖，普通彈幕和禮物消息分別通過客戶端 SDK 以及服務(wù)器 API 到達云信服務(wù)器，并最終進入彈幕廣播服務(wù)，隨后分流到長連接和 CDN 上，再通過 pull / push 混合的方式送達客戶端。

PS：有興趣的同學(xué)可以深入閱讀關(guān)于這個案例的技術(shù)分享：《直播系統(tǒng)聊天技術(shù)(九)：千萬級實時直播彈幕的技術(shù)實踐》。

10、聊天室標(biāo)簽應(yīng)用案例

近年來，隨著互聯(lián)網(wǎng)的發(fā)展，在線教育越來越火爆，最近又興起了“超級小班課”模式。

所謂超級小班課，指的是大型多人課堂與小班互動模式結(jié)合。在線直播場景下，文字互動作為其中重要的一環(huán)，是IM聊天室的典型應(yīng)用場景。

但在超級小班課的模式下，常規(guī)的IM聊天室系統(tǒng)卻存在各種各樣的問題，不管是建立多個聊天室，還是單個聊天室進行消息過濾，都存在一些嚴(yán)重的問題。

由此我們開放了聊天室標(biāo)簽功能，完美支持了上述業(yè)務(wù)場景。

基于聊天室標(biāo)簽：可以靈活地支持聊天室消息定向收發(fā)、聊天室權(quán)限定向管理、聊天室成員定向查詢等個性化功能，真正實現(xiàn)大型直播下多場景的分組互動。

比如：

• 1）對學(xué)生進行分組標(biāo)簽后，方便進行因材施教；

• 2）分小組討論，小組間內(nèi)部討論和組間 PK 等等。

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

11、本文小結(jié)

以上，就是本文的全部分享，主要介紹了我們構(gòu)建一個大型聊天室系統(tǒng)的主要技術(shù)以及架構(gòu)原理。

任何系統(tǒng)的搭建都不是一蹴而就的，我們也會繼續(xù)打磨底層技術(shù)，就像引入 WE-CAN 來提升網(wǎng)絡(luò)傳輸效果，也會繼續(xù)豐富完善我們的功能圖譜（如獨創(chuàng)的聊天室標(biāo)簽功能等）。

12、參考資料

[1]?直播系統(tǒng)聊天技術(shù)(九)：千萬級實時直播彈幕的技術(shù)實踐

[2]?海量實時消息的視頻直播系統(tǒng)架構(gòu)演進之路(視頻+PPT)

[3]?百萬在線的美拍直播彈幕系統(tǒng)的實時推送技術(shù)實踐之路

[4]?阿里電商IM消息平臺，在群聊、直播場景下的技術(shù)實踐

[5]?微信直播聊天室單房間1500萬在線的消息架構(gòu)演進之路

[6]?百度直播的海量用戶實時消息系統(tǒng)架構(gòu)演進實踐

[7]?百萬人在線的直播間實時聊天消息分發(fā)技術(shù)實踐

[8]?直播間海量聊天消息的架構(gòu)設(shè)計難點實踐

[9]?vivo直播系統(tǒng)中IM消息模塊的架構(gòu)實踐

[10]?萬人群聊消息投遞方案的思考和實踐

[11]?IM中的萬人群聊技術(shù)方案實踐總結(jié)

（本文已同步發(fā)布于：http://www.52im.net/thread-4404-1-1.html）