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