【51CTO.com原創(chuàng)稿件】由于直播平臺(tái)的特點(diǎn)，對(duì)系統(tǒng)功能設(shè)計(jì)的可靠性要求更高，同時(shí)，如何在直播火熱的當(dāng)下快速實(shí)現(xiàn)直播平臺(tái)的構(gòu)建，成為很多企業(yè)的現(xiàn)實(shí)需求。本文主要分享融云直播互動(dòng)系統(tǒng)的設(shè)計(jì)與實(shí)踐，詳細(xì)介紹禮物、紅包等以消息為基礎(chǔ)的互動(dòng)方案設(shè)計(jì)思路和實(shí)踐方案并闡述如何結(jié)合融云自身技術(shù)優(yōu)勢(shì)，助力直播企業(yè)快速布局市場(chǎng)。

直播互動(dòng)平臺(tái)的特點(diǎn)

融云于 2014 年成立時(shí)，國(guó)內(nèi)直播平臺(tái)還未大批興起，當(dāng)時(shí)我們只提供聊天室服務(wù)。2015 年，源于大量客戶對(duì)直播互動(dòng)的需求，融云預(yù)見(jiàn)直播平臺(tái)未來(lái)會(huì)有很好的前景，于是開(kāi)始與客戶積極交流來(lái)挖掘需求，最終我們將聊天室轉(zhuǎn)變?yōu)橹辈セ?dòng)平臺(tái)。經(jīng)歷了 2016 年一個(gè)完整的直播元年，直播互動(dòng)系統(tǒng)也正式步入了成熟期。

目前，融云主要做實(shí)時(shí)通信云平臺(tái)，就是所謂的 IM 云，提供包含單聊、群聊、客服、推送、公眾賬號(hào)、直播平臺(tái)等云服務(wù)。得益于 2016 年直播市場(chǎng)的異常火熱，平臺(tái)每天可達(dá)到對(duì)外產(chǎn)生 2200 億條消息，峰值每小時(shí) 450 億，每秒高達(dá)千萬(wàn)的分發(fā)。

直播互動(dòng)平臺(tái)的特點(diǎn)是什么呢?我們做視頻直播的時(shí)候，可能有用戶需要跟主播以及其他用戶發(fā)一些文字消息、點(diǎn)贊消息等等進(jìn)行互動(dòng)，由于這些消息的存在，把以前單純的只是受眾于視頻的應(yīng)用這種視頻直播，變成了可以進(jìn)行互動(dòng)的平臺(tái)。

用戶在平臺(tái)發(fā)消息進(jìn)行互動(dòng)，這個(gè)互動(dòng)場(chǎng)景和聊天室類似，就是用戶加入聊天室，可收到別人的消息，同時(shí)也可發(fā)送消息，用戶下線時(shí)消息不再進(jìn)行推送，這個(gè)場(chǎng)景實(shí)際上可以滿足簡(jiǎn)單的直播互動(dòng)。

相較其他 IM 來(lái)講，沒(méi)有離線消息存儲(chǔ)，也沒(méi)有離線消息 Push，在業(yè)務(wù)形態(tài)來(lái)講，聊天室比較簡(jiǎn)單一些。

如下是直播互動(dòng)平臺(tái)的主要特性：

• 直播互動(dòng)平臺(tái)的用戶量實(shí)際是無(wú)上限的，因?yàn)椴豢赡苋ハ拗埔粋€(gè)主播加入觀眾的成員數(shù)量。
• 通過(guò)把消息進(jìn)行分級(jí)控制的方式來(lái)保證禮物、紅包等消息傳輸?shù)目煽啃浴?/li>
• 瞬時(shí)消息吞吐量大，融云某個(gè)聊天室曾經(jīng)一秒鐘產(chǎn)生過(guò)近千萬(wàn)的消息。
• 針對(duì)伸縮及穩(wěn)定性方面的高要求。

消息平臺(tái)的邏輯設(shè)計(jì)及設(shè)計(jì)原理

消息是直播互動(dòng)系統(tǒng)最重要的元素，消息處理做的好不好會(huì)直接影響用戶的體驗(yàn)。融云的消息平臺(tái)邏輯設(shè)計(jì)是怎樣的呢?

如上圖，我用一張時(shí)序圖針對(duì)這個(gè)問(wèn)題進(jìn)行了解答。A 客戶端是發(fā)消息方，服務(wù)端是融云整個(gè)后端平臺(tái)，B 客戶端是接收消息方。

首先，客戶端向服務(wù)端發(fā)送消息，服務(wù)端接收消息先進(jìn)行消息驗(yàn)證，消息驗(yàn)證里面包含了高危詞、敏感詞的過(guò)濾，反垃圾系統(tǒng)對(duì)消息進(jìn)行反垃圾的過(guò)濾及權(quán)限驗(yàn)證。

當(dāng)消息通過(guò)之后，對(duì)消息優(yōu)先進(jìn)行存儲(chǔ)，之后會(huì)給 A 客戶端返回應(yīng)答，告知消息已經(jīng)發(fā)送成功，這時(shí)服務(wù)端會(huì)遍歷成員分發(fā)通知。

值得注意的是，現(xiàn)在還沒(méi)有向客戶端發(fā)送消息實(shí)體，當(dāng)接收客戶端接收消息通知時(shí)，會(huì)從自己本地存儲(chǔ)里面拿到當(dāng)前直播間里面最新的消息版本號(hào)。

同時(shí)向服務(wù)器發(fā)起同步請(qǐng)求，服務(wù)器獲取客戶提交的版本號(hào)之后，會(huì)以這個(gè)版本號(hào)為起點(diǎn)，到最新版本號(hào)把所有消息全部拿回來(lái)返回給客戶端，客戶端收到這個(gè)消息進(jìn)行消息展示以及存儲(chǔ)這個(gè)最新版本號(hào)。

整個(gè)通信流程，版本號(hào)獲取方式，跟常用版本控制軟件比較類似。之所以把流程變得這么復(fù)雜，在發(fā)送完通知之后再同步消息，主要原因如下：

• 通知的推送重試可以依賴 TCP 的重試，無(wú)須邏輯保障。
• 服務(wù)器端存儲(chǔ)的消息順序與到達(dá)的客戶端順序一致。
• 當(dāng)消息密集時(shí)可以將多條消息進(jìn)行合并。
• 可以控制下發(fā)的消息條數(shù)。
• 以存儲(chǔ)分級(jí)實(shí)現(xiàn)消息分級(jí)。
• 不以消息數(shù)量衡量服務(wù)器規(guī)模，以在線用戶數(shù)量做為考量。

消息平臺(tái)在服務(wù)端實(shí)現(xiàn)細(xì)節(jié)及最佳應(yīng)用實(shí)踐

直播消息系統(tǒng)在服務(wù)端的實(shí)現(xiàn)細(xì)節(jié)，主要從數(shù)據(jù)預(yù)處理、消息分級(jí)、消息存儲(chǔ)和消息分發(fā)隊(duì)列四方面進(jìn)行介紹，但在實(shí)際服務(wù)開(kāi)發(fā)過(guò)程中，還有很多優(yōu)化。

數(shù)據(jù)預(yù)處理

當(dāng)服務(wù)端接收消息之后，優(yōu)先對(duì)數(shù)據(jù)進(jìn)行序列化以及存儲(chǔ)，序列化消息和要下發(fā)的客戶端數(shù)據(jù)要保持一致，通過(guò)這種預(yù)處理的方式，CPU 的使用率在當(dāng)前基礎(chǔ)上降低了 30%。

消息分級(jí)存儲(chǔ)

根據(jù)消息類型按照中、高、低序列進(jìn)行分級(jí)存儲(chǔ)。

Skiplist 轉(zhuǎn)化為環(huán)形隊(duì)列存儲(chǔ)

每條消息有唯一且遞增版本號(hào)，消息按照版本號(hào)順序存儲(chǔ)。這樣的數(shù)據(jù)在內(nèi)存存儲(chǔ)情況下，跳表是一種非常合適的數(shù)據(jù)結(jié)構(gòu)。

但是，跳表時(shí)間復(fù)雜度和空間復(fù)雜度比較大，同時(shí)往跳表中插入數(shù)據(jù)時(shí)使用的鎖范圍非常大，會(huì)對(duì)服務(wù)器產(chǎn)生一些額外的開(kāi)銷。之后，由跳表演進(jìn)成一種類似環(huán)形隊(duì)列的數(shù)據(jù)結(jié)構(gòu)，會(huì)對(duì)服務(wù)器性能開(kāi)銷提升很多。

Map 與隊(duì)列構(gòu)建復(fù)合數(shù)據(jù)結(jié)構(gòu)，降低無(wú)意義消費(fèi)

服務(wù)端下發(fā)通知，對(duì)于通知來(lái)講在這一時(shí)刻無(wú)論有多少條消息，每個(gè)用戶只有一條通知，通過(guò) Map 與隊(duì)列構(gòu)建這樣的復(fù)合結(jié)構(gòu)進(jìn)行存儲(chǔ)。

隊(duì)列里面存儲(chǔ)是數(shù)據(jù)的指針，Map 存儲(chǔ)用于下發(fā)的通知實(shí)體，Map 使用的 key 為用戶標(biāo)識(shí)，這樣可以降低無(wú)意義的消費(fèi)。

融云線上直播互動(dòng)平臺(tái)的整體架構(gòu)

直播互動(dòng)平臺(tái)的 2.1 架構(gòu)

如上圖，是融云線上 2.1 架構(gòu)圖，可分為連接層、業(yè)務(wù)層和存儲(chǔ)層等，連接層和業(yè)務(wù)層構(gòu)建成整個(gè)大的集群，然后進(jìn)行服務(wù)。

連接層主要是負(fù)責(zé)客戶端與服務(wù)器保持長(zhǎng)連接，同時(shí)將客戶端的協(xié)議與內(nèi)部服務(wù)的協(xié)議進(jìn)行相互轉(zhuǎn)化。

業(yè)務(wù)層負(fù)責(zé) IM 相關(guān)業(yè)務(wù)處理，采用的是微服務(wù)架構(gòu)，線上服務(wù)有 40 多個(gè)類型，但對(duì)于直播互動(dòng)平臺(tái)包含如下三項(xiàng)服務(wù)：

• 上行控制服務(wù)。主要目的是用于處理接收的上行客戶端的消息，進(jìn)行敏感詞和高危詞的過(guò)濾。這個(gè)服務(wù)的負(fù)載方式采用的是隨機(jī)分配。
• 直播服務(wù)。負(fù)責(zé)維護(hù)直播間的成員關(guān)系和負(fù)責(zé)接收上行控制服務(wù)給它的消息，上行控制服務(wù)會(huì)先期進(jìn)行消息拋棄，拋棄到直播服務(wù)可以接收的范圍之內(nèi)，然后將消息下發(fā)到直播服務(wù)，直播服務(wù)再?gòu)V播到直播消息服務(wù)。
• 直播消息服務(wù)。負(fù)責(zé)給用戶進(jìn)行分發(fā)通知，是以用戶 ID 進(jìn)行一致的哈希方式進(jìn)行負(fù)載。每個(gè)服務(wù)節(jié)點(diǎn)包含部分用戶關(guān)系。

整個(gè)直播消息服務(wù)構(gòu)建了一個(gè)整體成員關(guān)系，等同于直播消息服務(wù)上的一個(gè)節(jié)點(diǎn)。這層除分發(fā)通知外，還負(fù)責(zé)客戶端同步拉取獲取的消息。

存儲(chǔ)層主要職責(zé)是用來(lái)存儲(chǔ)各種消息，數(shù)據(jù)等，含多個(gè)數(shù)據(jù)庫(kù)。

線上 2.1 架構(gòu)和之前的架構(gòu)相比，降低了直播服務(wù)壓力和上行總量的控制，但面臨的問(wèn)題是需要更高的網(wǎng)絡(luò)質(zhì)量要求。

直播互動(dòng)平臺(tái)的網(wǎng)絡(luò)優(yōu)化

如下圖，是鏈路架構(gòu) 1.0：

鏈路架構(gòu) 1.0，線上進(jìn)行網(wǎng)絡(luò)加速主要是加速海外業(yè)務(wù)。融云選購(gòu)了第三方海外專線鏈路，涉及全球五個(gè)國(guó)家，覆蓋歐洲、美洲以及中東、日本等等。

實(shí)現(xiàn)國(guó)際鏈路優(yōu)化，就近區(qū)域接入的同時(shí)，又出現(xiàn)專線的流量過(guò)大，成本過(guò)高，跨國(guó)消息延時(shí)等問(wèn)題。

如下圖，是鏈路架構(gòu) 2.0：

鏈路架構(gòu) 2.0 采用模擬 CDN 模式進(jìn)行數(shù)據(jù)分發(fā)，專線內(nèi)只跑上行消息和廣播消息的方式。

融云提供的是直播互動(dòng)平臺(tái)，是一個(gè)基礎(chǔ)的 PAAS 服務(wù)，本身并不會(huì)去做直接面對(duì)用戶的直播 APP。未來(lái)，它也會(huì)不停地向前探索，如降低專線的依賴，數(shù)據(jù)中心進(jìn)行鏈路選擇等。

以上內(nèi)容根據(jù)李淼老師在 WOTA2017 “高性能直播系統(tǒng)架構(gòu)”專場(chǎng)的演講內(nèi)容整理。

[[201062]]

負(fù)責(zé)融云后端服務(wù)平臺(tái)的設(shè)計(jì)和架構(gòu)工作，2007-2013 年就職于移動(dòng)飛信團(tuán)隊(duì)，歷任高級(jí)技術(shù)經(jīng)理，架構(gòu)師，一直關(guān)注大規(guī)模高并發(fā)系統(tǒng)設(shè)計(jì)和研究。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】