企業(yè)級(jí)直播云服務(wù)的挑戰(zhàn)與架構(gòu)演進(jìn)

作者：千山 2023-12-07 14:20:05

成立于2005年的“獲得場(chǎng)景視頻”致力于面向全行業(yè)用戶提供一站式視頻解決方案，主要業(yè)務(wù)包括企業(yè)培訓(xùn)、在線教育、數(shù)字人直播等。今天在此主要是和大家分享一下我們公司的架構(gòu)是如何演進(jìn)的。

作者丨劉鈞石

編輯丨千山

本文整理自獲得場(chǎng)景視頻技術(shù)總經(jīng)理劉鈞石在WOT2023大會(huì)上的主題分享，更多精彩內(nèi)容及現(xiàn)場(chǎng)PPT，請(qǐng)關(guān)注51CTO技術(shù)棧公眾號(hào)，發(fā)消息【W(wǎng)OT2023PPT】即可直接領(lǐng)取。

日前，在51CTO主辦的WOT全球技術(shù)創(chuàng)新大會(huì)上，獲得場(chǎng)景視頻技術(shù)總經(jīng)理劉鈞石帶來(lái)了主題演講《企業(yè)級(jí)直播云服務(wù)的挑戰(zhàn)與架構(gòu)演進(jìn)》，圍繞企業(yè)級(jí)直播云服務(wù)面臨的諸多挑戰(zhàn)，詳細(xì)介紹了獲得場(chǎng)景視頻在架構(gòu)演進(jìn)中的實(shí)踐和經(jīng)驗(yàn)總結(jié)，為大眾呈現(xiàn)了全新的視角。

本文將摘選其中精彩內(nèi)容，統(tǒng)一整理，希望為諸君帶來(lái)啟發(fā)。

一、企業(yè)級(jí)直播云服務(wù)的挑戰(zhàn)

首先簡(jiǎn)述一下直播的應(yīng)用場(chǎng)景。直播往往并不單獨(dú)存在，我們做的直播通常都跟各種業(yè)務(wù)環(huán)境相結(jié)合。比如教育直播就會(huì)結(jié)合到白板、問(wèn)卷等教學(xué)工具；活動(dòng)直播就會(huì)結(jié)合到排行榜、紅包雨等營(yíng)銷(xiāo)工具；再比如賽事直播、大會(huì)直播、電商直播，數(shù)字人直播，可以說(shuō)各有各的形式和需求。

通常來(lái)說(shuō)，直播的業(yè)務(wù)流程分為推流、業(yè)務(wù)處理和拉流這三部分。推流涉及到多源輸入，手機(jī)、電腦攝像頭、VR采集設(shè)備都可以是輸入源，待這些媒體流/數(shù)據(jù)流上傳到云端后，經(jīng)過(guò)源站，由于流的協(xié)議不一樣，所以要轉(zhuǎn)碼后再分發(fā)，處理的同時(shí)將視頻存下來(lái)以便回放和進(jìn)行數(shù)據(jù)分析，最后根據(jù)不同的輸出端口進(jìn)行不同的適配處理，達(dá)成多端輸出的結(jié)果。

具體到業(yè)務(wù)場(chǎng)景時(shí)，它又要和更上層的業(yè)務(wù)系統(tǒng)去打通、對(duì)齊。

重點(diǎn)講一下在提供企業(yè)級(jí)直播云服務(wù)的過(guò)程中面臨的挑戰(zhàn)。

第一，場(chǎng)景不同，需求也不同。比如說(shuō)活動(dòng)直播要求高清晰度；賽事直播動(dòng)輒數(shù)十萬(wàn)人甚至百萬(wàn)人，因此要保證高并發(fā)；娛樂(lè)直播注重的則是高互動(dòng)性。

第二，客戶研發(fā)能力不同。不同客戶的技術(shù)能力千差萬(wàn)別。研發(fā)能力較高的企業(yè)往往只要求我們提供底層能力，比如SDK；研發(fā)能力中等或者要求不高的客戶，可能只要為他定制UI即可；另外一些研發(fā)能力還在起步階段的企業(yè)可能會(huì)傾向于讓我們提供開(kāi)箱即用的軟件。對(duì)此，我們當(dāng)然不可能逐一為其量身定制，我們的策略是分層，需要底層支持的開(kāi)放PaaS，只想做定制UI的就提供UISDK或者APaaS，想要開(kāi)箱即用一步到位的就開(kāi)放我們的SaaS產(chǎn)品。

第三，客戶痛點(diǎn)。首先在視頻這一環(huán)節(jié)，延遲肯定是最大痛點(diǎn)之一，看直播時(shí)如果出現(xiàn)延遲、卡頓等現(xiàn)象會(huì)直接影響用戶體驗(yàn)。然后不同場(chǎng)景下，更高的并發(fā)、突增的流量都可能形成挑戰(zhàn)。

二、如何提高流媒體質(zhì)量

視頻直播里的重中之重是視頻質(zhì)量。我們?cè)诳粗辈r(shí)，經(jīng)常會(huì)遇到的異常現(xiàn)象有黑流、延遲、卡頓等。不管是什么因素引起的，前提都是某段鏈路出現(xiàn)了問(wèn)題。

網(wǎng)絡(luò)一共分為三段，從推流端到邊緣節(jié)點(diǎn)，再到合流，再通過(guò)CDN分發(fā)。在每一段上最重要的是，如何選擇最合適的那一段鏈路，這就牽涉到調(diào)度問(wèn)題。對(duì)于任何一個(gè)直播系統(tǒng)來(lái)說(shuō)，優(yōu)秀的調(diào)度系統(tǒng)一定是最重要的組成部分之一。

那何時(shí)做調(diào)度呢？其實(shí)不僅僅是開(kāi)播時(shí)，從推流開(kāi)始就涉及到調(diào)度了。我們會(huì)在四個(gè)環(huán)節(jié)分別進(jìn)行調(diào)度：開(kāi)播調(diào)度、推流重試調(diào)度、播放調(diào)度、熱切調(diào)度。

如何做調(diào)度呢？一定有兩個(gè)數(shù)據(jù)來(lái)源——服務(wù)端和客戶端。通常我們主動(dòng)監(jiān)控的就是服務(wù)端數(shù)據(jù)，流量如何、帶寬如何、負(fù)載如何，將這些數(shù)據(jù)都采集起來(lái)。但是問(wèn)題在于，服務(wù)端的數(shù)據(jù)都是已經(jīng)發(fā)生的數(shù)據(jù)，因?yàn)榱鱽?lái)了，請(qǐng)求已經(jīng)到了，服務(wù)器才會(huì)發(fā)生相應(yīng)變化。那么還沒(méi)開(kāi)始推流的時(shí)候呢？想象一下，更多的人打開(kāi)客戶端，進(jìn)入直播間，推流即將開(kāi)始，請(qǐng)求即將到達(dá)。客戶端是知道這些數(shù)據(jù)的。所以我們把服務(wù)端數(shù)據(jù)和客戶端數(shù)據(jù)整合到一起，通過(guò)我們的決策模型來(lái)做調(diào)度，這樣的調(diào)度不僅僅是準(zhǔn)確，更有一定的預(yù)測(cè)性。

當(dāng)然做調(diào)度的前提是數(shù)據(jù)。我們每天最常處理的情況就是某個(gè)直播又卡了，某個(gè)節(jié)點(diǎn)負(fù)載又高了。具體情況到底如何，我們程序員通常會(huì)查看這些數(shù)據(jù)，從而了解是局部問(wèn)題還是整體問(wèn)題，以便更快地定位。

經(jīng)過(guò)實(shí)際測(cè)算，我們發(fā)現(xiàn)，沒(méi)有這些數(shù)據(jù)之前，直播故障出現(xiàn)后要定位或者解除某個(gè)問(wèn)題，都得超過(guò)30分鐘。現(xiàn)在我們可以做到3~4分鐘確定一個(gè)客訴到底是什么問(wèn)題、什么級(jí)別。我們給這個(gè)系統(tǒng)起名叫“魔鏡”，也正在把魔鏡的數(shù)據(jù)對(duì)客戶開(kāi)放，從而便于客戶自行排查。

關(guān)于故障問(wèn)題的處理，如果通過(guò)服務(wù)商的程序員進(jìn)行處理，響應(yīng)再靈敏也要經(jīng)過(guò)多級(jí)溝通。因此可以說(shuō)，問(wèn)題越能前置解決，影響就越小。本來(lái)很小的問(wèn)題經(jīng)過(guò)層層排查，可能也會(huì)因?yàn)轫憫?yīng)不及時(shí)演變?yōu)檩^大的問(wèn)題。所以問(wèn)題越提前暴露，越能處理得更好。

三、如何支持高并發(fā)

在做直播的時(shí)候如何支持高并發(fā)？并發(fā)來(lái)了，會(huì)出現(xiàn)哪些問(wèn)題？這里列舉三個(gè)比較有代表性的瓶頸點(diǎn)。

用戶登錄。大部分業(yè)務(wù)肯定都在登錄這塊或多或少出現(xiàn)過(guò)問(wèn)題。
信令帶寬。做直播或視頻時(shí)，視頻帶寬容易出現(xiàn)問(wèn)題，比如節(jié)點(diǎn)跑滿了。經(jīng)常被忽略的是信令帶寬，比如說(shuō)聊天尤其是多人刷屏?xí)r，也會(huì)占滿帶寬。
互動(dòng)數(shù)據(jù)。比如紅包雨、投票等等。

下面具體分享一下我們針對(duì)這三點(diǎn)分別做了哪些針對(duì)性措施。

1.登錄優(yōu)化

最初我們有個(gè)業(yè)務(wù)叫接口認(rèn)證，用戶想登錄我們的系統(tǒng)的時(shí)候，用戶信息都存在我們客戶的系統(tǒng)，我們通過(guò)調(diào)用客戶的服務(wù)端去獲取他的信息去認(rèn)證。

整體流程大概是：用戶從他要登錄的一個(gè)客戶的視頻列表頁(yè)，進(jìn)入我們的直播播放頁(yè)，把用戶名、密碼給到我們的服務(wù)，我們?cè)偃フ?qǐng)求服務(wù)端。

當(dāng)初設(shè)計(jì)的時(shí)候我們沒(méi)有意識(shí)到這種操作有什么問(wèn)題。后來(lái)發(fā)現(xiàn)，我們沒(méi)有辦法保證客戶的服務(wù)端是怎么樣的，我們可以做一些過(guò)載保護(hù)，但是如果很多客戶同時(shí)都在直播，這個(gè)地方就非常容易出問(wèn)題。于是我們做了一個(gè)比較簡(jiǎn)單的改造，就是我們不再去調(diào)客戶的服務(wù)，而是由客戶到我們這邊來(lái)創(chuàng)建，再通過(guò)列表頁(yè)把這個(gè)Token帶給我們，這樣就解決了這一典型問(wèn)題。

2.信令帶寬

以聊天室業(yè)務(wù)為例，我發(fā)一個(gè)聊天，這個(gè)房間里的所有人都收到。如果這個(gè)平臺(tái)上跑了一萬(wàn)個(gè)直播間，那屆時(shí)怎么處理呢？

打個(gè)比方，最開(kāi)始有20臺(tái)服務(wù)器專門(mén)建立SocketIO，所有人都連上來(lái)。作為用戶，我要把一條消息發(fā)到其中一個(gè)Socket服務(wù)器上，然后通過(guò)一個(gè)廣播，經(jīng)由Pub/sub，把這個(gè)信息同步發(fā)到另外20個(gè)服務(wù)器上。

這里的問(wèn)題在于，本身就是活動(dòng)直播，比如有一萬(wàn)個(gè)人，你又有一萬(wàn)個(gè)直播間，光這一條消息就放大了20倍，如果這個(gè)聊天室里再有人刷屏，這里的消息量堪稱恐怖。

架構(gòu)是演進(jìn)出來(lái)的，但有時(shí)也是緊急情況下催生的。2019年某個(gè)突發(fā)狀況下，我們花了三天三夜就進(jìn)行了快速調(diào)整。收獲極大但思路很簡(jiǎn)單，就是分組，按用戶、按渠道把你的資源進(jìn)行分組，找到合理的組。

3.高性能模板

用戶看直播，除了獲取直播流以外，他可能還有一些業(yè)務(wù)數(shù)據(jù)要獲取，比如說(shuō)他想看看能不能拉到歷史的聊天數(shù)據(jù)。

通常一場(chǎng)直播肯定都是先登錄直播頁(yè)，然后請(qǐng)求業(yè)務(wù)系統(tǒng)把這些歷史數(shù)據(jù)都分波拉下來(lái)。但是如果有一些直播量非常大，比如，你了解到某場(chǎng)直播在明天晚上7點(diǎn)有十萬(wàn)人同時(shí)進(jìn)，如果這些人同時(shí)請(qǐng)求你的業(yè)務(wù)系統(tǒng)，系統(tǒng)壓力一定會(huì)非常大。對(duì)此，我們可以正面解決，比如用彈性擴(kuò)容、用容器化服務(wù)。但是我們也有一種迂回的思路，就是預(yù)制這些數(shù)據(jù)。

面向這種直播，我們肯定是可以做一些降級(jí)策略的。比如拉歷史聊天數(shù)據(jù)，聊天室里那么多消息，如果少了10條、20條，其實(shí)是不影響的，而且你可以把聊天室消息通過(guò)分類(lèi)做區(qū)分，主播的消息不能丟，但是其他人的消息可以丟一點(diǎn)。最重要的是把這些數(shù)據(jù)提前都進(jìn)行處理，預(yù)制到這個(gè)頁(yè)面里面，把它靜態(tài)化。其實(shí)用戶打開(kāi)這個(gè)頁(yè)面的時(shí)候，大部分的數(shù)據(jù)都已經(jīng)在這個(gè)頁(yè)面里了，只有很少的一部分是需要去服務(wù)端請(qǐng)求。通過(guò)這種預(yù)制數(shù)據(jù)的辦法，一下就能把請(qǐng)求數(shù)據(jù)量或者請(qǐng)求接口量降到原來(lái)的10%以下。因此這對(duì)我們來(lái)說(shuō)也是很好的經(jīng)驗(yàn)。

四、如何實(shí)現(xiàn)高可用

關(guān)于如何實(shí)現(xiàn)高可用，首先分享一個(gè)很多年前的故障案例。

當(dāng)時(shí)，我們的視頻處理組做了一個(gè)非常強(qiáng)大的功能升級(jí)——極速回放。原來(lái)視頻直播結(jié)束后，視頻錄制可能需要一段時(shí)間才能生成，功能升級(jí)后，直播結(jié)束立刻就能生成回放。沒(méi)想到這一功能上線后，出現(xiàn)了直播結(jié)束一大批觀眾立刻觀看回放，引起存儲(chǔ)元數(shù)據(jù)的數(shù)據(jù)庫(kù)壓力過(guò)大。而且當(dāng)時(shí)我們還沒(méi)做拆分，回放一側(cè)出了問(wèn)題，新用戶也無(wú)法加入直播間。后續(xù)我們就做了一些解耦。

第一步，把回放和直播在服務(wù)層解耦。直播怎么樣，不能影響回放。回放怎么樣，不能影響直播，踐行了一個(gè)基本的故障隔離的思路。

第二步，把回放元數(shù)據(jù)冷熱分離。直播中，特別是部分業(yè)務(wù)數(shù)據(jù)，比如畫(huà)筆，200毫秒一條，特別大的量，之前沒(méi)過(guò)多地對(duì)這份數(shù)據(jù)做處理。后來(lái)我們做了一些冷熱的分離，保證這個(gè)庫(kù)的壓力不會(huì)太大。

第三步，回放元數(shù)據(jù)實(shí)現(xiàn)靜態(tài)化。跟之前提到的高性能模版的思路一樣，我們提前對(duì)數(shù)據(jù)進(jìn)行處理，把這些數(shù)據(jù)變成靜態(tài)化的，這樣再去請(qǐng)求頁(yè)面的時(shí)候，只請(qǐng)求這些數(shù)據(jù)，很少的一部分去請(qǐng)求數(shù)據(jù)庫(kù)。通過(guò)這樣的策略，也能大大提升我們的可用性。

另外，具體就回放來(lái)說(shuō)，回放的業(yè)務(wù)某種程度上比直播更復(fù)雜。關(guān)于回放的處理，尤其是回放的錄制，我們也做了很多工作。

原來(lái)直播跟回放在一起，我們一臺(tái)服務(wù)器既負(fù)責(zé)直播流的轉(zhuǎn)發(fā)，又負(fù)責(zé)視頻文件存在本地的責(zé)任，所以經(jīng)常會(huì)導(dǎo)致服務(wù)器IO和帶寬同時(shí)高，常常顧此失彼，導(dǎo)致利用率很低，彈性也很成問(wèn)題。因?yàn)橹辈ナ怯袪顟B(tài)的，視頻流一直推著，這個(gè)流不能切，一切就斷了，但錄制是可以的，因?yàn)槟阍谶@臺(tái)機(jī)器錄一半，在另外一臺(tái)機(jī)器再錄一半，然后把兩者拼在一起就可以了。所以我們花了不少精力打造有狀態(tài)的彈性的錄制系統(tǒng)。

此外，在直播安全方面，我們也采取了很多措施來(lái)防止盜鏈、盜播。盡管涉及到的系統(tǒng)邏輯不太一樣，但核心思路依然是把這些數(shù)據(jù)的功能拆分開(kāi)來(lái)，盡可能做到解耦，讓每一個(gè)業(yè)務(wù)流彼此獨(dú)立。

五、組件化分層架構(gòu)

關(guān)于分層架構(gòu)的內(nèi)容，我以問(wèn)卷功能為例進(jìn)行具體說(shuō)明。之前我們的直播和互動(dòng)也是在一起的，至少?gòu)臉I(yè)務(wù)邏輯上是不太區(qū)分的，簡(jiǎn)單來(lái)說(shuō)，直播推流和發(fā)起問(wèn)卷都是由一個(gè)大模塊來(lái)管理。這里就出現(xiàn)了幾個(gè)問(wèn)題。

變更風(fēng)險(xiǎn)大開(kāi)發(fā)效率低。因?yàn)殚_(kāi)發(fā)問(wèn)卷功能或者進(jìn)行問(wèn)卷邏輯優(yōu)化會(huì)影響到直播邏輯。
流量壓力。比如發(fā)紅包雨問(wèn)卷時(shí)流量通常比較集中，問(wèn)卷引發(fā)的流量可能影響直播服務(wù)。
信令帶寬。問(wèn)卷是走信令，也會(huì)造成視頻的卡頓。

這三個(gè)問(wèn)題意味著，必須將直播和互動(dòng)分開(kāi)。我們直接做了這樣的改造：把所有的問(wèn)卷服務(wù)從直播服務(wù)都拆出來(lái)，全部SDK化。如圖所示，我們把直播類(lèi)與互動(dòng)類(lèi)的信令分開(kāi)，把業(yè)務(wù)邏輯分開(kāi)，在UI層面把UI都分開(kāi)。這樣一來(lái)，不僅能解決以上痛點(diǎn)，還能大大提升開(kāi)發(fā)效率。

直播與互動(dòng)彼此獨(dú)立，這樣的話就可以建設(shè)一套開(kāi)放的、互動(dòng)的組件平臺(tái)。而且作為云服務(wù)商來(lái)講，我們不但可以自己去開(kāi)發(fā)這個(gè)組件，也可以邀請(qǐng)我們的合作伙伴或者我們的客戶自己去開(kāi)發(fā)、貢獻(xiàn)他的組件。

綜合下來(lái)，分層架構(gòu)的邏輯大致如此：最下面是IaaS層，然后是我們的支撐系統(tǒng)，支撐系統(tǒng)我們可以稱之為是PaaS層，這三層都可以對(duì)外提供。

把直播服務(wù)跟互動(dòng)服務(wù)分開(kāi)，其好處在于彼此可以獨(dú)立運(yùn)作。而且現(xiàn)在建設(shè)異地研發(fā)中心漸成趨勢(shì)，雖然視頻會(huì)議很普及，但相較面對(duì)面溝通，溝通成本依然很高。更好的方案還是讓他們彼此不影響、彼此約定好接口、約定好規(guī)范，這是最高效的。所以把互動(dòng)跟直播拆開(kāi)，是我們近幾年來(lái)最重要的變化。

如果從客戶視角來(lái)看，從最底層的IaaS提供的組件，然后到INFSDK，面向的是自身有研發(fā)能力的這些客戶，他們可以直接自定義INFSDK。如果想只是自定義UI，不自定義業(yè)務(wù)流程，可以用UISDK。想開(kāi)箱即用的這些客戶，可以直接使用SaaS應(yīng)用。

然后我們是層層依賴的，最上層SaaS應(yīng)用依賴UISDK，UISDK依賴INFSDK，整體再依賴Common-SDK。但是每一層又可以獨(dú)立地對(duì)外提供。組件化平臺(tái)，這也是我們近兩年的核心技術(shù)思路。這樣的方式就是可以對(duì)不同的類(lèi)型客戶提供支持，自己又可以不用重復(fù)地去造輪子。

簡(jiǎn)單總結(jié)一下組件化的技術(shù)價(jià)值：

代碼重用性：獨(dú)立開(kāi)發(fā)和測(cè)試，被多個(gè)產(chǎn)品復(fù)用
系統(tǒng)靈活性：通過(guò)添加、替換組件輕松實(shí)現(xiàn)系統(tǒng)功能增強(qiáng)
提升開(kāi)發(fā)團(tuán)隊(duì)的協(xié)作能力：不同團(tuán)隊(duì)同時(shí)開(kāi)發(fā)，提升效率
技術(shù)生態(tài)系統(tǒng)發(fā)展：三方組件接入，豐富組件庫(kù)

六、未來(lái)展望：數(shù)字人直播

面向未來(lái)，我們主要的思路就是擁抱AI。我覺(jué)得，現(xiàn)在無(wú)論你談不談AI，首先你必須得接受，它就是一個(gè)必然的趨勢(shì)。但是也不必那么恐慌，因?yàn)槲覀冏钪匾木褪侨绾问褂盟？傮w來(lái)說(shuō)，AI給我們直播行業(yè)也帶來(lái)了一個(gè)非常大的契機(jī)。

原來(lái)的數(shù)字人其實(shí)挺雞肋的，因?yàn)樗鼪](méi)有靈魂，它不懂你在說(shuō)什么，一點(diǎn)不好玩。但是有AI的賦能之后，除了比較常見(jiàn)的語(yǔ)義理解外，更重要的是它能生成，能主動(dòng)產(chǎn)生內(nèi)容。如何把數(shù)字人和AI結(jié)合，是我們目前的一個(gè)重點(diǎn)方向。

我們現(xiàn)在已經(jīng)上線的一個(gè)應(yīng)用是人工智能客服。當(dāng)然這個(gè)客服主要是針對(duì)教育場(chǎng)景的助理，教育場(chǎng)景通常有學(xué)員提問(wèn)，而且教育場(chǎng)景又是很?chē)?yán)肅的，不能亂說(shuō)。很多時(shí)候GPT的回答五花八門(mén)，甚至可以說(shuō)完全不著邊際。所以我們要去控制，對(duì)數(shù)據(jù)進(jìn)行定制訓(xùn)練，做更多的調(diào)優(yōu)。后面我們還會(huì)對(duì)其他場(chǎng)景做優(yōu)化，比如直播帶貨，還有一些口播的短視頻，這是我們現(xiàn)在正在測(cè)試階段的兩個(gè)產(chǎn)品。