網易雲信大規模聊天室系統架構解析

前言

聊天室是一類很是重要的 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 彈幕分發鏈路的消息流轉過程: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 系統構建以及相關中間件的開發有豐富的實戰經驗。

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

相關文章
相關標籤/搜索