扩展 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 服务的所有挑战。生生不息，填坑不止，后端服务就没有作完的那一天。

「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。