實時互動業務

---

對于傳統的頁面，點播業務，到近兩年來興起的直播，都是依賴于 CDN 網絡的單向數據傳播業務。隨著業務場景需求，實時互動正在扮演著越來越重要的場景。我們已經看到很多直播中都加入了實時互動的元素：

• 直播中最早的互動方式，直播間里觀眾通過消息，彈幕等方式刷屏和主播進行互動
• 直播連麥，兩個或多個主播進行實時互動，然后把互動內容通過 CDN 進行直播
• 抓娃娃機，通過安裝在抓娃娃機的攝像頭，讓抓娃娃設備與游戲者進行實時互動，完成游戲
• 直播答題，主播在直播過程中插入題目(配合導播完成)，觀眾進行答題，并獲取最終的獎勵
• ……

我們可以看到加入實時互動以后，直播的業務場景得到了大大的豐富。隨著技術的逐步成熟，技術門檻和網絡成本的逐步降低，人類日常的社交方式也將逐步從文字，語音開始向視頻方式轉換

本篇主要對實時互動技術做一個簡單的探討

最簡單的架構

實時互動技術總的來說主要是兩個方面：

• 消息類的實時互動
• 媒體類的實時互動，媒體類包含語音和視頻兩種

一般在用戶量比較小的時候，多數業務方都會采用 BGP 作為業務核心系統，覆蓋所有終端用戶

連麥：

聊天室：

以上架構，一般滿足小規模業務場景是沒有任何問題，如果業務規模較大，可能會出現很多問題：

BGP 機房成本太高

所有終端用戶到 BGP 機房的網絡質量可能會存在問題

單點問題，對于這個問題，可能有人會提，我可以選用幾個 BGP 機房來做，那這幾個機房是負荷分擔還是熱備關系，如果是主備，如何解決腦裂問題。到這一層面，運維的難度就會更加復雜

CDN 融合架構

其實從業務模式來說，直播和實時互動有一定的相通性：直播有主播推流的上行流程和觀眾拉流的下行流程，而實時互動對于每個參與方來說，既是主播也是觀眾

而從網絡層面上來說，分層架構可以基本解決網絡不可達問題。這種分級架構，其實并不是 CDN 特有的，在電信系統里面，分級架構是其傳輸網絡的基礎架構。其實無論是 IM 聊天室，還是會議服務，其實更多的是電信業務的模式，這里提的 CDN 融合架構，實際上是利用 CDN 天生的網絡優勢，去融合實時互動甚至是實時通信的業務

連麥

直播 CDN 會有多個匯聚核心，分別用于覆蓋不同區域，通過鏈路選優服務，每個區域的邊緣節點到匯聚核心都能保證較高的網絡質量。

選點上，將實時互動的業務服務器與直播 CDN 核心部署在一起，邊緣傳輸節點與直播 CDN 邊緣部署在一起。直播和實時互動的選優服務主要測量指標為延遲和丟包率，這點上面兩個服務是通用的，所以在調度層面上，可以進行一部分的復用

對于不同區域的實時互動參與者，會進到不同核心的業務服務器上，而這些服務器之間再做一層橋接，實現跨區域的音視頻會議

以上，通過 API Server 對主會議室進行搶占，未搶占到主會議室的核心向主會議室核心進行橋接，各會議室向 API Server 定時發送心跳，一旦主會議室出現異常，從會議室會搶占成為主會議室恢復

WS edge 是 websocket 邊緣，turn server 可以和 websocket 邊緣部署在一起，分布在 CDN 邊緣節點，保證到用戶終端的可達性。用戶終端可以通過 IP 調度或者 DNS 調度找到離自己最近的邊緣節點

一般音視頻會議參與方有人數上限，所以對于這類業務，不需要在邊緣進行匯聚，直接通過核心匯聚

當邊緣到核心連通性不好時，需要考慮加一級中轉節點，這個中轉節點可以稱作 media gateway，該網元會將用戶的 signalling 直接橋接到最近的核心，在這里也需要做一次 SDP 映射。功能可參考 IMS 中的 SBC

聊天室

對于聊天室，其實是一種大規模的消息分發，可以參考直播中主播房間中觀眾的文字互動或者彈幕消息(這里暫時不考慮必達消息的處理方式)。如果全部匯聚到一個核心服務器，這個消息量是很可觀的，核心連接數必然會影響到核心服務器的性能，這里就需要考慮多級匯聚的架構方式。

通過多級匯聚后，到核心的連接數和消息數都會大大減少

性能上的改進

對于規模較小的情況，使用 websocket 基本可以滿足要求，各種 http 架構對 websocket 的支持也較好。如果服務器連接處理成為瓶頸，則需要考慮使用 UDP 通道的方式替代 websocket

總結

以上是生活随笔為你收集整理的实时互动业务的全部內容，希望文章能夠幫你解決所遇到的問題。

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