作者丨劉鈞石
編輯丨千山
本文整理自獲得場景視頻技術總經理劉鈞石在WOT2023大會上的主題分享，更多精彩內容及現場PPT，請關注51CTO技術棧公眾號，發消息【WOT2023PPT】即可直接領取。
日前，在51CTO主辦的WOT全球技術創新大會上，獲得場景視頻技術總經理劉鈞石帶來了主題演講《企業級直播云服務的挑戰與架構演進》，圍繞企業級直播云服務面臨的諸多挑戰，詳細介紹了獲得場景視頻在架構演進中的實踐和經驗總結，為大眾呈現了全新的視角。
本文將摘選其中精彩內容，統一整理，希望為諸君帶來啟發。
一、企業級直播云服務的挑戰
成立于2005年的“獲得場景視頻”致力于面向全行業用戶提供一站式視頻解決方案，主要業務包括企業培訓、在線教育、數字人直播等。今天在此主要是和大家分享一下我們公司的架構是如何演進的。
首先簡述一下直播的應用場景。直播往往并不單獨存在，我們做的直播通常都跟各種業務環境相結合。比如教育直播就會結合到白板、問卷等教學工具；活動直播就會結合到排行榜、紅包雨等營銷工具；再比如賽事直播、大會直播、電商直播，數字人直播，可以說各有各的形式和需求。
通常來說，直播的業務流程分為推流、業務處理和拉流這三部分。推流涉及到多源輸入，手機、電腦攝像頭、VR采集設備都可以是輸入源，待這些媒體流/數據流上傳到云端后，經過源站，由于流的協議不一樣，所以要轉碼后再分發，處理的同時將視頻存下來以便回放和進行數據分析，最后根據不同的輸出端口進行不同的適配處理，達成多端輸出的結果。
具體到業務場景時，它又要和更上層的業務系統去打通、對齊。
重點講一下在提供企業級直播云服務的過程中面臨的挑戰。
第一，場景不同，需求也不同。比如說活動直播要求高清晰度；賽事直播動輒數十萬人甚至百萬人，因此要保證高并發；娛樂直播注重的則是高互動性。
第二，客戶研發能力不同。不同客戶的技術能力千差萬別。研發能力較高的企業往往只要求我們提供底層能力，比如SDK；研發能力中等或者要求不高的客戶，可能只要為他定制UI即可；另外一些研發能力還在起步階段的企業可能會傾向于讓我們提供開箱即用的軟件。對此，我們當然不可能逐一為其量身定制，我們的策略是分層，需要底層支持的開放PaaS，只想做定制UI的就提供UISDK或者APaaS，想要開箱即用一步到位的就開放我們的SaaS產品。
第三，客戶痛點。首先在視頻這一環節，延遲肯定是最大痛點之一，看直播時如果出現延遲、卡頓等現象會直接影響用戶體驗。然后不同場景下，更高的并發、突增的流量都可能形成挑戰。
二、如何提高流媒體質量
視頻直播里的重中之重是視頻質量。我們在看直播時，經常會遇到的異常現象有黑流、延遲、卡頓等。不管是什么因素引起的，前提都是某段鏈路出現了問題。
網絡一共分為三段，從推流端到邊緣節點，再到合流，再通過CDN分發。在每一段上最重要的是，如何選擇最合適的那一段鏈路，這就牽涉到調度問題。對于任何一個直播系統來說，優秀的調度系統一定是最重要的組成部分之一。
那何時做調度呢？其實不僅僅是開播時，從推流開始就涉及到調度了。我們會在四個環節分別進行調度：開播調度、推流重試調度、播放調度、熱切調度。
如何做調度呢？一定有兩個數據來源——服務端和客戶端。通常我們主動監控的就是服務端數據，流量如何、帶寬如何、負載如何，將這些數據都采集起來。但是問題在于，服務端的數據都是已經發生的數據，因為流來了，請求已經到了，服務器才會發生相應變化。那么還沒開始推流的時候呢？想象一下，更多的人打開客戶端，進入直播間，推流即將開始，請求即將到達。客戶端是知道這些數據的。所以我們把服務端數據和客戶端數據整合到一起，通過我們的決策模型來做調度，這樣的調度不僅僅是準確，更有一定的預測性。
當然做調度的前提是數據。我們每天最常處理的情況就是某個直播又卡了，某個節點負載又高了。具體情況到底如何，我們程序員通常會查看這些數據，從而了解是局部問題還是整體問題，以便更快地定位。
經過實際測算，我們發現，沒有這些數據之前，直播故障出現后要定位或者解除某個問題，都得超過30分鐘。現在我們可以做到3~4分鐘確定一個客訴到底是什么問題、什么級別。我們給這個系統起名叫“魔鏡”，也正在把魔鏡的數據對客戶開放，從而便于客戶自行排查。
關于故障問題的處理，如果通過服務商的程序員進行處理，響應再靈敏也要經過多級溝通。因此可以說，問題越能前置解決，影響就越小。本來很小的問題經過層層排查，可能也會因為響應不及時演變為較大的問題。所以問題越提前暴露，越能處理得更好。
三、如何支持高并發
在做直播的時候如何支持高并發？并發來了，會出現哪些問題？這里列舉三個比較有代表性的瓶頸點。
- 用戶登錄。大部分業務肯定都在登錄這塊或多或少出現過問題。
- 信令帶寬。做直播或視頻時，視頻帶寬容易出現問題，比如節點跑滿了。經常被忽略的是信令帶寬，比如說聊天尤其是多人刷屏時，也會占滿帶寬。
- 互動數據。比如紅包雨、投票等等。
下面具體分享一下我們針對這三點分別做了哪些針對性措施。
1.登錄優化
最初我們有個業務叫接口認證，用戶想登錄我們的系統的時候，用戶信息都存在我們客戶的系統，我們通過調用客戶的服務端去獲取他的信息去認證。
整體流程大概是：用戶從他要登錄的一個客戶的視頻列表頁，進入我們的直播播放頁，把用戶名、密碼給到我們的服務，我們再去請求服務端。
當初設計的時候我們沒有意識到這種操作有什么問題。后來發現，我們沒有辦法保證客戶的服務端是怎么樣的，我們可以做一些過載保護，但是如果很多客戶同時都在直播，這個地方就非常容易出問題。于是我們做了一個比較簡單的改造，就是我們不再去調客戶的服務，而是由客戶到我們這邊來創建，再通過列表頁把這個Token帶給我們，這樣就解決了這一典型問題。
2.信令帶寬
以聊天室業務為例，我發一個聊天，這個房間里的所有人都收到。如果這個平臺上跑了一萬個直播間，那屆時怎么處理呢？
打個比方，最開始有20臺服務器專門建立SocketIO，所有人都連上來。作為用戶，我要把一條消息發到其中一個Socket服務器上，然后通過一個廣播，經由Pub/sub，把這個信息同步發到另外20個服務器上。
這里的問題在于，本身就是活動直播，比如有一萬個人，你又有一萬個直播間，光這一條消息就放大了20倍，如果這個聊天室里再有人刷屏，這里的消息量堪稱恐怖。
架構是演進出來的，但有時也是緊急情況下催生的。2019年某個突發狀況下，我們花了三天三夜就進行了快速調整。收獲極大但思路很簡單，就是分組，按用戶、按渠道把你的資源進行分組，找到合理的組。
3.高性能模板
用戶看直播，除了獲取直播流以外，他可能還有一些業務數據要獲取，比如說他想看看能不能拉到歷史的聊天數據。
通常一場直播肯定都是先登錄直播頁，然后請求業務系統把這些歷史數據都分波拉下來。但是如果有一些直播量非常大，比如，你了解到某場直播在明天晚上7點有十萬人同時進，如果這些人同時請求你的業務系統，系統壓力一定會非常大。對此，我們可以正面解決，比如用彈性擴容、用容器化服務。但是我們也有一種迂回的思路，就是預制這些數據。
面向這種直播，我們肯定是可以做一些降級策略的。比如拉歷史聊天數據，聊天室里那么多消息，如果少了10條、20條，其實是不影響的，而且你可以把聊天室消息通過分類做區分，主播的消息不能丟，但是其他人的消息可以丟一點。最重要的是把這些數據提前都進行處理，預制到這個頁面里面，把它靜態化。其實用戶打開這個頁面的時候，大部分的數據都已經在這個頁面里了，只有很少的一部分是需要去服務端請求。通過這種預制數據的辦法，一下就能把請求數據量或者請求接口量降到原來的10%以下。因此這對我們來說也是很好的經驗。
四、如何實現高可用
關于如何實現高可用，首先分享一個很多年前的故障案例。
當時，我們的視頻處理組做了一個非常強大的功能升級——極速回放。原來視頻直播結束后，視頻錄制可能需要一段時間才能生成，功能升級后，直播結束立刻就能生成回放。沒想到這一功能上線后，出現了直播結束一大批觀眾立刻觀看回放，引起存儲元數據的數據庫壓力過大。而且當時我們還沒做拆分，回放一側出了問題，新用戶也無法加入直播間。后續我們就做了一些解耦。
第一步，把回放和直播在服務層解耦。直播怎么樣，不能影響回放。回放怎么樣，不能影響直播，踐行了一個基本的故障隔離的思路。
第二步，把回放元數據冷熱分離。直播中，特別是部分業務數據，比如畫筆，200毫秒一條，特別大的量，之前沒過多地對這份數據做處理。后來我們做了一些冷熱的分離，保證這個庫的壓力不會太大。
第三步，回放元數據實現靜態化。跟之前提到的高性能模版的思路一樣，我們提前對數據進行處理，把這些數據變成靜態化的，這樣再去請求頁面的時候，只請求這些數據，很少的一部分去請求數據庫。通過這樣的策略，也能大大提升我們的可用性。
另外，具體就回放來說，回放的業務某種程度上比直播更復雜。關于回放的處理，尤其是回放的錄制，我們也做了很多工作。
原來直播跟回放在一起，我們一臺服務器既負責直播流的轉發，又負責視頻文件存在本地的責任，所以經常會導致服務器IO和帶寬同時高，常常顧此失彼，導致利用率很低，彈性也很成問題。因為直播是有狀態的，視頻流一直推著，這個流不能切，一切就斷了，但錄制是可以的，因為你在這臺機器錄一半，在另外一臺機器再錄一半，然后把兩者拼在一起就可以了。所以我們花了不少精力打造有狀態的彈性的錄制系統。
此外，在直播安全方面，我們也采取了很多措施來防止盜鏈、盜播。盡管涉及到的系統邏輯不太一樣，但核心思路依然是把這些數據的功能拆分開來，盡可能做到解耦，讓每一個業務流彼此獨立。
五、組件化分層架構
關于分層架構的內容，我以問卷功能為例進行具體說明。之前我們的直播和互動也是在一起的，至少從業務邏輯上是不太區分的，簡單來說，直播推流和發起問卷都是由一個大模塊來管理。這里就出現了幾個問題。
- 變更風險大開發效率低。因為開發問卷功能或者進行問卷邏輯優化會影響到直播邏輯。
- 流量壓力。比如發紅包雨問卷時流量通常比較集中，問卷引發的流量可能影響直播服務。
- 信令帶寬。問卷是走信令，也會造成視頻的卡頓。
這三個問題意味著，必須將直播和互動分開。我們直接做了這樣的改造：把所有的問卷服務從直播服務都拆出來，全部SDK化。如圖所示，我們把直播類與互動類的信令分開，把業務邏輯分開，在UI層面把UI都分開。這樣一來，不僅能解決以上痛點，還能大大提升開發效率。
直播與互動彼此獨立，這樣的話就可以建設一套開放的、互動的組件平臺。而且作為云服務商來講，我們不但可以自己去開發這個組件，也可以邀請我們的合作伙伴或者我們的客戶自己去開發、貢獻他的組件。
綜合下來，分層架構的邏輯大致如此：最下面是IaaS層，然后是我們的支撐系統，支撐系統我們可以稱之為是PaaS層，這三層都可以對外提供。
把直播服務跟互動服務分開，其好處在于彼此可以獨立運作。而且現在建設異地研發中心漸成趨勢，雖然視頻會議很普及，但相較面對面溝通，溝通成本依然很高。更好的方案還是讓他們彼此不影響、彼此約定好接口、約定好規范，這是最高效的。所以把互動跟直播拆開，是我們近幾年來最重要的變化。
如果從客戶視角來看，從最底層的IaaS提供的組件，然后到INFSDK，面向的是自身有研發能力的這些客戶，他們可以直接自定義INFSDK。如果想只是自定義UI，不自定義業務流程，可以用UISDK。想開箱即用的這些客戶，可以直接使用SaaS應用。
然后我們是層層依賴的，最上層SaaS應用依賴UISDK，UISDK依賴INFSDK，整體再依賴Common-SDK。但是每一層又可以獨立地對外提供。組件化平臺，這也是我們近兩年的核心技術思路。這樣的方式就是可以對不同的類型客戶提供支持，自己又可以不用重復地去造輪子。
簡單總結一下組件化的技術價值：
- 代碼重用性：獨立開發和測試，被多個產品復用
- 系統靈活性：通過添加、替換組件輕松實現系統功能增強
- 提升開發團隊的協作能力：不同團隊同時開發，提升效率
- 技術生態系統發展：三方組件接入，豐富組件庫
六、未來展望：數字人直播
面向未來，我們主要的思路就是擁抱AI。我覺得，現在無論你談不談AI，首先你必須得接受，它就是一個必然的趨勢。但是也不必那么恐慌，因為我們最重要的就是如何使用它。總體來說，AI給我們直播行業也帶來了一個非常大的契機。
原來的數字人其實挺雞肋的，因為它沒有靈魂，它不懂你在說什么，一點不好玩。但是有AI的賦能之后，除了比較常見的語義理解外，更重要的是它能生成，能主動產生內容。如何把數字人和AI結合，是我們目前的一個重點方向。
我們現在已經上線的一個應用是人工智能客服。當然這個客服主要是針對教育場景的助理，教育場景通常有學員提問，而且教育場景又是很嚴肅的，不能亂說。很多時候GPT的回答五花八門，甚至可以說完全不著邊際。所以我們要去控制，對數據進行定制訓練，做更多的調優。后面我們還會對其他場景做優化，比如直播帶貨，還有一些口播的短視頻，這是我們現在正在測試階段的兩個產品。
總體來說，我覺得我們至少是直播行業，未來一定是跟AI緊密結合的，除了能看得見的應用，包括內部的流程，還有一些業務的邏輯，都是可以跟AI產生新的火花的。
