本次LiveVideoStackCon 2020北京線下峰會(huì)我們邀請(qǐng)到了北京二六三企業(yè)通信有限公司技術(shù)總監(jiān)李志濤來做分享。經(jīng)過多年的打造，263云視頻平臺(tái)已經(jīng)支持多協(xié)議、多種終端的使用場(chǎng)景，他將以視頻+戰(zhàn)略為導(dǎo)向，分享263運(yùn)營(yíng)級(jí)云視頻平臺(tái)搭建的技術(shù)迭代歷程。

大家好，我是來自北京二六三企業(yè)通信有限公司的李志濤，主要負(fù)責(zé)公司音視頻業(yè)務(wù)線的開發(fā)工作。

大家可能對(duì)263網(wǎng)絡(luò)通信有限公司比較陌生，用一句話概括：263深耕行業(yè)20年，做最懂企業(yè)互聯(lián)網(wǎng)通信的服務(wù)商。公司成立于1993年，前身是海誠(chéng)尋呼。在1999年成為基礎(chǔ)運(yùn)營(yíng)商以外國(guó)內(nèi)最大的撥號(hào)接入服務(wù)商。2001年，263自建機(jī)房成為國(guó)內(nèi)首批四星級(jí)IDC機(jī)房。2004年，263獲得國(guó)家多方通信牌照的電信增值服務(wù)商。2005年，263推出的企業(yè)郵箱成為企業(yè)郵箱外包服務(wù)國(guó)內(nèi)第一品牌。2010年，263網(wǎng)絡(luò)通信在深圳上市，股票代碼：002467，同年公司推出了263電話會(huì)議系統(tǒng)，這也是當(dāng)年我們國(guó)內(nèi)成長(zhǎng)最快的遠(yuǎn)程會(huì)議服務(wù)提供商。2015年，263收購(gòu)展視互動(dòng)，成為了國(guó)內(nèi)當(dāng)時(shí)最大的多媒體互動(dòng)直播技術(shù)服務(wù)商。2018年，263獲得了國(guó)內(nèi)首批移動(dòng)轉(zhuǎn)售牌照，推出企業(yè)定制移動(dòng)化通信服務(wù)，同年263推出了視頻+戰(zhàn)略。自此戰(zhàn)略上已經(jīng)從之前的尋呼、接入、消息、郵箱、電話會(huì)議，到現(xiàn)在基于音視頻的實(shí)時(shí)服務(wù)提供商，做了重大戰(zhàn)略轉(zhuǎn)型。

接下來，我將主要從四點(diǎn)來介紹263音視頻這塊，以視頻+戰(zhàn)略為導(dǎo)向，技術(shù)構(gòu)建方面的迭代方向。 1 263云視產(chǎn)品簡(jiǎn)介

經(jīng)過多年的打造，以263視頻云為基礎(chǔ)，支持多協(xié)議、多終端的使用場(chǎng)景，其中主要包括263云終端。云終端包括多款硬件終端，硬件終端主要根據(jù)企業(yè)辦公場(chǎng)景，針對(duì)個(gè)人參會(huì)、小型會(huì)議、中型會(huì)議、大型會(huì)議時(shí)，我們提出了多種終端的解決方案。除了會(huì)議室級(jí)別的，我們也支持任何場(chǎng)景、任何地域、任何時(shí)間都可以從移動(dòng)端、PC端、Windows端、Mac端、iOS端、安卓端入會(huì)，進(jìn)行實(shí)時(shí)音視頻會(huì)議溝通。 263視頻云對(duì)各種音視頻通信方式做了整個(gè)協(xié)議層的兼容，以WebRTC協(xié)議為主，兼容了VP8/VP9/H.264等編解碼方式，以及對(duì)多瀏覽器的兼容適配，對(duì)微軟Lync協(xié)議的接入支持?，F(xiàn)有相當(dāng)數(shù)量的企業(yè)客戶擁有大量的基于SIP和H.323協(xié)議的硬件終端，263視頻云對(duì)這些終端也做了協(xié)議支持，可以直接進(jìn)行接入使用。有些客戶購(gòu)買的成本比較高的思科、寶利通的硬件的MCU，我們打通了整個(gè)的視頻云來接入使用。 視頻云對(duì)我們傳統(tǒng)的PSTN網(wǎng)絡(luò)的電話會(huì)議進(jìn)行了融合接入。移動(dòng)電話以及座機(jī)可以通過電話會(huì)議平臺(tái)來進(jìn)行音頻接入，與視頻云進(jìn)行音頻的融合。視頻云的實(shí)時(shí)內(nèi)容以RTMP標(biāo)準(zhǔn)協(xié)議推送到云端進(jìn)行直播或點(diǎn)播。 1.1 能力矩陣

263視頻云系統(tǒng)的整個(gè)能力矩陣主要是有業(yè)務(wù)的管理系統(tǒng)、支撐管理、用戶管理、多業(yè)務(wù)平臺(tái)的管理、用戶認(rèn)證及權(quán)限信息管理。263視頻云提供了多種視頻服務(wù)場(chǎng)景：會(huì)議服務(wù)是解決企業(yè)遠(yuǎn)程辦公的；教育類服務(wù)，像大班、小班、雙師還有K12；遠(yuǎn)程醫(yī)療服務(wù)，遠(yuǎn)程醫(yī)療培訓(xùn)講解、遠(yuǎn)程手術(shù)等。 消息系統(tǒng)，主要有以下幾類消息，IM消息、應(yīng)用消息、消息通知；信令中轉(zhuǎn)系統(tǒng)，包括語音信令、音視頻信令、調(diào)度信令。出席系統(tǒng)主要是解決了用戶在登入之后，對(duì)他的消息調(diào)度進(jìn)行定位與管控。 實(shí)時(shí)RTC系統(tǒng)是我們的核心，包括WebRTC Service、Streaming Service。WebRTC Service主要接入的是用戶實(shí)時(shí)音視頻通信的Web服務(wù)和App的服務(wù)，Streaming Service主要接入的是用戶推流和直播服務(wù)。Core核心系統(tǒng)主要是進(jìn)行整個(gè)集群的管理和調(diào)度，包括整個(gè)集群硬件可用性的管理，硬件服務(wù)器上限、下限的管理，負(fù)載均衡與失效轉(zhuǎn)移的管理，系統(tǒng)平行擴(kuò)展的管理，根據(jù)系統(tǒng)負(fù)載情況進(jìn)行ROOM級(jí)別的任務(wù)調(diào)度管理?；谝粢曨l配置進(jìn)行MCU轉(zhuǎn)碼和混屏處理。SIP Service主要是解決了和外系統(tǒng)SIP模塊的對(duì)接，包括電話會(huì)議和基于SIP限令的第三方硬件、第三方系統(tǒng)。Recording 是對(duì)會(huì)議、教育、遠(yuǎn)程醫(yī)療等業(yè)務(wù)有錄制需求的，進(jìn)行按需錄制的服務(wù)。 263直播網(wǎng)絡(luò)，主要對(duì)接到263現(xiàn)有的直播系統(tǒng)，同時(shí)也向阿里云、騰訊云進(jìn)行推流。導(dǎo)播臺(tái)基于推流直播時(shí)做一些導(dǎo)播、插播的增值服務(wù)功能。直播管理針對(duì)直播的權(quán)限、直播會(huì)場(chǎng)管控等進(jìn)行管理。云存儲(chǔ)是與錄制件相關(guān)聯(lián)的，錄制件基于對(duì)象存儲(chǔ)方式存放在云存儲(chǔ)之后，可以進(jìn)行相關(guān)業(yè)務(wù)需求的VOD點(diǎn)播。 公共應(yīng)用系統(tǒng)有多重應(yīng)用服務(wù)，調(diào)查問卷、投票、打賞等。電話會(huì)議系統(tǒng)以硬件會(huì)議橋?yàn)楹诵牡腜STN會(huì)議系統(tǒng)。SIP MCU可以對(duì)接外系統(tǒng)SIP MCU或與SIP終端進(jìn)行對(duì)接。 1.2 SaaS&PaaS

我們提供SaaS&PaaS的接口能力，上半部分主要是SaaS層的能力，會(huì)議類、教育類的應(yīng)用，還有遠(yuǎn)程醫(yī)療類的應(yīng)用。整個(gè)系統(tǒng)包括消息SDK、共享SDK、標(biāo)注SDK， RTC的SDK、點(diǎn)播SDK和直播SDK。我們也可以給有深入開發(fā)能力的客戶提供PaaS層能力的開發(fā)接口。整個(gè)調(diào)用方式是方法、函數(shù)調(diào)用，底層基于Socket或RPC形式進(jìn)行通信。 2 技術(shù)架構(gòu)

接下來是近幾年我們整個(gè)的技術(shù)架構(gòu)的迭代的步驟。

263云視技術(shù)開源基礎(chǔ)基于Google開源的WebRTC和Intel開源的OWT這兩個(gè)項(xiàng)目。 2.1 架構(gòu)拓?fù)銿1.0

整個(gè)的技術(shù)框架是從第一代開始搭建。第一代系統(tǒng)，按照功能分為兩層構(gòu)建，采用集群分布式部署，基本分布了4類IDC，第一層IDC是我們核心的BJ DC，第二層主要解決國(guó)內(nèi)南北互聯(lián)互通，跨運(yùn)營(yíng)商訪問的接入問題。針對(duì)海外用戶訪問系統(tǒng)，我們提供了海外接入點(diǎn)。 到目前為止，由于對(duì)成本的考慮，不可能對(duì)全國(guó)各大城市都去布機(jī)房布節(jié)點(diǎn)，所以我們?cè)谟脩羰褂帽容^多的地方，布了幾個(gè)節(jié)點(diǎn)，其他的節(jié)點(diǎn)我們目前使用阿里云進(jìn)行補(bǔ)充。我們主要使用阿里云的ECS和它的帶寬，目前就全國(guó)用戶接入263視頻云系統(tǒng)來說訪問阿里云的幾個(gè)節(jié)點(diǎn)質(zhì)量還是不錯(cuò)的，可以保障國(guó)內(nèi)用戶使用的全覆蓋。這是我們整個(gè)系統(tǒng)架構(gòu)拓?fù)涞?.0系統(tǒng)。 1.0系統(tǒng)最大的問題是同區(qū)域同運(yùn)營(yíng)商不同IDC的交互都需要到中心節(jié)點(diǎn)交換，成本較高。再有數(shù)據(jù)鏈路較長(zhǎng)，用戶延時(shí)比較大，針對(duì)RTC應(yīng)用來說，正常是在400毫秒可以接受，而物理距離來回兩千公里，這個(gè)延時(shí)可觀?；谶@些問題，我們開發(fā)了2.0版本。 2.2 架構(gòu)拓?fù)銿2.0

基于架構(gòu)拓?fù)?.0的問題，我們開發(fā)了2.0版本,主要做了一個(gè)分層，加了一個(gè)Relay 池，同一區(qū)域，相同運(yùn)營(yíng)商，或是跨區(qū)域相同運(yùn)營(yíng)商的用戶訪問層之間可以互通。如果他們之間不能互通，可以通過Relay池進(jìn)行互轉(zhuǎn)，這個(gè)Relay可以進(jìn)行平衡擴(kuò)展的。整個(gè)架構(gòu)從1.0的二層變成了2.0的三層，北京IDC及Relay層IDC走的是多線BGP機(jī)房進(jìn)行部署。 針對(duì)海外，基于美國(guó)、德國(guó)、歐洲、香港加了Relay層節(jié)點(diǎn)。用戶是基于本地進(jìn)行交互的，直接從本地走，不需要到核心機(jī)房進(jìn)行數(shù)據(jù)中轉(zhuǎn)，用戶的延時(shí)感受會(huì)很好。同時(shí)北京的核心機(jī)房做了高可用改造，當(dāng)其中一個(gè)核心機(jī)房遭到攻擊，可以迅速進(jìn)行熱備切到其他機(jī)房。 2.3 媒體信令邏輯

系統(tǒng)中媒體信令邏輯主要體現(xiàn)了三個(gè)層，背景核心層，中間的多線接入機(jī)房Relay層，還有用戶就近訪問的接入訪問層。核心邏輯OWT Core，基于Intel的OWT來進(jìn)行的二次開發(fā)，主要負(fù)責(zé)整個(gè)系統(tǒng)的計(jì)算、管控、調(diào)度。SRC解決智能選路問題，用戶會(huì)在全球各地接入訪問，SRC負(fù)責(zé)找到一個(gè)離他訪問網(wǎng)絡(luò)質(zhì)量最好的Access。MC系統(tǒng)負(fù)責(zé)服務(wù)器可用性的訪問甄別，分配負(fù)載低、運(yùn)行同質(zhì)業(yè)務(wù)的服務(wù)器給用戶。 3 媒體通訊模式

3.1 基本模式

目前263云視頻各方面的技術(shù)保障已經(jīng)能解決一些接入訪問的質(zhì)量問題，但如果一些業(yè)務(wù)場(chǎng)景、業(yè)務(wù)模式錯(cuò)誤地使用了基本通信模式，導(dǎo)致流量增大、帶寬受限、服務(wù)器計(jì)算資源占用過高，網(wǎng)絡(luò)抖動(dòng)、丟包、延遲對(duì)實(shí)時(shí)音視頻適量的影響較大等問題。上圖主要表述了WebRTC目前為止使用的幾種通信模式。第一種MESH模式，WebRTC兩個(gè)點(diǎn)是直連的，媒體走P2P方式進(jìn)行互通。 第二種SFU與MESH之間有一些共性，區(qū)別是它把所有的媒體都經(jīng)過服務(wù)器進(jìn)行轉(zhuǎn)發(fā)。針對(duì)每一個(gè)客戶端，流的上行是1路，下行是n-1路。兩者劣勢(shì)基本一樣，優(yōu)勢(shì)是流通過服務(wù)器進(jìn)行Relay，便于混流推流直播或者其錄制操作。 第三種是基于MCU方式，MCU好處是1路上行，1路下行，客戶端耗費(fèi)帶寬小，由于該種模式需要對(duì)音視頻進(jìn)行Mixer混流，消耗服務(wù)器CPU及GPU的計(jì)算資源。以上幾種通信模式各有利弊，后續(xù)會(huì)講到基于不同業(yè)務(wù)使用場(chǎng)景而采用的基本通信方式外加混合通信方式的組合方式。 3.2 版本1.0

上圖是1.0使用的數(shù)據(jù)流程圖。Client按照業(yè)務(wù)邏輯進(jìn)行音視頻的發(fā)布和訂閱，右邊是服務(wù)器，在1.0中我們同時(shí)支持MCU和SFU。我舉例了4個(gè)Access模塊，虛線代表基于UDP協(xié)議的用戶層訪問。如果用SFU模式的話，就不涉及服務(wù)器后臺(tái)的運(yùn)算能力。端上使用不同的編解碼方式也會(huì)使用到服務(wù)器后臺(tái)的MCU模塊的轉(zhuǎn)碼能力，轉(zhuǎn)碼之后再進(jìn)行下發(fā)客戶端。采用MCU的業(yè)務(wù)場(chǎng)景會(huì)到MCU模塊進(jìn)行音頻和視頻的混音合屏。在這個(gè)版本中SFU缺少SVC或Simulcast的加持，所以音視頻質(zhì)量不好保障。 3.3 版本1.5

我們?cè)谥虚g又推出了1.5版本，主要用服務(wù)器MCU合屏，客戶端屏幕剪切方式實(shí)現(xiàn)了用戶使用場(chǎng)景的靈活性。剪切完以后每一路都是可以單獨(dú)顯示，靈活布局。 3.4 版本2.0

2.0版本基于1.0版本演變而來，原有SFU增加了Simulcast功能，同時(shí)也沿用了MCU。MCU我們又做了一些功能的拓展，包括RTMP推流，RTMP推流時(shí)可以按照用戶自定義的編碼格式、自定義布局推送?？梢院蚐IP網(wǎng)關(guān)打通，既可以和硬件MCU系統(tǒng)進(jìn)行融合，也可以通過SIP網(wǎng)關(guān)與PSTN電話會(huì)議進(jìn)行融合。 3.5Hybrid模式

這是前面提到的，我們整個(gè)系統(tǒng)是基于SFU和MCU這種方式來實(shí)現(xiàn)。SFU的優(yōu)勢(shì)是靈活分發(fā)、并發(fā)高，實(shí)時(shí)性也高，劣勢(shì)是下行轉(zhuǎn)發(fā)路數(shù)多，帶寬占用高，影響體驗(yàn)，客戶端維護(hù)多路連接的成本高。MCU的優(yōu)勢(shì)是下行帶寬占用少，劣勢(shì)是服務(wù)器性能要求高，部署成本太高，同時(shí)增加服務(wù)器環(huán)節(jié)，實(shí)時(shí)性略差。 我們采用的混合模式是基于MCU+SFU，業(yè)務(wù)場(chǎng)景決定了用MCU還是SFU。如果是五方以下的，SFU優(yōu)勢(shì)還是合適的，成本較低。如果是超過6方以上的，客戶的附加值高一些的話，使用MCU計(jì)算資源。交互方式?jīng)Q定通信模式。 4 運(yùn)營(yíng)級(jí)技術(shù)疊加

我們剛才講了WebRTC和OWT這塊。我們?cè)趯?shí)際使用中，根據(jù)我們遇到的弱網(wǎng)質(zhì)量問題，優(yōu)化了音視頻傳輸?shù)腘ACK和FEC功能。解決音視頻唇音不同步的問題。通過切流功能，解決我們?cè)贛CU方式下用戶的各端TV端、電腦端、移動(dòng)端等所希望收到不同分辨率的問題，大屏是1080P，PC端是720P，移動(dòng)端可能是360P已經(jīng)足夠了。同時(shí)也解決了不同的用戶根據(jù)自己的網(wǎng)絡(luò)質(zhì)量獲取不同碼流數(shù)據(jù)的問題。 系統(tǒng)在跨IDC時(shí)，集群內(nèi)部偶發(fā)網(wǎng)絡(luò)閃斷，會(huì)出現(xiàn)一些異常，增加了容錯(cuò)機(jī)制確保系統(tǒng)的健壯性。數(shù)據(jù)庫方面使用了MongoDB集群，RabbitMQ消息總線使用了HAProxy+3RMQ高可用。 以上這些分享都是我們對(duì)這套系統(tǒng)所做的一個(gè)適合運(yùn)營(yíng)級(jí)的改造。

責(zé)任編輯：lq