在互聯(lián)網(wǎng)云時代的今天，實時音視頻的各種計算也在向云端發(fā)展,由于音視頻的數(shù)據(jù)計算量巨大，加上移動、聯(lián)通、電信等運營商之間的互通問題,使得中心云端的計算壓力巨增，互通性的成本也隨之增加。為了最優(yōu)的解決這一矛盾，三體云在實踐中不斷的改進優(yōu)化，實現(xiàn)了一套充分利用邊緣云端分散計算的方式，很好的解決了這一矛盾。
大家好，我是來自三體云后端服務(wù)器的架構(gòu)師時杰，從事有關(guān)編解碼方面的工作。今天與大家分享的內(nèi)容是三體云服務(wù)器在音視頻合成的元邊緣計算方面的發(fā)展歷程。 之前我是從事廣電行業(yè)的，也從事跟音視頻網(wǎng)絡(luò)相關(guān)的工作，但模式跟現(xiàn)在是完全不同的，以前3G、4G初的階段面向的更多是廣電系列的電視臺、HTV之類的視頻，與現(xiàn)在實時互動視頻還是有一些差別的。
進入互聯(lián)網(wǎng)時代后，在實時通訊方面，不光終端是端對端的，有很多計算都要通過服務(wù)器進行一些混合運算。比如多個主播進行連麥的時候，他們的音視頻要進行合并后傳遞給觀眾，他們所看到的數(shù)據(jù)并不是直接從采集端發(fā)過來，而是要通過服務(wù)器進行各種加工、渲染，最后推到終端。問題是在所有的計算過程中服務(wù)器的結(jié)構(gòu)過程會遇到各種的問題。今天跟大家分享的就是如何解決以及優(yōu)化遇到的問題，并介紹一下三體云在其中是如何做的。
這次演講的內(nèi)容主要分為四部分:第一是音視頻合成的相關(guān)的一些解釋，為后面做云端分散計算進行鋪墊;第二是音視頻合成整鏈路的基本結(jié)構(gòu);第三是音視頻合成計算的發(fā)展歷程;最后是三體云在國內(nèi)、國外一些案例的結(jié)構(gòu)模型。
1. 音視頻合成的相關(guān)解釋
1.1 音頻合成
音視頻合成從文字上解釋就是將發(fā)言者的聲音通過混音器合成之后再輸出的過程，也稱之為混音。合成器可以是硬件也可以是軟件，在服務(wù)器結(jié)構(gòu)里不強調(diào)什么是硬件和軟件的。這張圖就很好的詮釋了音頻合成的一個過程，圖中有四個音頻輸入，經(jīng)過服務(wù)器進行合成后輸出到混音，這是音頻合成的一個簡單的模型。
1.2 視頻合成
視頻合成是將所有連麥者的視頻畫面通過采集編碼后 通過服務(wù)器解碼進行混合，根據(jù)指定的布局或者樣式進行布局，合成之后再推到觀眾端。這張圖就是一個簡單的模型，所有的主播或者終端客戶，他們采集自己的視頻到服務(wù)器進行一個合成，再推到觀眾端。這兩個點服務(wù)器都有在進行大量的音頻或者視頻數(shù)據(jù)計算，我們需要做到將這些大量且復(fù)雜的運算進行邊緣化。
1.3 節(jié)點類型
音視頻合成鏈路基本結(jié)構(gòu)里涉及到一些圖形節(jié)點，一種是客戶端，像手機、平板之類的電子產(chǎn)品通過采集或者聲音的捕捉都是可以的。另一種節(jié)點類型模式是SFU，它只負責(zé)一種點對點的轉(zhuǎn)發(fā)傳輸。最后一種節(jié)點類型是MCU，它是一個真正的核心運算終端，是一個多點控制單元，將所有終端上傳的數(shù)據(jù)進行正常的分發(fā)以及合成。 其次，服務(wù)器所屬機房分為單線和多線，就是某一個服務(wù)器在云端的部署時，它具有運營商的特性。比如舉國內(nèi)的一個例子來說，單線的指針可以是聯(lián)通的或者是移動的，如果一個客戶端本身是非聯(lián)通、非移動，而是電信的，那這時就需要一個多線，它支持所有運營商的接入，這就區(qū)分了兩種服務(wù)器的接入方式。
2. 音視頻合成鏈路基本結(jié)構(gòu)
2.1 SFU模型
下面介紹這種接入方式在服務(wù)器結(jié)構(gòu)部署上的優(yōu)勢以及劣勢，這張圖是解釋SFU的一種模型圖，它是所有的終端進行SFU服務(wù)器的轉(zhuǎn)發(fā)傳輸，并且是單進單出的一個模型。
2.2 MCU模型
下面介紹這種接入方式在服務(wù)器結(jié)構(gòu)部署上的優(yōu)勢以及劣勢，這張圖是解釋SFU的一種模型圖，它是所有的終端進行SFU服務(wù)器的轉(zhuǎn)發(fā)傳輸，并且是單進單出的一個模型。
2.3 單線模型
這個模型表示了一個簡單的單線，這里以聯(lián)通為例，如果左邊用戶是聯(lián)通，只能接受一個單線服務(wù)器，那么右邊的出口也只能和聯(lián)通的另一個終端用戶進行連接。
2.4 多線模型
如果兩個用戶不是同一個運營商，就需要一個多線服務(wù)器進行連接，多線服務(wù)器是不需要識別具體的運營商的，它的任何運營商都有接口接入的，而且它的出口也是多點的，這樣所有的終端用戶都會連到一起，并且暢通無阻。但問題是成本太高。對此的解決方案是用一個單線服務(wù)器，讓它去承載三線所帶來昂貴費用的功能點，然后分散到單線上，這也是我們這次內(nèi)容的關(guān)鍵和中心。
2.5 節(jié)點之間的關(guān)系
節(jié)點之間的關(guān)系主要有兩點：
- 一是所有節(jié)點之間都有網(wǎng)絡(luò)鏈路連接傳輸;
- 二是節(jié)點之間以多媒體流處理和轉(zhuǎn)發(fā)為主要功能。
3. 音視頻合成計算的發(fā)展歷程
3.1 音視頻合成計算的第一階段
這張圖就是音視頻合成的第一階段模型，在2017年三體云成立之初，服務(wù)器結(jié)構(gòu)全部都是以這種方式進行接入的。 這里列舉一個簡單的點對點、一對一的圖，當(dāng)然在現(xiàn)實的服務(wù)器中不是一對一的，而是非常多的。圖中的橢圓形表示一個多線的服務(wù)器。圖中的方形表示一個單線的服務(wù)器。服務(wù)器所具備的功能是圖中所標識的SFU和MCU，通過前面概念的講解，可知SFU是用來傳輸?shù)模皇怯脕磉\算的，而MCU不僅僅用來傳輸，里面還摻雜各種的混合運算。圖中左邊黃色的client1以及右邊綠色的client2，它們在進行連麥時，各自有各自所對應(yīng)的多線的服務(wù)器進行連接。這個時候就不去具體區(qū)分client1和client2是哪一個運營商，它們在接入服務(wù)器之后就可以暢通無阻的進行接通了。這種模型看似沒問題，也解決了實際問題，使得client1和client2可以暢通地進行連麥通話，但問題是圖中紅色部分其實是在負載，計算client1和client2上所有數(shù)據(jù)的混合運算，所以圖中紅色標記都是運算的標記。圖中所有的服務(wù)器都是一個多線服務(wù)器，所以在線上很多的服務(wù)器的結(jié)構(gòu)是非常簡單的。但問題還是過高的成本。
3.1.1 第一階段的簡介
中心計算節(jié)點都是多線IDC機房的(MCU)服務(wù)器，實現(xiàn)所有運營商之間的通訊，簡單易實現(xiàn)這是它的一個特點。但問題是它的壓力大，成本高，因為它是多線，就意味著所有的client都會去連接它，我們在做中心運算的時候是一個服務(wù)器在進行，不可能每一個服務(wù)器都在進行運算，因為要有一個數(shù)據(jù)的匯聚，這就是第一階段的一個模式。還有一個問題就是計算和轉(zhuǎn)發(fā)沒有分離出來。圖中所有多線服務(wù)器的SFU和MCU都在一起，沒有分離出來，這就造成后面要提到一個問題。下面這個模型就是client1通過SFU和MCU多線，將剛才的圖形模型以這種方式描述出來。
3.2 音視頻合成計算的第二階段
通過第一階段后來看一下發(fā)展的第二個歷程。在音視頻合成的第二階段，就只有一個三線服務(wù)器了，而且是紅色的標識，它是參與中心計算的。左邊方塊的SFU和右邊方塊的SFU，僅僅是用來進行client1和client2的用戶上行的接入轉(zhuǎn)發(fā)的。如果client1是聯(lián)通，client2是移動，那么它們所對應(yīng)的圖中黃色的單線服務(wù)器就是聯(lián)通，綠色的SFU就是移動，所以它們匯聚時通過中心MCU是可以接入的，這就將一個多線的服務(wù)器變成兩個不需要運算的、低成本的單線服務(wù)器接入了。
3.2.1音視頻合成計算第二階段的簡介
這樣一種進化，使它的計算壓力并沒有得到緩解，但是它的結(jié)構(gòu)發(fā)生變化可以部署更多的SFU邊緣計算機。所以它的特點就是以中心計算為主，以邊緣為輔，因為邊緣已經(jīng)被慢慢地剝離出來，這樣做就減少了多線服務(wù)器的壓力，這種壓力的減少更多的是在傳輸上進行了減壓，但是在運算上還沒有得減壓，所以剛剛提出的問題還沒有被解決。將上行分散到單線服務(wù)器，剛才第二階段的上行全部都是單線服務(wù)器了，特點是這樣的軟件結(jié)構(gòu)比第一階段復(fù)雜，因為要實現(xiàn)SFU在傳輸過程中找到對應(yīng)的三線服務(wù)器，而且需要更多的SFU服務(wù)器。還有一個特點就是計算和轉(zhuǎn)發(fā)是分開的，但問題還是中心計算問題并沒有得到實質(zhì)性的解決，只是把轉(zhuǎn)發(fā)的這一部分功能從多線服務(wù)器剝離了出來，但是計算還停留在第一階段的結(jié)構(gòu)上。
3.3 音視頻合成計算的第三階段
接下來是第三階段的進化，這也是我們目前三體云線上所部署的正在使用的一種場景。這種階段不是最終的目標，但就目前而言是比較優(yōu)化的。 圖中可以看到client1和client2，它們各自接入自己的單線服務(wù)器上行，比如client1是上海，client2是北京，它們會找最近的SFU服務(wù)器以及對應(yīng)的運營商，同理client2也會在上海找對應(yīng)的這個SFU服務(wù)器以及相對應(yīng)的運營商，并把數(shù)據(jù)傳輸?shù)綄?yīng)的MCU服務(wù)器。問題是圖中紅色的MCU，方塊MCU代表的是一個單線。在第三階段，我們已經(jīng)把計算的方式開始邊緣化，已經(jīng)分配到它所對應(yīng)的單線的MCU服務(wù)器上了，還要保證client1和client2暢通無阻的連接，所以還需要圖中右邊橢圓形的多線服務(wù)器去進行匯聚連接，這就很好地把中心計算剝離出來并將其分散到單線MCU。但并不是右邊的SFU跟MCU多線服務(wù)器不進行計算了，而是中心服務(wù)器的運算量在減少，這只是一個client1和client2簡單的連麥模型。而線上是一個網(wǎng)狀、樹狀的結(jié)構(gòu)，它的連接關(guān)系是非常的復(fù)雜的，這里SFU和MCU多線服務(wù)器起到了多運營連接跳轉(zhuǎn)的作用，所以SFU和MCU中心節(jié)點還是不能省的，但是它們在client1和client2連接過程的模型中只做了轉(zhuǎn)發(fā)，沒有做任何的運算，這就達到了音視頻計算邊緣化的目的。
3.3.1音視頻合成計算的第三階段的簡介
第三階段就是分散到邊緣，減少多線服務(wù)器的壓力，所有的單線服務(wù)器都是參與計算的。但特點是軟件實現(xiàn)復(fù)雜，即通過我們的設(shè)計結(jié)構(gòu)以及框架去改變之前的中心節(jié)點計算下壓力大的問題，就是把它的復(fù)雜度通過軟件的實現(xiàn)達到減少壓力，減少成本，減少多節(jié)點服務(wù)器的目的，這樣每一個服務(wù)器都參與了計算，并且SFU和MCU的軟件部署是可分可合的，這也使得部署過程非常靈活。 模型中的SFU單線到MCU單線，在實際的生產(chǎn)過程中，為了節(jié)約帶寬成本，圖中左邊紅色單線中心計算服務(wù)器MCU和黃色的SFU(大概率)在同一臺服務(wù)器，可以節(jié)省左邊黃色的SFU到MCU之間帶寬的費用，因為兩者都是單線，能夠連接說明它們具有相同的運營商屬性，所以把它們部署到一塊，可以節(jié)省兩者之間的通信帶寬的費用。 其次，邊緣計算還帶來另一個節(jié)約成本的作用，在第一階段，每一個三線中心服務(wù)器在做運算的時候，它匯聚所有的客戶端傳來的數(shù)據(jù)時，勢必會增加寬帶的壓力，就意味著服務(wù)器所承載的95峰值計算的峰值達到很高，不利于成本的節(jié)約。相反，單線服務(wù)器承載運算之后，每一個點都在運算，它所承擔(dān)的數(shù)據(jù)匯聚就把之前的中心節(jié)點分散出來，使得95峰值的帶寬降下來，進而節(jié)約了帶寬的成本，這就是邊緣計算帶來的成本上的節(jié)約。 圖中SFU和MCU左邊紅色標識，它們在一個服務(wù)器上，就使得它們的帶寬得到節(jié)省，傳輸距離也縮短了，短距離的網(wǎng)絡(luò)傳輸使得延遲變短，傳輸更加流暢，卡頓率降低，這方面就得到進一步的優(yōu)化。以前的方式，中心量大，CPU的總線以及帶寬的總線都達到了極致，就會造成卡頓，并非是距離上的，而是負載上的，負載太高就會造成卡頓，也更容易丟包，所以把這些問題分散就能解決了。
4. 三體云的國內(nèi)、國外案例模型
4.1 三體云的國內(nèi)案例模型
這部分是三體云在目前服務(wù)器部署上的一個簡單拓撲。是前面所講的client1和client2稍微復(fù)雜的一種拓撲圖，所有的client對應(yīng)的是單線的SFU，都有各自的運營商。 這張圖是一個國內(nèi)的例子，表示一個房間里的連麥，在這個連麥的過程中，所有用戶在一個房間內(nèi)進行連麥只使用一個多線服務(wù)器，并且大量使用單線邊緣的服務(wù)器。圖中紅色標識承載了房間內(nèi)所有用戶的混流的合成運算。從業(yè)務(wù)上講，圖中C1、C2可能是主播，由它發(fā)起創(chuàng)建一個房間，所以離它們的計算服務(wù)器最近，其他與之連麥的主播通過它們各自的SFU和MCU進行轉(zhuǎn)發(fā)，匯聚到主播所在的SFU多線服務(wù)器，最后再匯聚到SFU紅色的方塊內(nèi)進行混合運算�；旌线\算以后就推給它所在的粉絲或者是觀眾。
4.2 三體云的國外案例模型
國外看似跟國內(nèi)沒什么區(qū)別，圖中展示也只是圖形發(fā)生變化，在國外沒有單線服務(wù)器的概念，所有的服務(wù)器都是多線的，可以隨意的聯(lián)通，但計算的點還在主播端。 在實際的生產(chǎn)過程中，有一個案例，在印度有一部分人在房間內(nèi)做交互，如中間這張圖，他們視頻連完之后，計算就在他們的計算范圍內(nèi)。如果會議需要一部分印尼人參加，需要把印尼的數(shù)據(jù)直接傳輸?shù)接《人诜块g的MCU中心計算服務(wù)器上。先將印尼的數(shù)據(jù)進行收集，通過離得最近的SFU服務(wù)器匯聚到他們所在的SFU、MCU多線服務(wù)器，匯聚完之后把他們的數(shù)據(jù)統(tǒng)一匯聚到印度MCU中心計算服務(wù)器上，最后再輸出。同理，左邊的迪拜，可能人數(shù)更少，也是按這樣一個過程進行。 這種方式的好處是不需要把每一個人單獨通過他們的單線去連接到印度，而是在印尼做一個小范圍的匯聚，然后再全部匯集到一起。好處是比如圖中綠色和紅色的橢圓的中間的連線出現(xiàn)了問題，因為跨國的帶寬費用高，保證性也比較差，萬一出現(xiàn)了中斷，至少印尼里C3、C40、C41三個用戶所組成的結(jié)構(gòu)是可以互通的，互通完后網(wǎng)絡(luò)有可能變好或者恢復(fù)，所以這是一個樹狀的結(jié)構(gòu)，保證小局域范圍內(nèi)的安全性。
4.3 三體云的國內(nèi)、國外案例模型對比
將國內(nèi)和國外的兩個案例模型做一個比較，國內(nèi)和國外的網(wǎng)絡(luò)運營方式不同。國內(nèi)多運營商，互通性是有問題的，我們的聯(lián)通、移動是不通的。這種跨運營商之間的互通的中斷，很容易造成三線節(jié)點增多，帶來的不確定的因素就越多，就增加卡頓以及掉線率。所以如果用單線和用一個多線服務(wù)器技術(shù)進行中轉(zhuǎn)的話，因為多線節(jié)點變少了，效果就會好很多。 而國外是沒有單線這樣的問題的，全部都是多線，所以邊緣節(jié)點可以任意選取，如果用戶發(fā)起一個房間的連麥，那么他所在的多線邊緣節(jié)點就參與計算，以及區(qū)域內(nèi)的保障和區(qū)域之間互通的特點。
4.4 三體云邊緣計算
從2017年經(jīng)過這樣一個優(yōu)化過程到現(xiàn)在，得到了如下一些成果，首先因為單線多了，部署節(jié)點就更多，這就意味著所有的客戶端在連接各自的服務(wù)器時就更近、更容易，那丟包和卡頓就會很少，像前面講的峰值、帶寬的成本也會下降。所以服務(wù)器越多，節(jié)點邊緣越多，它的覆蓋用戶越多，貸款成本、核心負載下降，這就達到了我們讓所有線上的服務(wù)器都運轉(zhuǎn)起來、都參與計算的預(yù)期效果。
5. 總結(jié)
總的來說，三體云在去中心充分利用邊緣云端分散計算的方式使服務(wù)器資源得到最大限度的利用。相比之前的方式，大大降低了服務(wù)器成本，因為單線服務(wù)器成本幾乎等于多線服務(wù)器成本的三分之一，甚至更低。雖然服務(wù)器的成本下降，但邊緣計算還將持續(xù)優(yōu)化下去。雖然這種部署是每一個邊緣節(jié)點都參與了計算，但并不是每一個都參與計算才是最好的，往往要根據(jù)流量，包括成本控制去計算，比如兩個人都在上海，各自上行對應(yīng)各自的服務(wù)器，如果把他們兩個上行的用戶都通到一個服務(wù)器上，那另一個服務(wù)器目前就空出來了，但是這并不能給服務(wù)器的帶寬帶來質(zhì)的飛躍，并不影響它的計費，這種情況下服務(wù)器就可以省出來并用來做其他事情，這也是一種優(yōu)化。所以我們的優(yōu)化方案需要不斷地調(diào)整，也希望大家在這次的分享中得到一些啟發(fā)。
