音影片合成的雲邊緣計算實現
- 2020 年 2 月 19 日
- 筆記
Photo by Dids from Pexels
在互聯網雲時代的今天，實時音影片的各種計算也在向雲端發展,由於音影片的數據計算量巨大，加上移動、聯通、電信等運營商之間的互通問題,使得中心雲端的計算壓力巨增，互通性的成本也隨之增加。為了最優的解決這一矛盾，三體雲在實踐中不斷的改進優化，實現了一套充分利用邊緣雲端分散計算的方式，很好的解決了這一矛盾。
文 / 時傑
整理 / LiveVideoStack
大家好，我是來自三體雲後端伺服器的架構師時傑，從事有關編解碼方面的工作。今天與大家分享的內容是三體雲伺服器在音影片合成的元邊緣計算方面的發展歷程。
之前我是從事廣電行業的，也從事跟音影片網路相關的工作，但模式跟現在是完全不同的，以前3G、4G初的階段面向的更多是廣電系列的電視台、HTV之類的影片，與現在實時互動影片還是有一些差別的。
進入互聯網時代後，在實時通訊方面，不光終端是端對端的，有很多計算都要通過伺服器進行一些混合運算。比如多個主播進行連麥的時候，他們的音影片要進行合併後傳遞給觀眾，他們所看到的數據並不是直接從採集端發過來，而是要通過伺服器進行各種加工、渲染，最後推到終端。問題是在所有的計算過程中伺服器的結構過程會遇到各種的問題。今天跟大家分享的就是如何解決以及優化遇到的問題，並介紹一下三體雲在其中是如何做的。
這次演講的內容主要分為四部分:第一是音影片合成的相關的一些解釋，為後面做雲端分散計算進行鋪墊；第二是音影片合成整鏈路的基本結構；第三是音影片合成計算的發展歷程；最後是三體雲在中國、國外一些案例的結構模型。
1. 音影片合成的相關解釋
1.1 音頻合成
音影片合成從文字上解釋就是將發言者的聲音通過混音器合成之後再輸出的過程，也稱之為混音。合成器可以是硬體也可以是軟體，在伺服器結構里不強調什麼是硬體和軟體的。這張圖就很好的詮釋了音頻合成的一個過程，圖中有四個音頻輸入，經過伺服器進行合成後輸出到混音，這是音頻合成的一個簡單的模型。
1.2 影片合成
影片合成是將所有連麥者的影片畫面通過採集編碼後 通過伺服器解碼進行混合，根據指定的布局或者樣式進行布局，合成之後再推到觀眾端。這張圖就是一個簡單的模型，所有的主播或者終端客戶，他們採集自己的影片到伺服器進行一個合成，再推到觀眾端。這兩個點伺服器都有在進行大量的音頻或者影片數據計算，我們需要做到將這些大量且複雜的運算進行邊緣化。
1.3 節點類型
音影片合成鏈路基本結構里涉及到一些圖形節點，一種是客戶端，像手機、平板之類的電子產品通過採集或者聲音的捕捉都是可以的。另一種節點類型模式是SFU，它只負責一種點對點的轉發傳輸。最後一種節點類型是MCU，它是一個真正的核心運算終端，是一個多點控制單元，將所有終端上傳的數據進行正常的分發以及合成。
其次，伺服器所屬機房分為單線和多線，就是某一個伺服器在雲端的部署時，它具有運營商的特性。比如舉中國的一個例子來說，單線的指針可以是聯通的或者是移動的，如果一個客戶端本身是非聯通、非移動，而是電信的，那這時就需要一個多線，它支援所有運營商的接入，這就區分了兩種伺服器的接入方式。
2. 音影片合成鏈路基本結構
2.1 SFU模型
下面介紹這種接入方式在伺服器結構部署上的優勢以及劣勢，這張圖是解釋SFU的一種模型圖，它是所有的終端進行SFU伺服器的轉發傳輸，並且是單進單出的一個模型。
2.2 MCU模型
這張圖是一個MCU模型，從圖形中看線條的數量可以了解，它可以接受所有終端伺服器傳輸過來的數據，在中間進行簡單的運算。
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. 總結
總的來說，三體雲在去中心充分利用邊緣雲端分散計算的方式使伺服器資源得到最大限度的利用。相比之前的方式，大大降低了伺服器成本，因為單線伺服器成本幾乎等於多線伺服器成本的三分之一，甚至更低。雖然伺服器的成本下降，但邊緣計算還將持續優化下去。雖然這種部署是每一個邊緣節點都參與了計算，但並不是每一個都參與計算才是最好的，往往要根據流量，包括成本控制去計算，比如兩個人都在上海，各自上行對應各自的伺服器，如果把他們兩個上行的用戶都通到一個伺服器上，那另一個伺服器目前就空出來了，但是這並不能給伺服器的頻寬帶來質的飛躍，並不影響它的計費，這種情況下伺服器就可以省出來並用來做其他事情，這也是一種優化。所以我們的優化方案需要不斷地調整，也希望大家在這次的分享中得到一些啟發。
