簡介：在 2021 LiveVideoStackCon 音視頻技術(shù)大會上海站，聚焦 “輕端重云和邊緣架構(gòu)新模式” 專場，阿里云視頻云的 RTC 傳輸專家楊成立（忘籬）帶來 “基于邊緣云原生的 RTC 服務(wù)架構(gòu)演進(jìn)” 的主題演講，與行業(yè)伙伴分享視頻云在 RTC 服務(wù)架構(gòu)演進(jìn)之路上的挑戰(zhàn)和經(jīng)驗，以下為完整的演講內(nèi)容。

后端傳輸網(wǎng)絡(luò)是 RTC 系統(tǒng)的核心能力，比如阿里云的 GRTN、聲網(wǎng)的 SD-RTN 等。本文介紹了阿里云視頻云如何不斷改進(jìn) RTC 架構(gòu)，擴(kuò)展 GRTN 網(wǎng)絡(luò)，并基于云原生技術(shù)獲得云的強(qiáng)大能力。

個人介紹

大家好，我是楊成立（忘籬），目前在阿里云負(fù)責(zé) RTC 的傳輸網(wǎng)絡(luò)，之前在藍(lán)汛 CDN 負(fù)責(zé)直播的傳輸網(wǎng)絡(luò)，這十年左右一直在做視頻的后端服務(wù)，也是開源視頻服務(wù)器 SRS 的作者，SRS 目前是全球 Top1 的開源視頻服務(wù)器。

后端服務(wù)都架構(gòu)在云上，CDN 的趨勢也是邊緣云，這是因為云計算成為各種服務(wù)的基礎(chǔ)設(shè)施，當(dāng)然也包括視頻的后端服務(wù)。開發(fā)者可以便捷的直接使用云廠商的 SDK 和視頻云服務(wù)，也可以使用開源方案在云上構(gòu)建自己的系統(tǒng)。

我正好活躍在視頻開源和云服務(wù)這兩個領(lǐng)域，一直都有朋友詢問這兩個的差異，借這次機(jī)會正好分享下這個話題，希望通過這次分享，大家可以了解，從一個開源服務(wù)器，到可以提供服務(wù)的商業(yè)系統(tǒng)，到底有哪些路要走。

RTC 服務(wù)介紹

因為有些朋友不是做服務(wù)器的，我還是先介紹下 RTC 服務(wù)是什么吧。

直播經(jīng)過這些年的發(fā)展，大家都理解需要后端服務(wù)，比如 OBS 推流，是不能直接推給播放器的，而是經(jīng)過 CDN 轉(zhuǎn)發(fā)，CDN 就是直播的后端服務(wù)了。

RTC 是大不相同的，比如 WebRTC 本身設(shè)計是通話，通話場景大部分時候都是一對一的對話，所以 WebRTC 設(shè)計了多種傳輸方式，比如直接 P2P、通過 STUN 轉(zhuǎn)發(fā)、通過 SFU 或 MCU 轉(zhuǎn)發(fā)。

如果只是跑 DEMO，那么不用 RTC 服務(wù)器，直接 P2P 也是可以跑起來的。真實線上，肯定是要經(jīng)過服務(wù)器，現(xiàn)在使用最廣的是 SFU 轉(zhuǎn)發(fā)。主要原因如下：

• P2P 打不通：有些網(wǎng)絡(luò)是對稱 NAT，兩個客戶端在各自的內(nèi)網(wǎng)無法通過 P2P 打通，就必須使用服務(wù)器中轉(zhuǎn)流。
  
  
• 跨網(wǎng)遠(yuǎn)距離傳輸：比如跨國傳輸，或者跨運營商，客戶端直接 P2P 就算能連通，效果也不好，如果經(jīng)過服務(wù)器可以優(yōu)化傳輸線路。
  
  
• 會議轉(zhuǎn)直播：如果需要對媒體進(jìn)行處理，比如將 RTC 轉(zhuǎn)直播，廣播給更多觀眾，就需要轉(zhuǎn)碼和轉(zhuǎn)協(xié)議，這也必須要服務(wù)器處理。
  
  
• 錄制精彩片段：目前的錄制和剪輯等內(nèi)容的處理，在互聯(lián)網(wǎng)上還是 RTMP 對接比較多，將 RTMP 流送到錄制或剪輯系統(tǒng)。
  
  
• 不同客戶端網(wǎng)絡(luò)狀況不同：有些客戶端網(wǎng)絡(luò)好，有些差，通過服務(wù)器可以精確計算不同客戶端的網(wǎng)絡(luò)情況，給客戶端傳輸不同的質(zhì)量的流。
  
  
• 兼容老客戶端和協(xié)議：線上客戶端的版本非常多，隨著迭代，可能支持的協(xié)議也不一樣，需要服務(wù)器做兼容處理。
  

各家云廠商都有自己的后端服務(wù)，比如阿里云的 GRTN，聲網(wǎng)的 SD-RTN 等等。實際上傳輸網(wǎng)絡(luò)并不等于傳輸服務(wù)器，而是一個傳輸?shù)南到y(tǒng)，包括調(diào)度、路由、協(xié)議處理、發(fā)布和維護(hù)、問題排查、數(shù)據(jù)分析等等。

AliRTC（阿里云 RTC）的傳輸網(wǎng)絡(luò)，傳輸協(xié)議使用 GRTN，除了 GRTN (CDN) 的網(wǎng)絡(luò)，我們還擴(kuò)展實現(xiàn)了 GRTN (Tenfold)；GRTN (Tenfold) 補(bǔ)充了 BGP 專線、ENS、專有云網(wǎng)絡(luò)、第三方云支持 K8S 的云網(wǎng)絡(luò)等，適應(yīng)多種不同場景的傳輸要求。

其中 GRTN (Tenfold) 就是基于 SRS 做的，增加了很多能力，有些已經(jīng)反饋給了 SRS 社區(qū)。

為何選擇 SRS

下面介紹下 SRS，以及我們?yōu)楹我x擇 SRS。

視頻服務(wù)器的主要問題是：門檻高、領(lǐng)域廣、更新快，開源和云服務(wù)不同步。

• 門檻高：由于視頻的技術(shù)棧很深，信號處理、編解碼、傳輸、客戶端平臺，每個方向都有很深的技術(shù)棧，必須要有專門的視頻服務(wù)器。業(yè)內(nèi)知名的 Nginx 本質(zhì)上并不是做視頻的，Web 和視頻差別非常大。
  

• 領(lǐng)域廣：直播和 RTC 是互聯(lián)網(wǎng)成規(guī)模的應(yīng)用，其實還有監(jiān)控和 IoT 發(fā)展也非常快，公有云、專有云、邊緣云多個云的情況也不同，我們需要一個跨視頻領(lǐng)域的服務(wù)器。Janus 等專門的會議服務(wù)器，在超大規(guī)模上有結(jié)構(gòu)性的問題（或者說這是直播要解的問題，所以 Janus 不需要解）。
  

• 更新快，開源和云服務(wù)不同步：視頻比云服務(wù)發(fā)展更早，而云服務(wù)的很多要求，開源視頻服務(wù)器并不滿足，很多開源項目并不考慮云架構(gòu)，因此從基于開源的自建系統(tǒng)，遷移到云就非常難。
  

為什么這個問題很重要？

• 影響視頻在各個領(lǐng)域的落地，阻礙新場景的發(fā)展。新場景一定是跨領(lǐng)域的，不會有只做直播或只做 RTC 的情況，新領(lǐng)域并不是直播簡單的滲透，而是互聯(lián)網(wǎng)視頻的滲透，只有跨領(lǐng)域的開源項目，才能推動新場景的發(fā)展和落地。
  

• 無法使用云服務(wù)能力。云架構(gòu)最厲害在于彈性，而且是標(biāo)準(zhǔn)的跨云的彈性。如果開源項目本身不考慮云架構(gòu)，就無法遷移到云也沒有彈性能力。開源的云架構(gòu)并不是把開源在云主機(jī)中運行，就是云架構(gòu)。
  

• 多云遷移困難。云的方向是應(yīng)用上云的標(biāo)準(zhǔn)化 (K8S)，可以在多個云之間無縫遷移，這給應(yīng)用非常高的可靠性。如果開源項目本身不做 K8S 所要求的改造，就無法在多個云之間遷移。
  

SRS 如何解決這個問題？SRS 的定位是云原生的視頻服務(wù)器，應(yīng)對云原生做了大量改造，可以非常方便上云和遷移。

除了云原生的能力，SRS 也是非常高性能的開源服務(wù)器。當(dāng)然性能沒有最高只有更高，每個大版本都需要做性能優(yōu)化，然后用性能交換功能和用戶體驗。

特別說明下，這里并不是說 Nginx 和 Janus 就做不到 SRS 的并發(fā)，只是目前的版本壓測出來的數(shù)據(jù)。性能和行業(yè)背景是非常相關(guān)的，比如 2012 年大多是千兆網(wǎng)絡(luò)時代，所以 Nginx 的性能足夠能打滿帶寬了。而 Janus 同類的服務(wù)器差不多都是 Janus 這個量級。SRS 之所以一直重視性能是因為互聯(lián)網(wǎng)很關(guān)注成本，成本必須使用性能交換。

今年是 SRS 第八個年頭，去年已經(jīng)成為開源視頻服務(wù)器的 Top1，主要還是因為國內(nèi)的視頻行業(yè)發(fā)展很快，另外活躍的視頻開源服務(wù)器比較少。

這里說點八卦，這次疫情給全球經(jīng)濟(jì)帶來很大影響，也帶來了互聯(lián)網(wǎng)視頻的大爆發(fā)，比如直播、教育、會議、云游戲、IoT 等等。大家只能在家活動，所以互聯(lián)網(wǎng)成了大家交流的重要方式，各個開源項目也在 20 年初有很大的增長，比如 Janus。

很可能這是我們唯一會經(jīng)歷的黑天鵝了，我之前一直有個疑問，就是疫情結(jié)束后，是否互聯(lián)網(wǎng)視頻會回到解放前？從 Janus 的增長速度看，半年后增長的速度回落到疫情前了。這也許也說明了，就算是做開源也不能依賴這種事件。

SRS 的快速增長是在 19 年底，這個時間點也是 SRS 支持 WebRTC、SRT 和 GB28181。所以也分不清多少是疫情的拉動，多少是因為 SRS 自己的努力。好消息是 SRS 的增長并沒有回落，而且是目前增長最快的開源視頻服務(wù)器項目。持續(xù)的增長和全球 Top1，這不是結(jié)束，而是一個新的開始。

我們認(rèn)為只有公眾號訂閱的開發(fā)者超過 100K，才能有機(jī)會提升了整個視頻行業(yè)開發(fā)者的創(chuàng)造力。只有達(dá)到 100K 的 Star，才能叫互聯(lián)網(wǎng)視頻的標(biāo)準(zhǔn)開源服務(wù)器。只有不斷推動新場景的 DEMO 和探索，才能不斷拓展視頻的邊界。

SRS 是一個雄心勃勃的開源項目，十年的 OKR 是個挺大的目標(biāo)。如果我們看三十年后，那么有三代新的開發(fā)者進(jìn)入視頻行業(yè)，而隨著視頻成為互聯(lián)網(wǎng)基礎(chǔ)設(shè)施的一部分，那么這個目標(biāo)也不算是很大，最大的問題可能是在于 SRS 能否活夠 30 年吧。

什么是云原生

回到今天的主題，從開源 SRS 到商業(yè)服務(wù)，還需要解決哪些問題。

• 長會話：RTC 中最長有 48 小時的會議，甚至更長，直播有時候也是非常長時間推流，比如昨天雷軍的視頻號直播，折疊小米手機(jī)的折疊屏，連續(xù)直播折疊三天。這三天直播服務(wù)怎么升級？
  

• 中心、邊緣、專有云 SLA 差異大：中心云的網(wǎng)絡(luò)狀況，基礎(chǔ)設(shè)施的完善度很高，會話的遷移相對比較容易。而邊緣和專有云的 SLA 就差很多，不能用同樣的機(jī)制做遷移。
  

• 端口和 IP 復(fù)用：傳統(tǒng) RTC 一般是內(nèi)網(wǎng)應(yīng)用，有可以隨便使用的 IP，可以分配幾萬個隨機(jī)端口，這些在云上有安全隱患，公網(wǎng) IPv4 地址不能隨意用，擴(kuò)容就很難做。
  

• 流多且有關(guān)聯(lián)，還有切網(wǎng)問題：直播的流之間沒有關(guān)聯(lián)性，可以在服務(wù)器負(fù)載高時調(diào)度新的會話到其他服務(wù)器，而 RTC 流之間有關(guān)聯(lián)性，有時候不能隨意調(diào)度，導(dǎo)致負(fù)載均衡很難做。
  

• 性能優(yōu)化難：RTC 必須加密，UDP 在內(nèi)核協(xié)議棧的性能低下，QoS 算法的不斷迭代消耗了性能。這讓 RTC 的服務(wù)不再是單純的 IO 密集型服務(wù)器，性能是整個系統(tǒng)的基礎(chǔ)，影響其他所有的方面。
  

• 客戶端版本和算法多，很難做回歸測試。牽一發(fā)而動全身，很難知道一次修改，是否會導(dǎo)致客戶端出問題，很難知道是否所有線上的大版本和小版本是否會出問題。
  

這些問題，前四個和云原生是有非常緊密的關(guān)系。后面幾個問題，每個都是很大的話題，限于時間關(guān)系，我們會在以后給大家分享。

云的發(fā)展方向，不管是中心云、邊緣云還是專有云，都是云原生方向。云本身就云里霧里，云原生更加云山霧罩了，我們可以看看云本身的思考。

可以說，開源項目如果做了云原生的改造和重新設(shè)計，具備了云架構(gòu)的能力，就解決了商業(yè)化服務(wù)一個大問題。我們一起來看，需要做哪些改造。

長會話，升級難

長會話：RTC 中最長有 48 小時的會議，甚至更長，直播有時候也是非常長時間推流，比如昨天雷軍的視頻號直播，折疊小米手機(jī)的折疊屏，連續(xù)直播折疊三天。這三天直播服務(wù)怎么升級？

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

為何重要：真正提供服務(wù)的線上系統(tǒng)，不是在升級，就是在升級的路上，一天到晚都是升級。是不可能完全停下來，中斷服務(wù)，全量升級后再提供服務(wù)。長會話意味著必須支持無中斷升級，否則就會造成不可用和服務(wù)中斷的問題，嚴(yán)重影響客戶體驗。

擴(kuò)縮容也會受到長會話的影響。業(yè)務(wù)量增長時，需要增加機(jī)器擴(kuò)容，現(xiàn)有長會話無法遷移到新的機(jī)器，擴(kuò)容只能應(yīng)對新的流量。業(yè)務(wù)量降低后，可以縮容降低成本，如果長會話的周期，超過了業(yè)務(wù)周期，就無法實現(xiàn)縮容。

直播的業(yè)務(wù)質(zhì)量，是按百分比計算，比如百分之 N 的卡頓是可以接受的。而在 RTC 中，會議中有一個人不可用，整個會議就無法繼續(xù)。每個會議都很重要的，一個會議的重要性，并不一定低于另外一百個會議。

現(xiàn)狀和未來：開源 SRS 改進(jìn)了退出邏輯，可以做到等待一定時間后退出。SRS 還做不到無狀態(tài)升級，因為要做到無狀態(tài)化需要依賴存儲，而開源的 SLA 還不需要那么高。

GRTN (Tenfold) 已經(jīng)做到無狀態(tài)化升級，可隨時升級（當(dāng)然會選擇業(yè)務(wù)低峰期升級）。由于可以無狀態(tài)重啟，我們也順便解決了 Crash 后恢復(fù)的問題，C++ 的程序，就像移動端的 Crash 率一樣的，一定會有 Crash。

未來 GRTN (Tenfold) 還會做到狀態(tài)遷移和 K8S 的滾動升級。

SLA 不同，遷移難

中心、邊緣、專有云 SLA 差異大：中心云的網(wǎng)絡(luò)狀況，基礎(chǔ)設(shè)施的完善度很高，會話的遷移相對比較容易。而邊緣和專有云的 SLA 就差很多，不能用同樣的機(jī)制做遷移。

問題：沒有 100% 的 SLA，底層設(shè)施一定會出問題，遲早會出問題，宕機(jī)、IO Hang、網(wǎng)絡(luò)不可用；中心、邊緣、專有云，SLA 差異大，遷移難。

為何重要：當(dāng)?shù)讓踊A(chǔ)設(shè)施出現(xiàn)問題，雖然概率不大，但一旦出現(xiàn)問題，服務(wù)就是不可用了。一臺服務(wù)器不可用時，影響的不僅僅是這臺服務(wù)器的會話，而是這個服務(wù)器上的所有會議，一個會議一般會跨多個服務(wù)器。

中心云的遷移，可用的基礎(chǔ)設(shè)施比較完善。邊緣云和專有云，網(wǎng)絡(luò)狀況和基礎(chǔ)設(shè)施可靠性，不如中心云，遷移的難度更大。

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

GRTN (Tenfold) 具備了底層遷移能力，預(yù)計今年可以支持中心云遷移。未來需要不斷優(yōu)化遷移能力，支持邊緣云和專有云的遷移；還需要考慮計劃中的遷移，比如流量再均衡。

端口和 IP 復(fù)用，擴(kuò)容難

端口和 IP 復(fù)用：傳統(tǒng) RTC 一般是內(nèi)網(wǎng)應(yīng)用，有可以隨便使用的 IP，可以分配幾萬個隨機(jī)端口，這些在云上有安全隱患，公網(wǎng) IPv4 地址不能隨意用幾萬個，擴(kuò)容就很難做。

問題：安全要求只能開固定的端口；企業(yè)防火墻只能開特定的端口；不能開一定范圍端口，比如 10000 到 20000 端口。

為何重要：不符合安全規(guī)范，無法通過安全審核。多端口更容易被攻擊，如果出現(xiàn)安全事故，比一臺服務(wù)不可用還要嚴(yán)重，這也是為何 WebRTC 正在做 E2E（端到端）加密的原因。

有些用戶在企業(yè)防火墻后面，訪問公網(wǎng)時不能訪問任意端口，必須收斂到某些 IP 和端口。如果不支持端口復(fù)用，就無法在這些企業(yè)場景下使用。

端口本質(zhì)上是一種狀態(tài)，它是一種對用戶的標(biāo)示，比如 IP+ 端口就可以認(rèn)為是某個客戶端。這也給服務(wù)遷移帶來問題，需要遷移更多的狀態(tài)。

現(xiàn)狀和未來：云原生的標(biāo)準(zhǔn)做法，是通過 SLB/Service 隱藏服務(wù)，流量通過 SLB 轉(zhuǎn)發(fā)到真實的 Pod 服務(wù)器。SRS 已經(jīng)支持了這種方式。

線上還有移動端切網(wǎng)問題，會影響 SLB 定位客戶端。SRS 目前使用 ICE 的 PingPong 標(biāo)示客戶端，未來和更好的做法是用 QUIC，QUIC 協(xié)議本身考慮了會話的標(biāo)示，在 SLB 層就可以解決問題。

GRTN (Tenfold) 還支持了 TURN 協(xié)議的 SLB 轉(zhuǎn)發(fā)。未來還需要解決在邊緣云中的端口復(fù)用問題，和中心云不同，邊緣云可能是分運營商的，客戶端切網(wǎng)后需要更換 IP 入口。

流多且關(guān)聯(lián)，負(fù)載均衡難

流多且有關(guān)聯(lián)，還有切網(wǎng)問題：直播的流之間沒有關(guān)聯(lián)性，可以在服務(wù)器負(fù)載高時調(diào)度新的會話到其他服務(wù)器，而 RTC 流之間有關(guān)聯(lián)性，有時候不能隨意調(diào)度，導(dǎo)致負(fù)載均衡很難做。

問題：流有關(guān)聯(lián)性，服務(wù)的會話數(shù)不變，負(fù)載可能會突增。流的關(guān)聯(lián)性，碼率的波動，以及 QoS 算法的動態(tài)變化，導(dǎo)致水位評估不準(zhǔn)，會話數(shù)目不增加時，消耗的 CPU 和帶寬都不同。

為何重要：水位如果無法精確評估，就只能預(yù)留較多資源，保持較低的水位運行，避免水位突增，服務(wù)器被打爆。保持較低水位導(dǎo)致整體成本高。

現(xiàn)狀和未來：SRS 還沒有解決這個問題，正在做 QUIC 級聯(lián)，未來會考慮給出服務(wù)器的水位，但不會做流量調(diào)度和負(fù)載均衡，這個是系統(tǒng)要做的。

GRTN (Tenfold) 已經(jīng)支持多級級聯(lián)，跨區(qū)域級聯(lián)，有粗略的水位評估。正在做精確的水位評估，未來會考慮做流量均衡。

SRS 云原生

總結(jié)來說，云原生解決的都是臟活累活，而且還是干不完的臟活累活。云原生往前走了一大步，讓基礎(chǔ)設(shè)施可以不斷的標(biāo)準(zhǔn)化發(fā)展，應(yīng)用只要遵守云原生的規(guī)范，就可以在多個云上悠然自得。

視頻的門檻真的非常非常非常的高，還記得十一年前剛開始接觸 Flash 和 FFmpeg，僅僅各種概念和協(xié)議，就讓人一頭霧水。SRS 希望能讓視頻的門檻不斷降低，保持易用性讓開發(fā)者少一些焦慮和壓力，保持濃密的頭發(fā)。

但，這不是 RTC 服務(wù)的全部挑戰(zhàn)。生生不息，填坑不止，后端服務(wù)就沒有做完的那一天。

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

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。