263運營級云視頻平臺搭建的技術(shù)迭代歷程

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

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

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

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

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

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

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

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

263云視技術(shù)開源基礎基于Google開源的WebRTC和Intel開源的OWT這兩個項目。 2.1 架構(gòu)拓撲V1.0

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

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

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

3.1 基本模式

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

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

我們在中間又推出了1.5版本，主要用服務器MCU合屏，客戶端屏幕剪切方式實現(xiàn)了用戶使用場景的靈活性。剪切完以后每一路都是可以單獨顯示，靈活布局。 3.4 版本2.0

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

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

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

責任編輯：lq