擴展 GRTN：雲原生趨勢下的 RTC 架構演進

在 2021 LiveVideoStackCon 音視頻技術大會上海站，聚焦 「輕端重雲和邊緣架構新模式」 專場，阿里雲視頻雲的 RTC 傳輸專家楊成立（忘籬）帶來 「基於邊緣雲原生的 RTC 服務架構演進」 的主題演講，與行業夥伴分享視頻雲在 RTC 服務架構演進之路上的挑戰和經驗，如下爲完整的演講內容。

後端傳輸網絡是 RTC 系統的核心能力，好比阿里雲的 GRTN、聲網的 SD-RTN 等。本文介紹了阿里雲視頻雲如何不斷改進 RTC 架構，擴展 GRTN 網絡，並基於雲原生技術得到雲的強大能力。

我的介紹

你們好，我是楊成立（忘籬），目前在阿里雲負責 RTC 的傳輸網絡，以前在藍汛 CDN 負責直播的傳輸網絡，這十年左右一直在作視頻的後端服務，也是開源視頻服務器 SRS 的做者，SRS 目前是全球 Top1 的開源視頻服務器。

後端服務都架構在雲上，CDN 的趨勢也是邊緣雲，這是由於雲計算成爲各類服務的基礎設施，固然也包括視頻的後端服務。開發者能夠便捷的直接使用雲廠商的 SDK 和視頻雲服務，也可使用開源方案在雲上構建本身的系統。

我正好活躍在視頻開源和雲服務這兩個領域，一直都有朋友詢問這兩個的差別，藉此次機會正好分享下這個話題，但願經過此次分享，你們能夠了解，從一個開源服務器，到能夠提供服務的商業系統，到底有哪些路要走。

RTC 服務介紹

由於有些朋友不是作服務器的，我仍是先介紹下 RTC 服務是什麼吧。

直播通過這些年的發展，你們都理解須要後端服務，好比 OBS 推流，是不能直接推給播放器的，而是通過 CDN 轉發，CDN 就是直播的後端服務了。

RTC 是大不相同的，好比 WebRTC 自己設計是通話，通話場景大部分時候都是一對一的對話，因此 WebRTC 設計了多種傳輸方式，好比直接 P2P、經過 STUN 轉發、經過 SFU 或 MCU 轉發。

若是隻是跑 DEMO，那麼不用 RTC 服務器，直接 P2P 也是能夠跑起來的。真實線上，確定是要通過服務器，如今使用最廣的是 SFU 轉發。主要緣由以下：

• P2P 打不通：有些網絡是對稱 NAT，兩個客戶端在各自的內網沒法經過 P2P 打通，就必須使用服務器中轉流。
• 跨網遠距離傳輸：好比跨國傳輸，或者跨運營商，客戶端直接 P2P 就算能連通，效果也很差，若是通過服務器能夠優化傳輸線路。
• 會議轉直播：若是須要對媒體進行處理，好比將 RTC 轉直播，廣播給更多觀衆，就須要轉碼和轉協議，這也必需要服務器處理。
• 錄製精彩片斷：目前的錄製和剪輯等內容的處理，在互聯網上仍是 RTMP 對接比較多，將 RTMP 流送到錄製或剪輯系統。
• 不一樣客戶端網絡情況不一樣：有些客戶端網絡好，有些差，經過服務器能夠精確計算不一樣客戶端的網絡狀況，給客戶端傳輸不一樣的質量的流。
• 兼容老客戶端和協議：線上客戶端的版本很是多，隨着迭代，可能支持的協議也不同，須要服務器作兼容處理。

各家雲廠商都有本身的後端服務，好比阿里雲的 GRTN，聲網的 SD-RTN 等等。實際上傳輸網絡並不等於傳輸服務器，而是一個傳輸的系統，包括調度、路由、協議處理、發佈和維護、問題排查、數據分析等等。

AliRTC（阿里雲 RTC）的傳輸網絡，傳輸協議使用 GRTN，除了 GRTN (CDN) 的網絡，咱們還擴展實現了 GRTN (Tenfold)；GRTN (Tenfold) 補充了 BGP 專線、ENS、專有云網絡、第三方雲支持 K8S 的雲網絡等，適應多種不一樣場景的傳輸要求。

其中 GRTN (Tenfold) 就是基於 SRS 作的，增長了不少能力，有些已經反饋給了 SRS 社區。

爲什麼選擇 SRS

下面介紹下 SRS，以及咱們爲什麼要選擇 SRS。

視頻服務器的主要問題是：門檻高、領域廣、更新快，開源和雲服務不一樣步。

• 門檻高：因爲視頻的技術棧很深，信號處理、編解碼、傳輸、客戶端平臺，每一個方向都有很深的技術棧，必需要有專門的視頻服務器。業內知名的 Nginx 本質上並非作視頻的，Web 和視頻差異很是大。
• 領域廣：直播和 RTC 是互聯網成規模的應用，其實還有監控和 IoT 發展也很是快，公有云、專有云、邊緣雲多個雲的狀況也不一樣，咱們須要一個跨視頻領域的服務器。Janus 等專門的會議服務器，在超大規模上有結構性的問題（或者說這是直播要解的問題，因此 Janus 不須要解）。
• 更新快，開源和雲服務不一樣步：視頻比雲服務發展更早，而云服務的不少要求，開源視頻服務器並不知足，不少開源項目並不考慮雲架構，所以從基於開源的自建系統，遷移到雲就很是難。

爲何這個問題很重要？

• 影響視頻在各個領域的落地，阻礙新場景的發展。新場景必定是跨領域的，不會有隻作直播或只作 RTC 的狀況，新領域並非直播簡單的滲透，而是互聯網視頻的滲透，只有跨領域的開源項目，才能推進新場景的發展和落地。
• 沒法使用雲服務能力。雲架構最厲害在於彈性，並且是標準的跨雲的彈性。若是開源項目自己不考慮雲架構，就沒法遷移到雲也沒有彈性能力。開源的雲架構並非把開源在雲主機中運行，就是雲架構。
• 多雲遷移困難。雲的方向是應用上雲的標準化 (K8S)，能夠在多個雲之間無縫遷移，這給應用很是高的可靠性。若是開源項目自己不作 K8S 所要求的改造，就沒法在多個雲之間遷移。

SRS 如何解決這個問題？SRS 的定位是雲原生的視頻服務器，應對雲原生作了大量改造，能夠很是方便上雲和遷移。

除了雲原生的能力，SRS 也是很是高性能的開源服務器。固然性能沒有最高只有更高，每一個大版本都須要作性能優化，而後用性能交換功能和用戶體驗。

特別說明下，這裏並非說 Nginx 和 Janus 就作不到 SRS 的併發，只是目前的版本壓測出來的數據。性能和行業背景是很是相關的，好比 2012 年大可能是千兆網絡時代，因此 Nginx 的性能足夠能打滿帶寬了。而 Janus 同類的服務器差很少都是 Janus 這個量級。SRS 之因此一直重視性能是由於互聯網很關注成本，成本必須使用性能交換。

今年是 SRS 第八個年頭，去年已經成爲開源視頻服務器的 Top1，主要仍是由於國內的視頻行業發展很快，另外活躍的視頻開源服務器比較少。

這裏說點八卦，此次疫情給全球經濟帶來很大影響，也帶來了互聯網視頻的大爆發，好比直播、教育、會議、雲遊戲、IoT 等等。你們只能在家活動，因此互聯網成了你們交流的重要方式，各個開源項目也在 20 年初有很大的增加，好比 Janus。

極可能這是咱們惟一會經歷的黑天鵝了，我以前一直有個疑問，就是疫情結束後，是否互聯網視頻會回到解放前？從 Janus 的增加速度看，半年後增加的速度回落到疫情前了。這也許也說明了，就算是作開源也不能依賴這種事件。
SRS 的快速增加是在 19 年末，這個時間點也是 SRS 支持 WebRTC、SRT 和 GB28181。因此也分不清多少是疫情的拉動，多少是由於 SRS 本身的努力。好消息是 SRS 的增加並無回落，並且是目前增加最快的開源視頻服務器項目。持續的增加和全球 Top1，這不是結束，而是一個新的開始。

咱們認爲只有公衆號訂閱的開發者超過 100K，纔能有機會提高了整個視頻行業開發者的創造力。只有達到 100K 的 Star，才能叫互聯網視頻的標準開源服務器。只有不斷推進新場景的 DEMO 和探索，才能不斷拓展視頻的邊界。

SRS 是一個雄心勃勃的開源項目，十年的 OKR 是個挺大的目標。若是咱們看三十年後，那麼有三代新的開發者進入視頻行業，而隨着視頻成爲互聯網基礎設施的一部分，那麼這個目標也不算是很大，最大的問題多是在於 SRS 可否活夠 30 年吧。

什麼是雲原生

回到今天的主題，從開源 SRS 到商業服務，還須要解決哪些問題。

• 長會話：RTC 中最長有 48 小時的會議，甚至更長，直播有時候也是很是長時間推流，好比昨天雷軍的視頻號直播，摺疊小米手機的摺疊屏，連續直播摺疊三天。這三天直播服務怎麼升級？
• 中心、邊緣、專有云 SLA 差別大：中心雲的網絡情況，基礎設施的完善度很高，會話的遷移相對比較容易。而邊緣和專有云的 SLA 就差不少，不能用一樣的機制作遷移。
• 端口和 IP 複用：傳統 RTC 通常是內網應用，有能夠隨便使用的 IP，能夠分配幾萬個隨機端口，這些在雲上有安全隱患，公網 IPv4 地址不能隨意用，擴容就很難作。
• 流多且有關聯，還有切網問題：直播的流之間沒有關聯性，能夠在服務器負載高時調度新的會話到其餘服務器，而 RTC 流之間有關聯性，有時候不能隨意調度，致使負載均衡很難作。
• 性能優化難：RTC 必須加密，UDP 在內核協議棧的性能低下，QoS 算法的不斷迭代消耗了性能。這讓 RTC 的服務再也不是單純的 IO 密集型服務器，性能是整個系統的基礎，影響其餘全部的方面。
• 客戶端版本和算法多，很難作迴歸測試。牽一髮而動全身，很難知道一次修改，是否會致使客戶端出問題，很難知道是否全部線上的大版本和小版本是否會出問題。

這些問題，前四個和雲原生是有很是緊密的關係。後面幾個問題，每一個都是很大的話題，限於時間關係，咱們會在之後給你們分享。

雲的發展方向，無論是中心雲、邊緣雲仍是專有云，都是雲原生方向。雲自己就雲裏霧裏，雲原生更加雲山霧罩了，咱們能夠看看雲自己的思考。

能夠說，開源項目若是作了雲原生的改造和從新設計，具有了雲架構的能力，就解決了商業化服務一個大問題。咱們一塊兒來看，須要作哪些改造。

長會話，升級難

長會話：RTC 中最長有 48 小時的會議，甚至更長，直播有時候也是很是長時間推流，好比昨天雷軍的視頻號直播，摺疊小米手機的摺疊屏，連續直播摺疊三天。這三天直播服務怎麼升級？

問題：長會話，最長有 48 小時會議，升級困難。

爲什麼重要：真正提供服務的線上系統，不是在升級，就是在升級的路上，一天到晚都是升級。是不可能徹底停下來，中斷服務，全量升級後再提供服務。長會話意味着必須支持無中斷升級，不然就會形成不可用和服務中斷的問題，嚴重影響客戶體驗。

擴縮容也會受到長會話的影響。業務量增加時，須要增長機器擴容，現有長會話沒法遷移到新的機器，擴容只能應對新的流量。業務量下降後，能夠縮容下降成本，若是長會話的週期，超過了業務週期，就沒法實現縮容。

直播的業務質量，是按百分比計算，好比百分之 N 的卡頓是能夠接受的。而在 RTC 中，會議中有一我的不可用，整個會議就沒法繼續。每一個會議都很重要的，一個會議的重要性，並不必定低於另一百個會議。

現狀和將來：開源 SRS 改進了退出邏輯，能夠作到等待必定時間後退出。SRS 還作不到無狀態升級，由於要作到無狀態化須要依賴存儲，而開源的 SLA 還不須要那麼高。

GRTN (Tenfold) 已經作到無狀態化升級，可隨時升級（固然會選擇業務低峯期升級）。因爲能夠無狀態重啓，咱們也順便解決了 Crash 後恢復的問題，C++ 的程序，就像移動端的 Crash 率同樣的，必定會有 Crash。

將來 GRTN (Tenfold) 還會作到狀態遷移和 K8S 的滾動升級。

SLA 不一樣，遷移難

中心、邊緣、專有云 SLA 差別大：中心雲的網絡情況，基礎設施的完善度很高，會話的遷移相對比較容易。而邊緣和專有云的 SLA 就差不少，不能用一樣的機制作遷移。

問題：沒有 100% 的 SLA，底層設施必定會出問題，早晚會出問題，宕機、IO Hang、網絡不可用；中心、邊緣、專有云，SLA 差別大，遷移難。

爲什麼重要：當底層基礎設施出現問題，雖然機率不大，但一旦出現問題，服務就是不可用了。一臺服務器不可用時，影響的不只僅是這臺服務器的會話，而是這個服務器上的全部會議，一個會議通常會跨多個服務器。

中心雲的遷移，可用的基礎設施比較完善。邊緣雲和專有云，網絡情況和基礎設施可靠性，不如中心雲，遷移的難度更大。

現狀和將來：SRS 沒有支持遷移，開源的 SLA 容忍度高一些，同類開源服務器也沒有遷移能力；將來計劃使用體驗差的重連方案支持遷移。

GRTN (Tenfold) 具有了底層遷移能力，預計今年能夠支持中心雲遷移。將來須要不斷優化遷移能力，支持邊緣雲和專有云的遷移；還須要考慮計劃中的遷移，好比流量再均衡。

端口和 IP 複用，擴容難

端口和 IP 複用：傳統 RTC 通常是內網應用，有能夠隨便使用的 IP，能夠分配幾萬個隨機端口，這些在雲上有安全隱患，公網 IPv4 地址不能隨意用幾萬個，擴容就很難作。

問題：安全要求只能開固定的端口；企業防火牆只能開特定的端口；不能開必定範圍端口，好比 10000 到 20000 端口。

爲什麼重要：不符合安全規範，沒法經過安全審覈。多端口更容易被攻擊，若是出現安全事故，比一臺服務不可用還要嚴重，這也是爲什麼 WebRTC 正在作 E2E（端到端）加密的緣由。

有些用戶在企業防火牆後面，訪問公網時不能訪問任意端口，必須收斂到某些 IP 和端口。若是不支持端口複用，就沒法在這些企業場景下使用。

端口本質上是一種狀態，它是一種對用戶的標示，好比 IP+ 端口就能夠認爲是某個客戶端。這也給服務遷移帶來問題，須要遷移更多的狀態。

現狀和將來：雲原生的標準作法，是經過 SLB/Service 隱藏服務，流量經過 SLB 轉發到真實的 Pod 服務器。SRS 已經支持了這種方式。

線上還有移動端切網問題，會影響 SLB 定位客戶端。SRS 目前使用 ICE 的 PingPong 標示客戶端，將來和更好的作法是用 QUIC，QUIC 協議自己考慮了會話的標示，在 SLB 層就能夠解決問題。

GRTN (Tenfold) 還支持了 TURN 協議的 SLB 轉發。將來還須要解決在邊緣雲中的端口複用問題，和中心雲不一樣，邊緣雲多是分運營商的，客戶端切網後須要更換 IP 入口。

流多且關聯，負載均衡難

流多且有關聯，還有切網問題：直播的流之間沒有關聯性，能夠在服務器負載高時調度新的會話到其餘服務器，而 RTC 流之間有關聯性，有時候不能隨意調度，致使負載均衡很難作。

問題：流有關聯性，服務的會話數不變，負載可能會突增。流的關聯性，碼率的波動，以及 QoS 算法的動態變化，致使水位評估不許，會話數目不增長時，消耗的 CPU 和帶寬都不一樣。

爲什麼重要：水位若是沒法精確評估，就只能預留較多資源，保持較低的水位運行，避免水位突增，服務器被打爆。保持較低水位致使總體成本高。

現狀和將來：SRS 尚未解決這個問題，正在作 QUIC 級聯，將來會考慮給出服務器的水位，但不會作流量調度和負載均衡，這個是系統要作的。

GRTN (Tenfold) 已經支持多級級聯，跨區域級聯，有粗略的水位評估。正在作精確的水位評估，將來會考慮作流量均衡。

SRS 雲原生

總結來講，雲原生解決的都是髒活累活，並且仍是幹不完的髒活累活。雲原生往前走了一大步，讓基礎設施能夠不斷的標準化發展，應用只要遵照雲原生的規範，就能夠在多個雲上怡然自得。

視頻的門檻真的很是很是很是的高，還記得十一年前剛開始接觸 Flash 和 FFmpeg，僅僅各類概念和協議，就讓人一頭霧水。SRS 但願能讓視頻的門檻不斷下降，保持易用性讓開發者少一些焦慮和壓力，保持濃密的頭髮。

但，這不是 RTC 服務的所有挑戰。生生不息，填坑不止，後端服務就沒有作完的那一天。

「視頻雲技術」你最值得關注的音視頻技術公衆號，每週推送來自阿里雲一線的實踐技術文章，在這裏與音視頻領域一流工程師交流切磋。