簡介：在 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 服務的全部挑戰。生生不息，填坑不止，后端服務就沒有做完的那一天。

原文鏈接：https://developer.aliyun.com/article/783743?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的扩展 GRTN：云原生趋势下的 RTC 架构演进的全部內容，希望文章能夠幫你解決所遇到的問題。

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