幾年前，很多人對線上網課還非常陌生。隨著移動裝置的普及和音視訊技術的發展，如今線上教育產品百花齊放。而線上教育產品能服務千萬學子離不開流媒體分發技術的支撐。本次LiveVideoStackCon
2021 音視訊技術大會北京站邀請到了網易有道研發工程師周曉天，為我們分享網易有道線上教育業務的流媒體分發相關內容。
文 | 周曉天
整理 | LiveVideoStack
大家好，我來自網易有道精品課研發團隊。如今音視訊被各界廣泛關注，“直播+”成為一個熱點，大廠也紛紛推出了一系列音視訊的相關服務。
網易有道是一家以成就學習者“高效學習”為使命的智慧學習公司，依託強大的網際網路AI等技術手段，圍繞學習場景，打造了一系列深受使用者喜歡的學習產品和服務。除了面向多種場景的線上教育平臺，還有有道詞典、有道詞典筆等領先市場的軟硬體學習工具。
其中線上教育業務就是依託音視訊技術的不斷成熟應運而生的一項重要業務。
音視訊技術內容廣、鏈條長、每個點又會很深。所以今天分享的內容以有道的線上教育業務為主題，聚焦在有道團隊流媒體分發服務端的部分。
今天的內容分為三個部分，分別是有道線上教育業務介紹、分發系統架構的演進和對分發難點的思考與實踐。
1.線上教育業務介紹
首先通過線上教育直播業務形態理解需求，明確媒體分發服務端要考慮什麼。
不同班型對應著不同需求。2013年左右最先出現的是1V1課程、普通小班課。本質上是藉助RTC實時通訊模式構建的教育產品。後來遊戲直播和娛樂直播被大家熟悉，而這個階段被熟知的線上學習的主要形式是視訊點播模式，比如網易公開課。隨著音視訊領域技術成熟，以及使用者對線上教育需求的升級，直播網課迅速發展。直播課大約出現在2014年，在疫情後得到了空前的關注。
傳統大班直播課是老師的單向推流，在互動大班課中，學生可以和老師進一步互動，獲得更好的上課體驗。學生連麥、螢幕/白板、老師視訊和互動訊息構成一節課的主要內容。
互動小班進一步優化產品的互動性，提升學員課堂參與感、學習體驗與學習效果。音視訊+H5互動元件+靈活的佈局需求也帶來額外複雜性。
面向業務設計服務，需要理解不同業務的差異再去採取相應的技術。這裡提供一種思考的方式：以互動大班課為例，一個老師和一個學生正在連麥，再將連麥的過程分發給其他學生。對於流媒體分發，右側列出一些考慮的要素：需要什麼程度的延遲和流暢性？多大的規模？需要多高的媒體質量？當前業務線對方案成本的敏感度？
進一步可以用這種方式橫向對比不同課程形態，通過它們的區別獲得更精細的需求。
比如，對比大班直播課和互動大班課：對於規模為M的會話，大班直播課要把一個人的資訊分發給M-1個人，這可以通過基於CDN的視訊直播方式做到。如果進一步想要給產品增增加連麥互動性，成為互動大班課。連麥的增加會讓簡化模型變為兩個部分，如何在一個教室內同時滿足這兩個需求？最簡單的思路是在原有CDN分發的基礎上，讓連麥內容通過RTC方式交換，再將它們的資訊通過原有CDN系統分發，但這麼做會帶來內容延遲和使用者切換延遲等問題。
對比互動大班和（線上、線下）雙師班級，雖然模型類似，但具體到場景中雙師班級中的一個“學生端”可能對應一個線下教室的全體學生，這會增加單路分發異常的代價，這樣的差異也就要求系統能對不同場景配置不同策略。
除了線上教育，橫向對比的思路同樣可以用來分析其他場景的業務線，例如普通小班和遊戲開黑。開黑看似和只傳送語音的普通小班課程類似，但是在效能和網路佔用方面要求更嚴格。在儘量不佔用遊戲頻寬的同時，還需要儘量減少CPU的操作，為遊戲提供充足的算力。如果直接用小班課程的RTC介面用於遊戲，保證通話質量的同時反而會影響遊戲。如果期望使用一套系統支援多種業務，那麼在系統設計早期就要明確業務差異和設計需求。
通過以上的分析，可以列出了線上教育業務對媒體分發系統的一些主要需求點。第一要滿足分發低延遲、上麥低延遲。第二點要做大規模分發。相對一些娛樂場景，要做到高穩定以及高可用。第四點要對成本進行控制。最後，不同學生、不同教室對於上課場景的需求是不同的，所以一定要支援多端接入。
2.分發架構的演進
當多個業務線同時鋪開的過程中，從1v1到小班、到大班直播、再到互動大班以及互動小班等課程，這會影響分發系統的演進過程。一種思路是隨著業務的演變，分發架構逐漸複雜，不斷支援越來越多的特性。有道並沒有採用該思路，而是經歷了從基於CDN的分發，到全部業務使用實時通訊網路（RTN）的切換，沒有架構上的中間過渡狀態。
下面我們簡單回顧一些分發架構作為普及內容。
基於CDN網路的直播內容分發的樹狀架構十分清晰，架構本身決定資料的路由，同時易於維護、風險和成本可控。當一個使用者選定一個邊緣接入，媒體資料的分發路由就已經規劃好了。同時它有自身的缺點，比如：只支援單向分發、協議帶來的固定延遲等。
早期通過CDN模式部署的直播為了增加互動性和降低延遲，在CDN架構的基礎上做了兩個優化。一方面在邊緣拉流節點支援RTC的方式接入（圖中也寫為RTN邊緣節點），從而遮蔽掉媒體封裝協議帶來的延遲、增加IM互動效果，同時還能增加弱網抗性。另一方面為了進一步增加互動性，增加了RTC旁路系統以支援雙向連麥，再將連麥內容轉推到CDN網路中完成直播。一些“低延時CDN直播”產品就採用這樣的原理。
剛剛提到用於連麥的旁路RTC系統需要轉推內容到CDN分發網路，那是否能讓這個系統把CDN大規模分發的任務也一起做了呢？於是就有了純RTN的架構。該架構不再有鮮明的樹狀分發結構，而是用一個網狀拓撲分發所有內容。任意單向拉流客戶端可以隨時切換為雙向通訊，不需要先做系統的切換。
通過上述的分析，我們可以大致總結出業內直播流媒體分發演進的方向——音視訊直播CDN和RTC網路邊界模糊，逐步融為一體。直播CDN廠商逐漸從單向大規模分發支援低延遲接入、連麥。之前的RTC產品，從面向小型會議的架構逐步為了能夠同時服務千人、萬人，也開始將分發網路變複雜。所以現在我們能看到網易的WE-CAN分散式傳輸網、阿里雲GRTN 流媒體匯流排、以及其它“X-RTN”都是該演進過程的結果。
剛剛提到的架構主要是ToB廠商的產品，在ToC服務的場景中也會有如上圖所示的架構，通過一個媒體伺服器融合兩個分發網路提供服務，特別是對於同時有自研和三方接入時。該結構在帶來新的非功能特性的同時，也有很大的風險。有道沒有選擇使用類似的架構進行過度，而是直接用RTN分發網路對原有功能進行替代。
該架構能滿足多種場景的需求，也支援多種推拉流客戶端接入。例如當同學上公開課時，通過微信小程式或者瀏覽器直接看是最為便捷的。已經使用課程APP、已經參加系列課程的使用者，使用APP接入以獲得最優體驗。
相比CDN架構自身的拓撲結構決定了資料分發路由，RTN網狀拓撲在帶來靈活性的同時也增加複雜性。比如路由無法從拓撲直接獲取，而是需要一個額外的排程中心去計算、規劃路由，完成對應轉發資源的排程，這也凸顯了RTN架構下排程中心的重要性。
圖中也有一個CDN旁路的部分，他的主要作用是做一些突發接入量過大的課程的負載均衡，增加系統的彈性。
有道在設計網路節點拓撲的時候更偏向於靈活性。一方面，分發節點沒有分層、分級，採用扁平拓撲。另一方面，通過配置不同的屬性、角色可以實現對網路分發特性的改變。
3.分發難點思考與實踐
對於流媒體分發系統有以下四個要點——接入問題、網路連通性、路由建立以及轉發。除此之外還想分享一下關於分層設計和通道的概念。
解決接入問題的核心理念是“就近”接入——網路質量最好的接入為“最近”的接入。（不同型別的業務可能會有不同思路：有道的教學場景中力求現有每個使用者體驗儘可能最優，類似於貪心演算法；但在別的業務中，思路可能會是在達到QoS最低限制的情況下選擇全域性成本最優的接入、路由方式）最直觀的方法是使用基於IP、位置的接入推薦。進一步利用對不同閘道器網路探測、連線歷史資料優化推薦的結果。除了利用線上、線下資料統計獲得的先驗的知識進行接入推薦，考慮到這樣的方法無法涵蓋所有特殊形況，有道還引入人工配置的支援。支援手工熱配對部分ToC場景非常有效
右下角是一個大班課老師上行丟包率打點圖，可以看到存在有規律的、平均在9%左右的丟包。該老師長期在固定地點使用固定裝置進行直播，而且早期還有技術支援同學進行過網路檢查，網路一直很好。按照之前的演算法，他的位置沒有變、網路沒有變，使用的推薦資料庫也變化不大，所以根據演算法每次會給出相同的推薦結果。突然出現的有規律丟包推測是流量行為被運營商識別、分類，並對其進行了策略限制。
面對這種情況，修改演算法是行不通的。通過有道熱配置的方式，在發現問題進行上報的同時就可以人工修改配置，下一次老師接入會避開對應接入節點，解決丟包問題。
我們通過“過濾器”機制實現該操作：假如所有可接入節點構成一個池子，那麼最終“過濾”出的結果構成推薦給客戶端進行接入的列表。所以把過濾規則的計算過程作為演算法寫入系統，將演算法執行要使用的引數作為可以熱更新的資料寫在資料庫來實現。
接入只解決了分發網路的入口問題，那麼分發網路究竟是怎樣的拓撲形態呢？這就涉及到網路節點的連通性設計問題。有道的網路是一個扁平的拓撲，每個機房都是拓撲中扁平的點。理論上可以給所有節點之間都建立連線，成為一個mesh網路，那麼這樣的網路將會無比靈活，任意一條通路都可以被規劃出來，完全依賴演算法進行實際路由的選擇。有道並沒有採用這樣的方式。
我們還是引入了一些人工經驗，比如根據經驗將一些機房的連通性刪除，成為非Full mesh的結構。可以認為是藉助人工的方式進行了剪枝、組織。除了連通性，在路由計算時還需要解決權重的獲取問題，也就需要對節點連線情況差異進行量化描述。這種量化是基於規律性的QoS探測完成的，類似前面接入選擇的問題，演算法可能沒法精細地滿足所有case或者一些特殊情況，那麼在量化差異外，我們也通過可配置的屬性描述定性的差異來增加拓撲的靈活性。
之所以這樣提高靈活性、支援人工配置，是為了能滿足不同業務的差異化需求。同時也有代價，就是複雜性的提高。所以或許沒有最好的架構，只有更合適的架構。
在確定了接入位置（明確了分發的起點和終點）、建立了分發網路的連通性後，要解決的就是路由規劃或者說排程問題。這裡可以為大家分享的實踐和思考有三點：一條路由的規劃、多路徑還有成本控制。規劃單條路由是完成資料分發的基礎，我們根據動態探測、重新整理的網路QoS量化質量和基於當前節點狀況、節點配置共同完成路由權重的計算。有了無向帶權圖、有了終點和起點，就可以計規劃一條最短分發路由。
解決了接入問題，又完成分發網路連通性定義，現在解決了媒體資料分發路由的規劃，看似就可以完成分發任務了。但對於有道的業務要求這還不夠,想進一步保障使用者體驗就需要提升分發網路對抖動、丟包的抗性。多路徑分發是一種保障方式。有道分發網路有三種路徑——主要路徑、備選路徑、實時路徑。主要路徑直接用於業務分發；備選路徑是主要路徑的備份，在規劃主要路徑時生成，當主要路徑異常時切換。實時路徑是在主要路徑之外額外建立的多路冗餘分發路徑，以提供更加強大的分發抖動、丟包抗性，這對一些重點任務、大規模分發任務有很高價值。
以圖上橙色線路為例。邊緣是移動、聯通和電信三個單線機房，除了主路徑之外，可以在兩個邊緣的聯通運營商之間建立實時路徑，在實現實時備份的情況下降低備份線路成本。
控制中心完成資料分發路徑的規劃後，就需要沿途節點執行轉發任務。這涉及到高效能流媒體分發伺服器的設計。上圖顯示了有道的轉發伺服器執行緒模型。協議、埠對應不同的執行緒，從而在有限埠情況下儘可能利用多核資源。
除了每個協議-埠對會繫結一個IO執行緒，還有一個core執行緒，完成來自不同接入的資料包路由。比如一個推流使用者從協議A埠A1接入（如使用UDP，從3000埠推流），同會話另一個拉流使用者採用協議B埠B1接入（如使用TCP，從4000埠拉流），這兩個使用者根據IO執行緒模型不可能分配到同一個執行緒，所以需要進行跨執行緒資料轉發。此時core執行緒會根據會話釋出訂閱的關係，將接收佇列的內容向對應IO執行緒的佇列進行轉發。
該執行緒模型的設計和業務型別、比例也是相關的。當時系統負載以大班課為主，即推流人數大大小於拉流人數。如果業務型別發生變化，例如班型越來越小、課程每個成員都進行推流，而伺服器總使用者量如果不變，這會讓core執行緒的轉發負載相對大班課大大增加。這也是小班課業務帶來的一項挑戰，需要架構能隨業務變化靈活應對。
除了上面四個關鍵問題外，借本次機會想額外分享、探討兩個細節：分層設計和通道的概念。
分層設計相當於轉發問題的延伸。伺服器拿到來自一個連線的資料以後，通過core執行緒分發。邏輯結構上可以理解為三層：連結層解決不同協議連入的問題；路由層負責處理資料在內部的分發、轉移；會話層維護了釋出訂閱關係，指導路由進行分發，將資料發到正確的連線。該分層思想不僅用在單機執行緒模型中，也用在整個分發網路中。
當業務方接入一個實時通訊SDK時，關於“通道”不同ToB廠商會有不同定義，簡單理解就是對實時媒體傳輸資源的一種抽象。比如一些廠商所服務的業務場景的主要資料是人臉和螢幕共享，對應SDK可能就只提供兩個通道資源，其中人臉通道支援大小流的同時推送。
上圖以互動大班課為例介紹有道在“通道”設計方面的思考。左下角圖片展示了互動大班的典型教師上課效果：右上角是主講的老師，正在和左邊的學生進行連麥，那麼如何進一步把當前介面所有資訊傳遞給其它學生？有道實時通訊SDK提供了Live、RTC、Group等多個通道資源。SDK向外暴露的通道資源數量可以定義，同時可以差異化配置，雖然名字不同但是底層資源屬於同一類。一個通道對應一路同步的音視訊的分發能力。
仍以剛剛的場景為例：示意圖左側是教師，右側是學生。橙色是RTC通道，這部分完成老師和學生的連麥。隨後教師在端上進行混流——將連麥內容、課程白板等內容混為一路音視訊通過Live通道向其它聽課的學生髮送。比如可以通過獲取當前螢幕內容來做端上的混流。在互動大班型的業務場景下，所有學生需要獲得資訊都在這一張圖裡，都是視訊和音訊的媒體資訊，這樣就可以採取兩個通道組合的方式，一個連麥、一個直播，從而完成整個業務。
不同的通道之所以有不同的名字而不是使用一個通道物件陣列，是為了進一步降低客戶端接入門檻。比如Live通道概念上相比RTC更強調流暢性，這可以對應一個更大的視訊最小緩衝區來提升網路抖動抗性。
業務中發現SDK提供通道這種資源的方式可能會影響業務方的思考方式：如果只有“人臉通道”和“螢幕通道”，這可能會限制業務產品對新課程形式的思考。
4.互動小班課為例
借本次機會可以和大家分享有道關於互動小班的嘗試，在以下兩個方面和大家交流：小班的“互動”到底是怎樣的？以及互動課程的錄製問題。
在小班課中，多位學生和老師全程可以連麥。不同的同學可以隨時被拉到臺上進行分享、答題。除了音視訊、白板這些基本內容之外，我們還加入了一些互動元素：本地媒體元素播放、多人實時互動棋盤等。這樣的互動元素帶來什麼影響呢？
前面提到的互動大班課可以在端上混再傳送到Live通道，這樣流既可以省去需要單獨服務端混流帶來的視訊延遲和同步問題，同時完整地傳遞了所有課程資訊。但是對於互動小班課，如果老師端通過這種擷取螢幕將內容分發給其他學生的方式，就會丟失互動元素的可互動性、佈局也無法改變。當一個學生回頭看錄播的時候無法進行參與，只能作為旁觀者看到別的同學的互動過程。這也是互動小班課第一個難點——互動元素如何處理？如何進行錄製？回放的時候如何保持同步？實際中是有很多坑點和挑戰。
5.關於自研
最後想和大家探討一些關於自研實時通訊系統的問題。
這裡的部分內容擷取自 ToB 廠商對痛點的分析，自研所遇到的問題可以分為以下幾點：
- 成本：除了人力、資源覆蓋、動態擴縮容的運維等，還有與之對應的機會成本。前兩點都比較重要。另外不同業務頻寬峰值位置不同，複用一套基礎設施和頻寬資源可以降低資源、能源的消耗。
- 風險：比如上文提到用一套MCU結合兩套架構，可能會引入額外的風險。
- 邊界：比如是否加入特殊配置解決業務問題，團隊內做自研對於業務需求的邊界如何把握的問題？
- 系統優化門檻：當跑通上文提到的所有內容後，業務可以跑起來。但如果想要進一步壓縮成本，就需要對更深技術棧的理解，比如資料驅動的全鏈路傳輸優化，編解碼的優化，難度和所需的人力可能都會更高。
但自研的優勢也是很明顯的：
- 對音視訊基建的理解：音視訊逐步成為一種基建，但如果團隊只通過三方SDK的方式接入音視訊能力可能無法深刻理解音視訊技術的難點、無法正確評估風險、無法把握潛在的機會。
- 更多原子能力：自研技術可以根據複雜的業務需要按照業務線進行更靈活的配置，用合理的方式暴露更深的介面，這會讓業務層獲得更大的靈活性。
- 對產品、研發、技術支援提供幫助：音視訊技術涉及廣泛且複雜，讓客戶端研發同學、技術支援同學對業務出現的異常準確排錯、根據埋點資料分析問題原因是很困難的。依賴音視訊自研團隊對業務中遇到的問題進行積累、理解更深層的原因、排查未來可能出現的隱患是一種行之有效的方法。通過音視訊自研團隊可以輔助產品進行設計、加速研發對音視訊技術的落地，還能輔助技術支援在業務中確定使用者問題原因、提早發現更深的隱患。畢竟再快的工單系統可能也無法比隔壁工位的支援來的更快。
- 成本控制、面向業務優化：當能操控的技術越底層，針對特定業務能做的優化空間也就越大，進一步優化體驗的同時也有更多成本壓縮的空間。
感謝閱讀，以上是本次的分享內容，謝謝！