隨著近幾年音影片流媒體行業的持續發展，海量併發、低延時和低成本作為三大核心訴求依舊需要不斷深挖，同時隨著 RTC 和 CDN 這兩種技術的界線越來越模糊，因此有必要從底層架構層面重新思考 RTC 與 CDN 的融合之道。本文將重點分享：網易雲信如何構建 RTC-CDN 服務架構，深入剖析這套架構是如何解決海量併發、超低延時與低成本三大行業核心訴求，並結合低延時直播和元宇宙兩大場景，為大家講解 RTC-CDN 的核心技術和最佳實踐。
背景介紹
我們能明顯感受到近幾年影片雲行業的迅猛發展，不管是在傳統泛娛樂社交、教育、線上會議領域，還是在元宇宙、雲遊戲等創新領域都有較好的增長。隨之而來的是這個賽道在國內越來越卷，越來越多的公司投入這個領域，也不斷推動著影片雲技術的迭代升級。
簡單列舉幾個這兩年比較熱門的技術方向：
• 出海和全球化。隨著影片雲國內市場進入紅海階段，大家都開始向海外市場突破，音影片全球化的技術能力越來越成為各個廠商關注的重點，本文的第二部分會分享網易雲信構建全球化的流媒體服務的相關內容；
• 超低延時流媒體技術。或者換一個說法，就是在一套系統裡面去滿足不同場景從 200ms 到 1.2 秒的差異化延時需求，同時還要做到低成本，本文的第三部分中分享這些內容；
• 元宇宙與虛擬人。隨著 Metaverse、Avatar、NFT、Web3.0 等新興技術大熱，影片雲領域也不斷湧現出新的技術方向與之匹配，本文的第四部分會和大家探討相關方案；
• 標準化。隨著行業的發展，標準化協議和標準化方案越來越被企業需要，標準化是低成本的一部分，本文將會分享近兩年網易雲信在標準化方面的探索、思考和實踐。
隨著音影片流媒體相關需求的日益增長，未來流媒體行業還有無限機會，同時也面臨著眾多挑戰。
以下是低延時海量併發流媒體系統會面臨的三大挑戰：
• 在低延時流媒體系統裡，需要滿足包括 RTC 實時音影片、直播、低延時直播、IoT 機器人、嵌入式裝置等各類場景對延時的要求，為了實現不同的延時要求，低延時流媒體系統不僅要具備很強的協議相容能力還需要具備很強的架構自適應能力；
• 隨著流媒體系統承載的場景越來越豐富，整個系統需要承載的併發也越來越大，包括單頻道的百萬併發，以及晚高峰的的流量蜂擁，這就要求我們的系統具備很好的彈性擴縮容能力；
• 隨著全球化的使用者接入，還需要面對全球範圍內複雜多變的網路情況，包括小運營商、偏遠地區和非洲等國家的 2.5G 或 3G 網路，以及更為複雜的跨國通訊的網路場景。
帶著這些問題和挑戰，我們本文的第二部分。在這一部分，我們緊扣主題裡關鍵字“海量併發”，會和大家深度探討一下如何構建支援全球化海量併發的流媒體伺服器架構。
構建海量併發流媒體服務架構
首先，我們從全域性的維度來看看網易雲信是怎麼做多協議融合通訊流媒體服務系統的。
如圖所示，整個架構的中間，是雲信的流媒體傳輸與處理伺服器，其中包括了邊緣媒體接入系統、實時傳輸網系統、流媒體處理服務系統以及直播點播服務系統。在融合通訊流媒體系統中，除了雲信 SDK 以外還支援了多種協議客戶端的接入，在邊緣媒體接入服務模組中，我們的邊緣媒體伺服器既支援雲信 SDK 的接入，也直接支援了標準 Web 端使用 WebRTC 接入；另外雲信自研了 SIP 閘道器伺服器，實現了 SIP、PSTN 的接入；雲信使用通用媒體閘道器實現了標準 RTMP 推流工具、小程式、RTSP 監控攝像頭的接入。
在邊緣媒體服務系統收到各協議客戶端的媒體資料包以後，會透過雲信實時傳輸網的邊緣節點和路由節點進行全球實時媒體資料分發，保證端到端的最優體驗。同時利用流媒體處理服務的通用媒體處理伺服器 MPS，可以將媒體流混合以後旁路轉推到互動直播伺服器，再透過雲信的直播和低延時直播的融合 CDN 系統進行分發；還可以在雲端進行錄製後，儲存到雲信的點播服務系統中。
在流媒體傳輸與處理服務系統的左邊是全域性流媒體控制服務，它包括了：頻道與流管理服務，統一媒體排程服務和實時傳輸網排程服務，它是整個音影片融合通訊系統的大腦，由它來動態控制整個系統的運轉。
最右側，是大資料與配置服務系統，它包括了全域性大資料分析和挖掘系統，負責全鏈路各個採集的資料處理、告警和質量透明，並利用大資料探勘的結果指導全鏈路各模組演算法和策略的制定，另一個是我們智慧全域性配置管理和下發服務，它負責對我們各類雲端引數的下發，包括 QoS 引數，音影片編解碼引數以及 A/B test 的相關開關。
在網易雲信融合通訊流媒體架構中，大量使用瞭解耦與分層的思路。接下來，我們深入到其中流媒體傳輸與全球傳輸大網兩大核心繫統，看看解耦的思路具體是如何落地的。
網易雲信融合通訊流媒體架構——解耦
首先是流媒體傳輸模組的解耦，包含了控制面、媒體轉發面以及全球大網傳輸面三層解耦。客戶端連線到邊緣的媒體伺服器上以後，客戶端流的釋出和訂閱的資訊都由邊緣伺服器同步給頻道與流管理服務，所有頻道業務層面對流的操作都由管理伺服器統一處理，這就是控制面和轉發面的解耦。這麼做最大的好處就是媒體伺服器上沒有複雜的頻道狀態，那麼在多臺媒體伺服器級聯的時候，就無需在媒體伺服器之間同步流的狀態和資訊，這麼做大大降低了級聯的難度以及各級聯的媒體伺服器之間狀態不同步導致的問題，也非常易於實現萬人乃至十萬人的大房間。
其次，邊緣媒體伺服器之間的級聯採用的是無向圖結構，所有級聯的媒體伺服器節點都是平等的，沒有頂點就不存在單點故障問題。
最後，兩臺媒體伺服器的級聯中間鏈路的路由最佳化，由中間的實時傳輸大網來做，媒體伺服器本身並不關心中間路徑的規劃問題，這麼做也進一步的解耦了媒體伺服器與大網傳輸系統，大網傳輸也無需關心具體的音影片業務。實時傳輸網的邊緣節點根據實時傳輸網排程服務的統一調配，透過傳輸網的路由節點，將資料包以最優路徑傳送到目的邊緣媒體伺服器。在這個過程中實時傳輸網路由探測和計算服務是鏈路路由選擇且保證最優質量的的控制大腦。媒體伺服器的級聯行為完全按需由使用者的媒體分發需求觸發，而大網的也只需要考慮網路傳輸鏈路最優路由，兩個系統各司其職，做到極致最佳化；因為採用了完全解耦的設計，因此大網系統也充滿了想象空間，可用於除了 RTC 媒體傳輸以外的很多場景。
雲信流媒體伺服器架構——解耦（大網內部）
下面一起來看實時傳輸網 WE-CAN 內部的解耦和分層是怎麼做的。
我們把 WE-CAN 從下到上分為 6 層，核心的當然是網路層、傳輸層和應用層了，某種程度上對應傳統的網際網路模型的三層，當然不是嚴格對照。
在分層架構最底下是基建層，基建層都是我們網易自研或者說雲信自研的一些基礎平臺。包括資料平臺、管控平臺即我們 WE-CAN 的內部 Dashboard、我們自研的一個全球的分散式的快取系統即所謂儲存平臺，還有配置平臺。
基建層往上的控制層其實和網路層結合非常緊密，可以看到接入、轉發、路由和排程這四塊是 WE-CAN 最核心的模組。再上面的傳輸層主要是一個協議層，網路層和控制層是做路由的，傳輸層是做 QoS 和各種各樣的傳輸策略。最上面的應用層是對傳輸層和網路層能力的封裝，做了很多比較抽象的基礎服務，而業務層是實際各個業務場景中對應用層能力的使用。
那麼為什麼要強調網路分層呢？首先 WE-CAN 本身就是一個 overlay，它本身就是基於公共網際網路上的一層。其次網路分層做得好，我認為可以做到各個系統模組各司其職，系統邊界也非常清晰，並且其實各層有各自不同的傳輸最佳化策略，比如網路層和傳輸層的最佳化策略是不一樣的，可以做的事情不一樣，甚至同樣的最佳化策略如重傳，在網路層和傳輸層的實現方式也是不一樣的，網路層策略都是轉發節點間逐跳的，傳輸層是接入節點到接入節點之間的。
最後網路分層和解耦做得好，可以支援更多的傳輸場景。WE-CAN 不僅是要支援實時音影片通訊、低延遲媒體流傳輸，我們是要做一個通用的傳輸加速網路，所以分層做得好可以把各層的能力抽象剝離，就可以支援更多的傳輸場景。目前雲信已經將 WE-CAN 應用在 RTC、IM、直播點播和資料上報等場景。
全球化與單元化
隨著全球化和出海的需求越來越多，為了最佳化全球使用者的接入質量以及避免單點故障，系統的全球化和單元化是極其重要的。
下圖是一個 RTC 伺服器架構的簡圖，我們簡化了控制單元的數量，但是足以說明問題，對於它的部署架構，右邊這三個關鍵詞可以非常形象的描述它的整體設計理念。
第一個關鍵詞還是分層解耦。整個 RTC 伺服器可以劃分成三個層次，首先是信令接入層，這是整個 RTC 服務的入口。其次是媒體信令層，這層是 RTC 媒體伺服器的控制中心，會和底下第三層次的媒體服務層進行大量的信令互動。
具體來看每個服務層的實現方案，對於信令接入層來說，利用全球部署的智慧 DNS 和 HTTP DNS 服務，雲信實現智慧 LBS 服務可以將請求智慧負載均衡和災備到各個控制單元入口閘道器；每個控制單元均獨立部署支援 HTTP3 和 QUIC 的入口閘道器、頻道與流管理服務以及排程服務，控制單元之間利用 WE-CAN 實現的全球分散式訊息同步機制，同步必要的資訊，做到控制單元間的災備和資訊一致性，做好上面這些，就完成了第二個關鍵詞——資料隔離和同步；而對於媒體服務來說，全球範圍內的所有媒體伺服器以及 WE-CAN 傳輸大網節點均是所有單元共享的，這樣就可以做到邊緣節點最高資源利用率；
最後一個關鍵詞——單元互備。控制單元內的不管信令入口還是頻道管控排程服務均是單元互備，每個服務層均支援單元化的部署，透過單元間的互備，可以避免單點的故障影響全域性。
排程之道
在看完了全球化與單元化的方案後，我們把目光聚焦到排程系統，排程作為流媒體系統中的核心繫統，它的重要程度不言而喻。
展開來看，雲信的排程系統裡面最核心的要兩套策略：靜態排程和動態排程，這兩套策略並不是相互獨立生效，而是緊密配合的。對於靜態排程來說非常好理解，排程依賴的核心資料來源是全球靜態的 IP 庫，雲信使用多個 IP 庫並保持 IP 庫的每日更新，來儘量保障 IP 解析的正確性；靜態排程的排程策略也相對簡單：使用同 ISP 運營商、地理位置就近接入；使用 BGP 節點覆蓋小運營商；當然還需要保證全域性的負載均衡以大區隔離，所謂的大區隔離舉個例子：中國大陸的使用者無論如何不會排程到中國大陸以外的伺服器節點，即便是數字層面的距離非常近。
靜態排程策略在雲信早期使用多年，但隨著全球化和各類不同使用者的接入，由於使用者網路和運營商的複雜性，靜態排程已經滿足不了最優接入的要求；最典型的例子就是在中東，各種網路運營商數量繁多，某些中東使用者連線歐洲節點反而比連線中東本地節點更快、更穩定。為了解決此類問題，我們引入動態排程系統，核心思想是使用真實業務資料的大資料分析，驅動排程的排程策略的動態修正。展開來講：使用者登入邊緣節點的歷史登入成功率，使用者在某個邊緣節點的服務端側的 QoS 資料以及客戶單側真實的 QoE（卡頓、延時）資料，這些資料都會作為某個使用者的歷史通話質量指標成為動態排程系統的輸入；另外通話前的實時探測和通話過程中的取樣打點探測，這些探測資料也會用於那些沒有歷史通話資料使用者的動態排程。動態排程系統不僅解決了使用者的接入由原來的 “最近”接入升級為了的“最優”接入，還對成本最佳化帶來了正向作用，我們發現在很多省市的小運營商使用者使用頻寬費用較低的單線機房時 QoE 效果還優於使用頻寬費用高昂的 BGP 節點。
當然再智慧的排程的排程演算法也有覆蓋不了的邊緣情況，所以我們在排程系統中也引入了特殊規則配置系統，我認為這個是非常必要的，某些 bad case 現階段還是隻能使用特殊規則來匹配；另外對於一套成熟的排程系統來說，任何的排程演算法和策略變更都需要做完整的 A/B Test，所以一套完善 A/B Test 系統要滿足：從規則生效、灰度比例控制、請求染色，到最後的結果量化驗證，一定要形成一個完整的閉環。
流量蜂擁解決之道
• 基礎是要做要負載均衡，需要重點關注負載收集的及時性，包括算力和頻寬負載壓力的收集。
• 從流媒體的角度需要做好業務結合，特別是 RTC 的業務形態比較特殊，一個大房間的流量蜂擁，有時就會造成雪崩效應。從媒體分發的角度上要從頻道級別做好頻控和頻寬預測；從信令的角度上要做好信令合併，信令分級和平滑削峰佇列。
• 除此之外需要有兜底策略，做好限流和熔斷，設計好服務優先順序。比如在大房間的場景下，使用者列表的實時同步是一個非常消耗資源的服務功能，在蜂擁的情況下，非主播的使用者列表可以從實時同步降級為定時同步，這樣可以儘量不影響業務可用性的情況下，大大降低服務端的壓力。
• 最後基於 K8S 的動態彈性擴縮容能力是流媒體蜂擁之道解決的未來。
總結來說我認為好的排程系統，就是能在資源有限的前提下達到全域性最優。
以上內容為上半部分，下半部分內容請持續關注。