點擊上方“LiveVideoStack”關注我們

幾年前，很多人對在線網課還非常陌生。隨著移動設備的普及和音視頻技術的發展，如今在線教育產品百花齊放。而在線教育產品能服務千萬學子離不開流媒體分發技術的支撐。本次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的方式接入音視頻能力可能無法深刻理解音視頻技術的難點、無法正確評估風險、無法把握潛在的機會。

更多原子能力：自研技術可以根據復雜的業務需要按照業務線進行更靈活的配置，用合理的方式暴露更深的接口，這會讓業務層獲得更大的靈活性。

對產品、研發、技術支持提供幫助：音視頻技術涉及廣泛且復雜，讓客戶端研發同學、技術支持同學對業務出現的異常準確排錯、根據埋點數據分析問題原因是很困難的。依賴音視頻自研團隊對業務中遇到的問題進行積累、理解更深層的原因、排查未來可能出現的隱患是一種行之有效的方法。通過音視頻自研團隊可以輔助產品進行設計、加速研發對音視頻技術的落地，還能輔助技術支持在業務中確定用戶問題原因、提早發現更深的隱患。畢竟再快的工單系統可能也無法比隔壁工位的支持來的更快。

成本控制、面向業務優化：當能操控的技術越底層，針對特定業務能做的優化空間也就越大，進一步優化體驗的同時也有更多成本壓縮的空間。

感謝閱讀，以上是本次的分享內容，謝謝！

---

掃描圖中二維碼或點擊閱讀原文

了解大會更多信息

喜歡我們的內容就點個“在看”吧！

總結

以上是生活随笔為你收集整理的面向在线教育业务的流媒体分发演进的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。