关于kubernetes:扩展-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 服务的全副挑战。生生不息，填坑不止，后端服务就没有做完的那一天。

版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。