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

個(gè)人介紹

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

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

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

RTC 服務(wù)介紹

因?yàn)橛行┡笥巡皇亲龇?wù)器的，我還是先介紹下 RTC 服務(wù)是什么吧。

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

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

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

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

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

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

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

為何選擇 SRS

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

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

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

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

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

為什么這個(gè)問(wèn)題很重要？

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

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

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

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

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

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

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

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

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

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

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

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

什么是云原生

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

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

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

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

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

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

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

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

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

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

長(zhǎng)會(huì)話，升級(jí)難

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

問(wèn)題：長(zhǎng)會(huì)話，最長(zhǎng)有 48 小時(shí)會(huì)議，升級(jí)困難。

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

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

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

現(xiàn)狀和未來(lái)：開源 SRS 改進(jìn)了退出邏輯，可以做到等待一定時(shí)間后退出。SRS 還做不到無(wú)狀態(tài)升級(jí)，因?yàn)橐龅綗o(wú)狀態(tài)化需要依賴存儲(chǔ)，而開源的 SLA 還不需要那么高。

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

未來(lái) GRTN (Tenfold) 還會(huì)做到狀態(tài)遷移和 K8S 的滾動(dòng)升級(jí)。

SLA 不同，遷移難

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SRS 云原生

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

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

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

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

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

總結(jié)

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

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