作者丨劉鈞石

編輯丨千山

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

下面具體分享一下我們針對這三點分別做了哪些針對性措施。

1.登錄優(yōu)化

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

整體流程大概是：用戶從他要登錄的一個客戶的視頻列表頁，進(jìn)入我們的直播播放頁，把用戶名、密碼給到我們的服務(wù)，我們再去請求服務(wù)端。

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

2.信令帶寬

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

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

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

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

3.高性能模板

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

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

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

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

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

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

第一步，把回放和直播在服務(wù)層解耦。直播怎么樣，不能影響回放?；胤旁趺礃樱荒苡绊懼辈?，踐行了一個基本的故障隔離的思路。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

面向未來，我們主要的思路就是擁抱AI。我覺得，現(xiàn)在無論你談不談AI，首先你必須得接受，它就是一個必然的趨勢。但是也不必那么恐慌，因為我們最重要的就是如何使用它?？傮w來說，AI給我們直播行業(yè)也帶來了一個非常大的契機(jī)。

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

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

總體來說，我覺得我們至少是直播行業(yè)，未來一定是跟AI緊密結(jié)合的，除了能看得見的應(yīng)用，包括內(nèi)部的流程，還有一些業(yè)務(wù)的邏輯，都是可以跟AI產(chǎn)生新的火花的。