在 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 服務的全部挑戰。生生不息，填坑不止，後端服務就沒有做完的那一天。
「視訊雲技術」你最值得關注的音視訊技術公眾號，每週推送來自阿里雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。