本文來(lái)自英特爾實(shí)時(shí)通信解決方案架構(gòu)師 段先德在LiveVideoStackCon2019上海大會(huì)的分享，詳細(xì)介紹了英特爾在進(jìn)行分布式SFU/MCU媒體服務(wù)器的架構(gòu)設(shè)計(jì)中秉持的一些設(shè)計(jì)原則以及關(guān)鍵問(wèn)題的解決思路。

文 /?段先德

整理 /?LiveVideoStack

大家好，我是來(lái)自英特爾上海研發(fā)中心的段先德。從2014年開(kāi)始主要做基于WebRTC的實(shí)時(shí)通信和統(tǒng)一通信解決方案。對(duì)于實(shí)時(shí)通訊來(lái)說(shuō)WebRTC技術(shù)是一個(gè)革命性的存在。2014年4月英特爾發(fā)布了Intel? Collaboration Suite for WebRTC，這是一款可免費(fèi)使用的包含服務(wù)器側(cè)程序和客戶端SDK的完整解決方案。經(jīng)過(guò)多年的迭代更新，當(dāng)前最新發(fā)布的是4.2版本。

1.?Requirements and Design Principles

本次分享的內(nèi)容主要分為三個(gè)部分，首先介紹英特爾ICS for WebRTC項(xiàng)目中要解決的問(wèn)題；其次介紹我們?cè)诮鉀Q這些問(wèn)題的時(shí)候的指導(dǎo)思想和整體設(shè)計(jì)原則；最后介紹我們的解決方案目前的狀態(tài)以及當(dāng)下和近期要做的一些事情。

1.1 Functional Requirements

我們項(xiàng)目團(tuán)隊(duì)最初的出發(fā)點(diǎn)是希望能做一套夠達(dá)到一般功能性要求的基于互聯(lián)網(wǎng)的視頻會(huì)議解決方案。譬如可以支持WebRTC和SIP終端，實(shí)現(xiàn)接入到同一個(gè)會(huì)議中。SIP主要針對(duì)的是存量設(shè)備，重點(diǎn)是對(duì)WebRTC終端的支持。WebRTC接入相比于很多以前存量的企業(yè)視頻會(huì)議解決方案有很多的突破，從2011年以后Chrome在端多媒體系統(tǒng)，弱網(wǎng)對(duì)抗方面以及音視頻處理這方面一直在持續(xù)的改進(jìn)。

英特爾很早就注意到在WebRTC時(shí)代，亟需一個(gè)統(tǒng)一的終端和服務(wù)器側(cè)的解決方案。我們需要把企業(yè)內(nèi)外的一些移動(dòng)終端、桌面應(yīng)用、瀏覽器、傳統(tǒng)的SIP終端設(shè)備都支持起來(lái)，需要支持NAT穿越和屏幕共享，需要支持服務(wù)器側(cè)音視頻錄制，等等。這里面很多功能性需求通過(guò)傳統(tǒng)SIP的解決方案做起來(lái)很不方便或者成本很高，但是在WebRTC時(shí)代，在基于互聯(lián)網(wǎng)應(yīng)用的技術(shù)思路下，可以很便捷、很優(yōu)雅地解決這些問(wèn)題，于是我們?cè)?014年做了ICS for WebRTC v1.0。之后在2016年和2017年之間直播類的應(yīng)用大爆發(fā)使得有些客戶希望我們的解決方案里面能夠支持直播類場(chǎng)景，把實(shí)時(shí)互動(dòng)場(chǎng)景下的音視頻流通過(guò)RTMP/RTSP/HLS/Dash推送到現(xiàn)有的CDN網(wǎng)絡(luò)里面去。基于這類需求，我們?cè)诠δ苄苑矫嬖黾恿嘶?dòng)Streaming的能力。

2018年到現(xiàn)在，直播的用戶體驗(yàn)要求越來(lái)越高，客戶希望主播和粉絲或者觀眾之間的互動(dòng)能夠非常平滑的切換，同時(shí)端到端的時(shí)延也能夠做得更好，也就是希望做到保證端到端的實(shí)時(shí)性的前提下，在單個(gè)呼叫里支持海量的用戶連接。這就要求服務(wù)器側(cè)系統(tǒng)既要有非常大的“扇出”能力，要支持終端連接在“發(fā)布者”和“訂閱者”之間非常平滑地進(jìn)行切換。我們目前正在做的就是把目前的解決方案擴(kuò)展到這種能夠支持大規(guī)模并發(fā)的“實(shí)時(shí)互動(dòng)廣播”，初步目標(biāo)是單個(gè)呼叫里達(dá)到百萬(wàn)以上的并發(fā)連接，而且端到端的時(shí)延能夠全球控制在300毫秒以內(nèi)。關(guān)于端到端時(shí)延，我們?cè)趪?guó)內(nèi)互聯(lián)網(wǎng)上做過(guò)一些小規(guī)模的測(cè)試，測(cè)試結(jié)果的時(shí)延是150毫秒以內(nèi)。我們還希望這個(gè)解決方案能夠很方便封裝成類似于CDN的服務(wù)訪問(wèn)接口或者形式，以便集成到客戶現(xiàn)有的直播解決方案中去。

我們當(dāng)前的解決方案已經(jīng)具備了非常靈活的服務(wù)器側(cè)媒體處理，服務(wù)器端可以做音視頻的混音混流，比如說(shuō)當(dāng)前的一個(gè)呼叫里面有十幾個(gè)參與方，有的參與方希望訂閱呼叫中其他參與方發(fā)布的原始流，有的參與方希望訂閱所有或部分參與方的mix流，有的參與方希望訂閱符合自己對(duì)codec、分辨率、幀率、碼率等定制化要求的轉(zhuǎn)發(fā)流，我們當(dāng)前的解決方案已經(jīng)可以很好地支持這些需求。

1.2 Nonfunctional Requirements

如果僅僅是為了達(dá)到前面所講的各種功能性需求，隨便選擇一個(gè)現(xiàn)有的開(kāi)源框架去改改，再自己從頭寫一些功能模塊拼湊一下，總可以整出一個(gè)PoC的版本或可以初步走向產(chǎn)品的東西。如果是要嚴(yán)肅地做一個(gè)打算把它放到生產(chǎn)環(huán)境去運(yùn)營(yíng)的產(chǎn)品級(jí)別的東西，真正考驗(yàn)這個(gè)解決方案的生命力的其實(shí)是它在非功能性需求方面的取舍和功力。即使是選擇現(xiàn)有的開(kāi)源框架去做產(chǎn)品，這個(gè)框架對(duì)非功能性方面的考量也是最重要的決定因素。

在非功能性方面主要關(guān)注的點(diǎn)有三個(gè)方面。

一是系統(tǒng)的可擴(kuò)展性，它的服務(wù)部署規(guī)模可大可小，可以小到在一臺(tái)英特爾???酷睿??i7的PC上部署使用，大到一個(gè)集群幾百臺(tái)甚至上千臺(tái)機(jī)器組成一個(gè)大的cluster上部署使用。另外呼叫的參與方式可以是兩三個(gè)人的討論會(huì)，或者十幾個(gè)人一般視頻會(huì)議，又或者是幾十人的在線課堂。部署時(shí)可以在當(dāng)前的系統(tǒng)容量不足時(shí)在不中斷業(yè)務(wù)的前提下增加或者刪減當(dāng)前部署的規(guī)模，達(dá)到很靈活的Scale in/Scale out。

二是容錯(cuò)性，容錯(cuò)能力大多描述都比較抽象，但是落實(shí)到系統(tǒng)在做設(shè)計(jì)的時(shí)候要考慮的東西就是非常具體的設(shè)計(jì)決策，在系統(tǒng)設(shè)計(jì)里面我們會(huì)強(qiáng)調(diào)甚至固執(zhí)的堅(jiān)持每一個(gè)部件都可能會(huì)出錯(cuò)，運(yùn)行時(shí)都會(huì)發(fā)生crash，這就需要在流程設(shè)計(jì)或者一般邏輯里面handle這些問(wèn)題，在系統(tǒng)發(fā)生部分失效的時(shí)候，要能夠做到自動(dòng)恢復(fù)或服務(wù)優(yōu)雅降級(jí)。

三是分布式部署，單臺(tái)機(jī)器上單實(shí)例的部署是不可能做容錯(cuò)的，只有分布式的部署才能夠做到。我們要求允許把任何部件部署在數(shù)據(jù)中心的多臺(tái)機(jī)器上面。我們現(xiàn)在進(jìn)一步的要求是要能夠把任何部件部署在多個(gè)數(shù)據(jù)中心，進(jìn)行跨數(shù)據(jù)中心的分布式部署。

?

2.Unified Media Spread Model UMSM）

2.1 Modularization at Runtime

要滿足上述的各種功能性和非功能性需求，就需要在概念模型上對(duì)系統(tǒng)的各個(gè)部件進(jìn)行足夠的抽象，將邏輯上獨(dú)立的部件封裝到運(yùn)行時(shí)獨(dú)立的模塊里面——即模塊化。不管是從單一職責(zé)的角度來(lái)說(shuō)，還是從系統(tǒng)的可組合性來(lái)說(shuō)，模塊化是自始至終不能打破的一個(gè)原則，是我們當(dāng)前系統(tǒng)——也是很多復(fù)雜系統(tǒng)進(jìn)行架構(gòu)的第一原則。在我們的系統(tǒng)設(shè)計(jì)中，對(duì)于跟客戶端交互的部件來(lái)說(shuō)，要把信令和媒體分開(kāi)。對(duì)于媒體部分來(lái)說(shuō)，媒體的接入部分和處理部分一定是分開(kāi)的，直接和用戶打交道的部分和后臺(tái)內(nèi)部的一些處理部件，不管是從單一職責(zé)角度來(lái)講還是從面向接口的健壯性要求來(lái)講都必須把它們分開(kāi)。

我們的服務(wù)器側(cè)系統(tǒng)在運(yùn)行時(shí)可以分成五大塊。

第一塊就是跟客戶端進(jìn)行信令交互的部件，即圖中的WebRTC Portal和SIP Portal。他們跟WebRTC客戶端和SIP終端進(jìn)行信令交互。值得注意的一點(diǎn)是WebRTC標(biāo)準(zhǔn)對(duì)信令交互的格式和通道沒(méi)有規(guī)定，我們采用的是一種承載在socket.io通道中的私有協(xié)議。

第二塊是跟客戶端進(jìn)行音視頻媒體交互的部件，即圖中的WebRTC Agent、Streaming Agent、SIP Agent和Recording Agent。其中WebRTC Agent負(fù)責(zé)跟客戶端之間建立PeerConnection連接，SIP Agent跟SIP終端RTP流進(jìn)行傳輸，Streaming Agent是針對(duì)RTSP/RTMP/HLS/Dash流，我們可以把IPCamera的RTSP流作為輸入直接拉到系統(tǒng)里面來(lái)，也可以把系統(tǒng)里面任何一個(gè)輸入流/合成流/轉(zhuǎn)碼后的流作為輸出推送到RTMP Server上去，Recording雖然是完全發(fā)生在服務(wù)器側(cè)的行為，但實(shí)際上在概念層次上面是更接近于流的輸出。所以在概念模型里我們也把Recording Agent當(dāng)做媒體接出部件，以達(dá)到概念模型的一致性。

第三塊是媒體處理的部件，即圖中的Audio Agent和Video Agent。Audio Agent是進(jìn)行音頻混音轉(zhuǎn)碼工作的部件，Video Agent是視頻的合屏和轉(zhuǎn)碼的部件，這些所有的部件都是單獨(dú)部署獨(dú)立進(jìn)程在運(yùn)行。

第四塊是呼叫控制的部件，即圖中的Conference Agent。我們的系統(tǒng)還是將多方實(shí)時(shí)音視頻通信作為場(chǎng)景基礎(chǔ)，Conference Agent就是一通呼叫的總控制部件，它負(fù)責(zé)room中的參與者、流、訂閱關(guān)系的控制和管理。對(duì)于像遠(yuǎn)程教育、遠(yuǎn)程醫(yī)療、遠(yuǎn)程協(xié)助之類的其他場(chǎng)景，我們主要是通過(guò)對(duì)Conference Agent來(lái)進(jìn)行拓展和增強(qiáng)去支持。

第五塊就是一些支持部件。整個(gè)服務(wù)器系統(tǒng)在運(yùn)行和單機(jī)運(yùn)行時(shí)都是cluster形式，Cluster Manager就是一個(gè)簡(jiǎn)單的cluster管理器。視頻會(huì)議場(chǎng)景中會(huì)有一些room的預(yù)配置和管理，room的配置數(shù)據(jù)存放在MongoDB中，管理員都是通過(guò)OAM UI通過(guò)RESTful API訪問(wèn)Management API部件實(shí)現(xiàn)數(shù)據(jù)訪問(wèn)并受理REST請(qǐng)求。另外各個(gè)部件之間的rpc是架設(shè)在RabbitMQ消息隊(duì)列上的。

?

2.2 Strong Isolation

第二個(gè)原則就是要做強(qiáng)隔離。在系統(tǒng)里面堅(jiān)持執(zhí)行的原則就是要做強(qiáng)隔離，運(yùn)行時(shí)一定是把看到的邏輯上面獨(dú)立部件，把它在物理上也做成完全獨(dú)立的運(yùn)行時(shí)進(jìn)程。比如像信令受理部件和信令執(zhí)行部件就是分別獨(dú)立的進(jìn)程。這樣做使得信令受理部件可以獨(dú)立于呼叫控制里面的業(yè)務(wù)邏輯而存在。同理媒體接入部件和媒體處理部件也是分別獨(dú)立進(jìn)程。這里的進(jìn)程就是OS語(yǔ)義上面進(jìn)程，是我們服務(wù)器側(cè)系統(tǒng)構(gòu)建的基本元素，是生命體的細(xì)胞，不同的部件之間進(jìn)行通訊唯一的方式就是message passing（消息傳遞）。在概念模型里面看的得到部件都是用單獨(dú)的Worker進(jìn)程來(lái)處理一個(gè)獨(dú)立的Job。比方說(shuō)一個(gè)Video Agent生成出來(lái)的Video Node，它的職責(zé)要么是做一個(gè)視頻混流器，要么是做一個(gè)視頻轉(zhuǎn)碼器，單獨(dú)運(yùn)行，獨(dú)立工作。這樣做一方面是進(jìn)行錯(cuò)誤隔離一個(gè)部件中產(chǎn)生的異常不會(huì)傳染影響其他部件，一方面是各個(gè)運(yùn)行時(shí)部件可以進(jìn)行運(yùn)行時(shí)單獨(dú)進(jìn)行升級(jí)替換。

?

2.3 Hierarchy in Media Accessing/Processing

第三個(gè)原則就是層次化。具體體現(xiàn)在在媒體接入和媒體處理的一些部件的設(shè)計(jì)和實(shí)現(xiàn)上，這些部件在南北（縱）向上面有明確的層次劃分，自下而上分為包交互層、幀交互層和內(nèi)容操作層。以媒體接入部件為例，我們服務(wù)器側(cè)系統(tǒng)需要跟各種外圍系統(tǒng)和終端進(jìn)行媒體交互，有的媒體是通過(guò)RTP/SRTP包的形式輸入、輸出，有的媒體是直接以AVStream的行書輸出、輸出。當(dāng)媒體進(jìn)入到我們服務(wù)器側(cè)系統(tǒng)內(nèi)部以后，我們希望有一個(gè)統(tǒng)一的格式讓它在所有的媒體相關(guān)部件之間自由流轉(zhuǎn)，所以我們就定義了統(tǒng)一的MediaFrame格式，所有輸入的媒體在媒體接入部件上被組裝成MediaFrame。處理MediaFrame的邏輯我們把它放在幀交互層，與客戶端進(jìn)行RTP/SRTP交互的邏輯我們放在包交互層。另外，MediaFrame進(jìn)入媒體處理部件后，如果涉及到raw格式的操作——譬如合屏、色彩調(diào)整、添加水印、替換背景等——我們就把相關(guān)邏輯放在內(nèi)容操作層。

?

2.4 Media Pipeline in WebRTC Node

設(shè)計(jì)原則講起來(lái)太枯燥，舉兩個(gè)例子。

第一個(gè)是WebRTC Node中的Pipeline結(jié)構(gòu)。在WebRTCNode上面有一個(gè)明確的一個(gè)界限，廣為人知的一些開(kāi)源的框架里面有一些SFU框架是直接做RTP包的高級(jí)轉(zhuǎn)發(fā)，而在我們的解決方案里于所有的外部媒體進(jìn)入到系統(tǒng)里面會(huì)先將它們整理成統(tǒng)一的媒體（幀集的封裝）之后在各個(gè)結(jié)點(diǎn)之間進(jìn)行傳輸。除了使得層次分明便于系統(tǒng)橫向擴(kuò)展以外，另外一大好處就是把RTP傳輸相關(guān)的事務(wù)都終結(jié)在媒體接入部件（節(jié)點(diǎn)）上，RTP傳輸中的丟包、亂序等問(wèn)題的處理不會(huì)擴(kuò)散到系統(tǒng)其它部件。

?

2.5 Media Pipeline in Video Node (Video Mixer)

第二個(gè)例子是視頻混流器內(nèi)部的Pipeline結(jié)構(gòu)。視頻混流的部件在Pipeline上面進(jìn)出都是視頻幀，圖上紫顏色的模塊進(jìn)出的都是視頻已編碼的幀，在視頻處理部件的內(nèi)部可以是一些已編碼的幀，也可以是一些Scaler和Convertor。使得各個(gè)層次的處理器接口非常清楚，便于做成plugable。

?

2.6 Unified Media Spread Model (UMSM)

前面我們根據(jù)系統(tǒng)的功能性和非功能性需求，把系統(tǒng)拆成了一個(gè)個(gè)松散的部件。那么，怎么把這些部件捏合到一起成為一個(gè)有機(jī)的系統(tǒng)呢？特別是針對(duì)各個(gè)媒體接入部件和媒體處理部件之間的媒體交互，我們需要定義一個(gè)統(tǒng)一的內(nèi)部媒體交互模型——我們稱之為UMSM。

音視頻媒體在系統(tǒng)內(nèi)部流動(dòng)，我們采用的是一個(gè)“發(fā)布-訂閱”結(jié)構(gòu)的流基本拓?fù)洹?/span>如圖所示，系統(tǒng)有一個(gè)發(fā)布者發(fā)布一個(gè)流進(jìn)入到系統(tǒng)里，此時(shí)有兩個(gè)訂閱者，其中一個(gè)訂閱者希望訂閱發(fā)布的原始流的直接轉(zhuǎn)發(fā)流，另外一個(gè)訂閱者希望訂閱房間里面所有的原始流合成流合屏以后的mix流，流的發(fā)布者和訂閱者的PeerConnection連接建立在不同的WebRTC Node上面，通過(guò)PeerConnection進(jìn)入WebRTC Node的SRTP包流，經(jīng)過(guò)解密，被整理封裝成MediaFrame（Audioframe/Videoframe），之后再在不同的部件之間進(jìn)行傳遞，如果有訂閱者需要的是直接轉(zhuǎn)發(fā)流，就把它封裝好的音頻和視頻的幀直接擴(kuò)散到訂閱者所連接的WebRTC Node上面來(lái)，如果有訂閱者需要合成的流（合屏和混音的流），那么就把混流和混音以后的MediaFrame從AudioNode（Audio Mixer）和VideoNode（Video Mixer）擴(kuò)散到訂閱者所連接的WebRTC Node上。

有了這樣一個(gè)足夠松散的系統(tǒng)內(nèi)部流擴(kuò)散結(jié)構(gòu)，無(wú)論這些媒體接入部件和媒體處理部件是運(yùn)行在同一臺(tái)機(jī)器上還是運(yùn)行在一個(gè)數(shù)據(jù)中心內(nèi)的不同機(jī)器上——甚至運(yùn)行在位于不同數(shù)據(jù)中心的不同機(jī)器上，都有統(tǒng)一的、一致的流拓?fù)浣Y(jié)構(gòu)。

?

2.7 Media Spread Protocol

要實(shí)現(xiàn)這樣一個(gè)流擴(kuò)散模型，重點(diǎn)要解決兩個(gè)方面的問(wèn)題，一個(gè)是媒體節(jié)點(diǎn)間的傳輸，另一個(gè)是媒體節(jié)點(diǎn)的控制。

媒體節(jié)點(diǎn)間的傳輸是面向連接的，因?yàn)閿U(kuò)散鏈路都可能持續(xù)比較長(zhǎng)的時(shí)間，且一般服務(wù)器側(cè)部件的部署環(huán)境的網(wǎng)絡(luò)條件是可控的，有利于保障傳輸質(zhì)量。另外每一個(gè)連接結(jié)點(diǎn)間的擴(kuò)散鏈路的連接是雙向的，因?yàn)橛锌赡軆蓚€(gè)媒體流的接入結(jié)點(diǎn)之間存在雙向的擴(kuò)散，以及與媒體流相關(guān)的一些feedback信息需要被反向傳遞，我們希望它能夠復(fù)用在同一個(gè)擴(kuò)散鏈路上面。另外我們需要它是可靠的，在以前跟合作伙伴做技術(shù)交流的時(shí)候他們對(duì)于要求流擴(kuò)散鏈路必須是可靠的這一點(diǎn)有疑惑。實(shí)際上這是一個(gè)實(shí)時(shí)性和可靠性的取舍問(wèn)題，我們選擇在這個(gè)環(huán)節(jié)保證可靠性，而把實(shí)時(shí)性推給底層去解決，因?yàn)槿绻诹鲾U(kuò)散鏈路的所有環(huán)節(jié)處理信號(hào)損失，將給上層邏輯帶來(lái)巨大的復(fù)雜性。

?

2.8 MSP - Transport Control Primitives(WIP)

傳輸控制就是對(duì)于節(jié)點(diǎn)間擴(kuò)散傳輸鏈路的控制，目前為了方便在采用的是TCP，在同一數(shù)據(jù)中心內(nèi)進(jìn)行流擴(kuò)散問(wèn)題不大，在應(yīng)用到跨數(shù)據(jù)中心的部署場(chǎng)景中時(shí)，特別是tts和delay比較大的情況下，實(shí)際可用的throughput會(huì)受比較大的影響，目前仍有一些改進(jìn)的工作還在進(jìn)行當(dāng)中，我們也在調(diào)研SCTP和QUIC。

?

2.9 MSP - Underlying Transport Protocols(TCP vs.QUIC under weak network)

我們?cè)诠?jié)點(diǎn)間擴(kuò)散時(shí)加一些網(wǎng)損的情況下用TCP和QUIC有做過(guò)一些對(duì)比測(cè)試。QUIC和TCP都是可靠傳輸，在有網(wǎng)損的時(shí)候都會(huì)產(chǎn)生一些重傳或者是冗余，但是他們不同的擁塞控制策略會(huì)對(duì)端到端的媒體傳遞的質(zhì)量產(chǎn)生不同的影響。我們的對(duì)比測(cè)試中，發(fā)送端是以恒定的碼率和幀率（24fps）向服務(wù)器側(cè)發(fā)送視頻流，服務(wù)器側(cè)在節(jié)點(diǎn)間分別采用TCP和QUIC進(jìn)行節(jié)點(diǎn)間媒體流擴(kuò)散，圖中截取的是相同的網(wǎng)損條件下接收端收到的實(shí)際幀率，在5%的丟包和30ms delay時(shí)， TCP的幀率就會(huì)抖動(dòng)的非常厲害，在接收端體驗(yàn)就會(huì)看到點(diǎn)不流暢，能明顯地看到它的卡頓。當(dāng)加上10%的丟包時(shí)波動(dòng)就跟家劇烈，有時(shí)甚至降低到0fps，接收端的用戶體驗(yàn)就是非常明的卡頓。相比而言，在QUIC上面還能夠看到，接收端的幀率能夠更好地堅(jiān)持在24fps上下，接收端的流暢度更好。總體來(lái)看，QUIC是在弱網(wǎng)環(huán)境下進(jìn)行節(jié)點(diǎn)間流擴(kuò)散的一個(gè)不錯(cuò)的備選傳輸。

?

2.10 MSP - Media Control Primitives

媒體控制的操作對(duì)于媒體節(jié)點(diǎn)來(lái)說(shuō)，一個(gè)publish就是往媒體結(jié)點(diǎn)上面發(fā)布一路流，給它增加一個(gè)input，一個(gè)subscribe就是在它上面去增添一個(gè)output，linkup就是把一個(gè)input和output接續(xù)起來(lái)，cutoff就把一個(gè)input和一個(gè)output拆開(kāi)。對(duì)于媒體處理的結(jié)點(diǎn)有一些內(nèi)生的流，generate就是讓它產(chǎn)生一路流指定規(guī)格（codec、分辨率、幀率、碼率、關(guān)鍵幀間隔等），degenerate就是讓它取消正在生成中的一個(gè)流。

?

3.Cross DC Media Spread

3.1 Cross DC Media Spread:Relay Node (WIP)

做TCP和QUIC的對(duì)比調(diào)研目的就是解決跨數(shù)據(jù)中心通過(guò)Internet進(jìn)行節(jié)點(diǎn)間媒體流擴(kuò)散的實(shí)時(shí)性（本質(zhì)是throughput）問(wèn)題。由于在跨數(shù)據(jù)中心媒體擴(kuò)散的時(shí)候需要在Internet上面做流擴(kuò)散，Internet在傳輸質(zhì)量上講沒(méi)有在數(shù)據(jù)中心里的效果那么滿意，需要找一些基于UDP改進(jìn)的可靠傳輸協(xié)議去嘗試，我們調(diào)研過(guò)SCTP和QUIC，總體來(lái)看QUIC的表現(xiàn)是相當(dāng)不錯(cuò)的。

同時(shí)為了減少同一條流在兩個(gè)數(shù)據(jù)中心的多個(gè)節(jié)點(diǎn)間傳輸，我們?cè)黾恿艘粋€(gè)Relay Agent（Node）的部件，使得同一條流在兩個(gè)數(shù)據(jù)中心之間只需要擴(kuò)散一次。Relay Agent的另一個(gè)作用是進(jìn)行流擴(kuò)散的時(shí)候的路由控制，譬如一個(gè)集團(tuán)公司的很多分支機(jī)房并不是BGP的，需要將流匯聚到指定的BGP機(jī)房才能更好地向其他地區(qū)數(shù)據(jù)中心擴(kuò)散。

?

3.2 Access Node(Agent) Scheduling

在部署了多個(gè)接入節(jié)點(diǎn)以后，除了通過(guò)增加接入節(jié)點(diǎn)來(lái)擴(kuò)充系統(tǒng)的scalability，我們還希望能夠利用接入節(jié)點(diǎn)的不同地理位置給靠近它的終端用戶做就近接入。以WebRTC Agent為例，在部署WebRTC Agent的時(shí)候可以指定它的capacity（能力），capacity上面有兩個(gè)標(biāo)簽，一個(gè)是isp，一個(gè)是region。用戶在進(jìn)行通信連接請(qǐng)求的時(shí)候，它帶上isp和region的preference（喜好），系統(tǒng)在進(jìn)行WebRTC Agent調(diào)度的時(shí)候會(huì)對(duì)所有可用的WebRTC Agent的capacity與用戶指定的preference進(jìn)行匹配，找到最滿意的接入結(jié)點(diǎn)，最后達(dá)到就近接入的目的。

在符合preference的候選不止一個(gè)時(shí)，系統(tǒng)還提供基于work load和歷史使用記錄進(jìn)行l(wèi)ast-used、least-used、round-robin、random等調(diào)度策略，選取符合指定策略的接入節(jié)點(diǎn)。

?

3.3 CDN alike Service

解決了跨數(shù)據(jù)中心部署的媒體流擴(kuò)散和調(diào)度問(wèn)題后，我們的解決方案就可以提供更廣闊的實(shí)時(shí)多方音視頻通信服務(wù)。特別是有了Relay Agent的級(jí)聯(lián)能力后，我們服務(wù)器側(cè)系統(tǒng)就可以得到極大的提升，譬如假設(shè)單個(gè)媒體接入節(jié)點(diǎn)的扇出能力是1:1000的話，經(jīng)過(guò)一級(jí)級(jí)聯(lián)后就能達(dá)到1:100萬(wàn)，經(jīng)過(guò)兩級(jí)級(jí)聯(lián)后就能達(dá)到1:10億，已經(jīng)堪比一般CDN的扇出能力了。而CDN的就是本質(zhì)是一個(gè)分布式的cache系統(tǒng)，cache是實(shí)時(shí)應(yīng)用的天敵。許多既要求海量扇出比，又要求實(shí)時(shí)性，并且要隨時(shí)平滑進(jìn)行流拓?fù)淝袚Q的場(chǎng)景下，CDN就顯得無(wú)能為力了，而我們的解決方案將覆蓋這些場(chǎng)景，特別是在5G和IoT的時(shí)代。

LiveVideoStack? 招募

LiveVideoStack正在招募編輯/記者/運(yùn)營(yíng)，與全球頂尖多媒體技術(shù)專家和LiveVideoStack年輕的伙伴一起，推動(dòng)多媒體技術(shù)生態(tài)發(fā)展。同時(shí)，也歡迎你利用業(yè)余時(shí)間、遠(yuǎn)程參與內(nèi)容生產(chǎn)。了解崗位信息請(qǐng)?jiān)贐OSS直聘上搜索“LiveVideoStack”，或通過(guò)微信“Tony_Bao_”與主編包研交流。

LiveVideoStackCon 2019北京 音視頻技術(shù)大會(huì) 初版日程現(xiàn)已上線，掃描圖中二維碼或點(diǎn)擊【閱讀原文】了解大會(huì)最新日程。

總結(jié)

以上是生活随笔為你收集整理的如何构建分布式SFU/MCU媒体服务器？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。