当前位置:主页 > 查看内容

扩展 GRTN:云原生趋势下的 RTC 架构演进

发布时间:2021-04-24 00:00| 位朋友查看

简介:后端传输网络是 RTC 系统的核心能力 比如阿里云的 GRTN、声网的 SD-RTN 等。本文介绍了阿里云视频云如何不断改进 RTC 架构 扩展 GRTN 网络 并基于云原生技术获得云的强大能力。 个人介绍 大家好 我是杨成立 忘篱 目前在阿里云负责 RTC 的传输网络 之前在蓝汛……

后端传输网络是 RTC 系统的核心能力 比如阿里云的 GRTN、声网的 SD-RTN 等。本文介绍了阿里云视频云如何不断改进 RTC 架构 扩展 GRTN 网络 并基于云原生技术获得云的强大能力。

个人介绍


大家好 我是杨成立 忘篱 目前在阿里云负责 RTC 的传输网络 之前在蓝汛 CDN 负责直播的传输网络 这十年左右一直在做视频的后端服务 也是开源视频服务器 SRS 的作者 SRS 目前是全球 Top1 的开源视频服务器。

image.png

后端服务都架构在云上 CDN 的趋势也是边缘云 这是因为云计算成为各种服务的基础设施 当然也包括视频的后端服务。开发者可以便捷的直接使用云厂商的 SDK 和视频云服务 也可以使用开源方案在云上构建自己的系统。


我正好活跃在视频开源和云服务这两个领域 一直都有朋友询问这两个的差异 借这次机会正好分享下这个话题 希望通过这次分享 大家可以了解 从一个开源服务器 到可以提供服务的商业系统 到底有哪些路要走。


RTC 服务介绍

因为有些朋友不是做服务器的 我还是先介绍下 RTC 服务是什么吧。


直播经过这些年的发展 大家都理解需要后端服务 比如 OBS 推流 是不能直接推给播放器的 而是经过 CDN 转发 CDN 就是直播的后端服务了。


RTC 是大不相同的 比如 WebRTC 本身设计是通话 通话场景大部分时候都是一对一的对话 所以 WebRTC 设计了多种传输方式 比如直接 P2P、通过 STUN 转发、通过 SFU 或 MCU 转发。


如果只是跑 DEMO 那么不用 RTC 服务器 直接 P2P 也是可以跑起来的。真实线上 肯定是要经过服务器 现在使用最广的是 SFU 转发。主要原因如下

image.png

P2P 打不通 有些网络是对称 NAT 两个客户端在各自的内网无法通过 P2P 打通 就必须使用服务器中转流。

跨网远距离传输 比如跨国传输 或者跨运营商 客户端直接 P2P 就算能连通 效果也不好 如果经过服务器可以优化传输线路。

会议转直播 如果需要对媒体进行处理 比如将 RTC 转直播 广播给更多观众 就需要转码和转协议 这也必须要服务器处理。

录制精彩片段 目前的录制和剪辑等内容的处理 在互联网上还是 RTMP 对接比较多 将 RTMP 流送到录制或剪辑系统。

不同客户端网络状况不同 有些客户端网络好 有些差 通过服务器可以精确计算不同客户端的网络情况 给客户端传输不同的质量的流。

兼容老客户端和协议 线上客户端的版本非常多 随着迭代 可能支持的协议也不一样 需要服务器做兼容处理。


各家云厂商都有自己的后端服务 比如阿里云的 GRTN 声网的 SD-RTN 等等。实际上传输网络并不等于传输服务器 而是一个传输的系统 包括调度、路由、协议处理、发布和维护、问题排查、数据分析等等。


AliRTC 阿里云 RTC 的传输网络 传输协议使用 GRTN 除了 GRTN (CDN) 的网络 我们还扩展实现了 GRTN (Tenfold) GRTN (Tenfold) 补充了 BGP 专线、ENS、专有云网络、第三方云支持 K8S 的云网络等 适应多种不同场景的传输要求。

image.png

其中 GRTN (Tenfold) 就是基于 SRS 做的 增加了很多能力 有些已经反馈给了 SRS 社区。

为何选择 SRS


下面介绍下 SRS 以及我们为何要选择 SRS。


视频服务器的主要问题是 门槛高、领域广、更新快 开源和云服务不同步。


门槛高 由于视频的技术栈很深 信号处理、编解码、传输、客户端平台 每个方向都有很深的技术栈 必须要有专门的视频服务器。业内知名的 Nginx 本质上并不是做视频的 Web 和视频差别非常大。


领域广 直播和 RTC 是互联网成规模的应用 其实还有监控和 IoT 发展也非常快 公有云、专有云、边缘云多个云的情况也不同 我们需要一个跨视频领域的服务器。Janus 等专门的会议服务器 在超大规模上有结构性的问题 或者说这是直播要解的问题 所以 Janus 不需要解 。


更新快 开源和云服务不同步 视频比云服务发展更早 而云服务的很多要求 开源视频服务器并不满足 很多开源项目并不考虑云架构 因此从基于开源的自建系统 迁移到云就非常难。


为什么这个问题很重要


影响视频在各个领域的落地 阻碍新场景的发展。新场景一定是跨领域的 不会有只做直播或只做 RTC 的情况 新领域并不是直播简单的渗透 而是互联网视频的渗透 只有跨领域的开源项目 才能推动新场景的发展和落地。


无法使用云服务能力。云架构最厉害在于弹性 而且是标准的跨云的弹性。如果开源项目本身不考虑云架构 就无法迁移到云也没有弹性能力。开源的云架构并不是把开源在云主机中运行 就是云架构。


多云迁移困难。云的方向是应用上云的标准化 (K8S) 可以在多个云之间无缝迁移 这给应用非常高的可靠性。如果开源项目本身不做 K8S 所要求的改造 就无法在多个云之间迁移。


SRS 如何解决这个问题 SRS 的定位是云原生的视频服务器 应对云原生做了大量改造 可以非常方便上云和迁移。


除了云原生的能力 SRS 也是非常高性能的开源服务器。当然性能没有最高只有更高 每个大版本都需要做性能优化 然后用性能交换功能和用户体验。

image.png

特别说明下 这里并不是说 Nginx 和 Janus 就做不到 SRS 的并发 只是目前的版本压测出来的数据。性能和行业背景是非常相关的 比如 2012 年大多是千兆网络时代 所以 Nginx 的性能足够能打满带宽了。而 Janus 同类的服务器差不多都是 Janus 这个量级。SRS 之所以一直重视性能是因为互联网很关注成本 成本必须使用性能交换。


今年是 SRS 第八个年头 去年已经成为开源视频服务器的 Top1 主要还是因为国内的视频行业发展很快 另外活跃的视频开源服务器比较少。

image.gifimage.png

这里说点八卦 这次疫情给全球经济带来很大影响 也带来了互联网视频的大爆发 比如直播、教育、会议、云游戏、IoT 等等。大家只能在家活动 所以互联网成了大家交流的重要方式 各个开源项目也在 20 年初有很大的增长 比如 Janus。


很可能这是我们唯一会经历的黑天鹅了 我之前一直有个疑问 就是疫情结束后 是否互联网视频会回到解放前 从 Janus 的增长速度看 半年后增长的速度回落到疫情前了。这也许也说明了 就算是做开源也不能依赖这种事件。


SRS 的快速增长是在 19 年底 这个时间点也是 SRS 支持 WebRTC、SRT 和 GB28181。所以也分不清多少是疫情的拉动 多少是因为 SRS 自己的努力。好消息是 SRS 的增长并没有回落 而且是目前增长最快的开源视频服务器项目。持续的增长和全球 Top1 这不是结束 而是一个新的开始。

image.png

我们认为只有公众号订阅的开发者超过 100K 才能有机会提升了整个视频行业开发者的创造力。只有达到 100K 的 Star 才能叫互联网视频的标准开源服务器。只有不断推动新场景的 DEMO 和探索 才能不断拓展视频的边界。


SRS 是一个雄心勃勃的开源项目 十年的 OKR 是个挺大的目标。如果我们看三十年后 那么有三代新的开发者进入视频行业 而随着视频成为互联网基础设施的一部分 那么这个目标也不算是很大 最大的问题可能是在于 SRS 能否活够 30 年吧。


什么是云原生


回到今天的主题 从开源 SRS 到商业服务 还需要解决哪些问题。

image.png

长会话 RTC 中最长有 48 小时的会议 甚至更长 直播有时候也是非常长时间推流 比如昨天雷军的视频号直播 折叠小米手机的折叠屏 连续直播折叠三天。这三天直播服务怎么升级


中心、边缘、专有云 SLA 差异大 中心云的网络状况 基础设施的完善度很高 会话的迁移相对比较容易。而边缘和专有云的 SLA 就差很多 不能用同样的机制做迁移。


端口和 IP 复用 传统 RTC 一般是内网应用 有可以随便使用的 IP 可以分配几万个随机端口 这些在云上有安全隐患 公网 IPv4 地址不能随意用 扩容就很难做。


流多且有关联 还有切网问题 直播的流之间没有关联性 可以在服务器负载高时调度新的会话到其他服务器 而 RTC 流之间有关联性 有时候不能随意调度 导致负载均衡很难做。


性能优化难 RTC 必须加密 UDP 在内核协议栈的性能低下 QoS 算法的不断迭代消耗了性能。这让 RTC 的服务不再是单纯的 IO 密集型服务器 性能是整个系统的基础 影响其他所有的方面。


客户端版本和算法多 很难做回归测试。牵一发而动全身 很难知道一次修改 是否会导致客户端出问题 很难知道是否所有线上的大版本和小版本是否会出问题。


这些问题 前四个和云原生是有非常紧密的关系。后面几个问题 每个都是很大的话题 限于时间关系 我们会在以后给大家分享。

云的发展方向 不管是中心云、边缘云还是专有云 都是云原生方向。云本身就云里雾里 云原生更加云山雾罩了 我们可以看看云本身的思考。

image.gifimage.png

可以说 开源项目如果做了云原生的改造和重新设计 具备了云架构的能力 就解决了商业化服务一个大问题。我们一起来看 需要做哪些改造。

长会话 升级难


长会话 RTC 中最长有 48 小时的会议 甚至更长 直播有时候也是非常长时间推流 比如昨天雷军的视频号直播 折叠小米手机的折叠屏 连续直播折叠三天。这三天直播服务怎么升级

image.gifimage.png

问题 长会话 最长有 48 小时会议 升级困难。


为何重要 真正提供服务的线上系统 不是在升级 就是在升级的路上 一天到晚都是升级。是不可能完全停下来 中断服务 全量升级后再提供服务。长会话意味着必须支持无中断升级 否则就会造成不可用和服务中断的问题 严重影响客户体验。


扩缩容也会受到长会话的影响。业务量增长时 需要增加机器扩容 现有长会话无法迁移到新的机器 扩容只能应对新的流量。业务量降低后 可以缩容降低成本 如果长会话的周期 超过了业务周期 就无法实现缩容。


直播的业务质量 是按百分比计算 比如百分之 N 的卡顿是可以接受的。而在 RTC 中 会议中有一个人不可用 整个会议就无法继续。每个会议都很重要的 一个会议的重要性 并不一定低于另外一百个会议。


现状和未来 开源 SRS 改进了退出逻辑 可以做到等待一定时间后退出。SRS 还做不到无状态升级 因为要做到无状态化需要依赖存储 而开源的 SLA 还不需要那么高。


GRTN (Tenfold) 已经做到无状态化升级 可随时升级 当然会选择业务低峰期升级 。由于可以无状态重启 我们也顺便解决了 Crash 后恢复的问题 C 的程序 就像移动端的 Crash 率一样的 一定会有 Crash。


未来 GRTN (Tenfold) 还会做到状态迁移和 K8S 的滚动升级。


SLA 不同 迁移难


中心、边缘、专有云 SLA 差异大 中心云的网络状况 基础设施的完善度很高 会话的迁移相对比较容易。而边缘和专有云的 SLA 就差很多 不能用同样的机制做迁移。

image.png

问题 没有 100% 的 SLA 底层设施一定会出问题 迟早会出问题 宕机、IO Hang、网络不可用 中心、边缘、专有云 SLA 差异大 迁移难。


为何重要 当底层基础设施出现问题 虽然概率不大 但一旦出现问题 服务就是不可用了。一台服务器不可用时 影响的不仅仅是这台服务器的会话 而是这个服务器上的所有会议 一个会议一般会跨多个服务器。


中心云的迁移 可用的基础设施比较完善。边缘云和专有云 网络状况和基础设施可靠性 不如中心云 迁移的难度更大。


现状和未来 SRS 没有支持迁移 开源的 SLA 容忍度高一些 同类开源服务器也没有迁移能力 未来计划使用体验差的重连方案支持迁移。


GRTN (Tenfold) 具备了底层迁移能力 预计今年可以支持中心云迁移。未来需要不断优化迁移能力 支持边缘云和专有云的迁移 还需要考虑计划中的迁移 比如流量再均衡。


端口和 IP 复用 扩容难


端口和 IP 复用 传统 RTC 一般是内网应用 有可以随便使用的 IP 可以分配几万个随机端口 这些在云上有安全隐患 公网 IPv4 地址不能随意用几万个 扩容就很难做。

image.png

问题 安全要求只能开固定的端口 企业防火墙只能开特定的端口 不能开一定范围端口 比如 10000 到 20000 端口。


为何重要 不符合安全规范 无法通过安全审核。多端口更容易被攻击 如果出现安全事故 比一台服务不可用还要严重 这也是为何 WebRTC 正在做 E2E 端到端 加密的原因。


有些用户在企业防火墙后面 访问公网时不能访问任意端口 必须收敛到某些 IP 和端口。如果不支持端口复用 就无法在这些企业场景下使用。


端口本质上是一种状态 它是一种对用户的标示 比如 IP 端口就可以认为是某个客户端。这也给服务迁移带来问题 需要迁移更多的状态。


现状和未来 云原生的标准做法 是通过 SLB/Service 隐藏服务 流量通过 SLB 转发到真实的 Pod 服务器。SRS 已经支持了这种方式。


线上还有移动端切网问题 会影响 SLB 定位客户端。SRS 目前使用 ICE 的 PingPong 标示客户端 未来和更好的做法是用 QUIC QUIC 协议本身考虑了会话的标示 在 SLB 层就可以解决问题。


GRTN (Tenfold) 还支持了 TURN 协议的 SLB 转发。未来还需要解决在边缘云中的端口复用问题 和中心云不同 边缘云可能是分运营商的 客户端切网后需要更换 IP 入口。

流多且关联 负载均衡难


流多且有关联 还有切网问题 直播的流之间没有关联性 可以在服务器负载高时调度新的会话到其他服务器 而 RTC 流之间有关联性 有时候不能随意调度 导致负载均衡很难做。


image.png

image.gif

问题 流有关联性 服务的会话数不变 负载可能会突增。流的关联性 码率的波动 以及 QoS 算法的动态变化 导致水位评估不准 会话数目不增加时 消耗的 CPU 和带宽都不同。


为何重要 水位如果无法精确评估 就只能预留较多资源 保持较低的水位运行 避免水位突增 服务器被打爆。保持较低水位导致整体成本高。


现状和未来 SRS 还没有解决这个问题 正在做 QUIC 级联 未来会考虑给出服务器的水位 但不会做流量调度和负载均衡 这个是系统要做的。


GRTN (Tenfold) 已经支持多级级联 跨区域级联 有粗略的水位评估。正在做精确的水位评估 未来会考虑做流量均衡。

SRS 云原生


总结来说 云原生解决的都是脏活累活 而且还是干不完的脏活累活。云原生往前走了一大步 让基础设施可以不断的标准化发展 应用只要遵守云原生的规范 就可以在多个云上悠然自得。

image.png

视频的门槛真的非常非常非常的高 还记得十一年前刚开始接触 Flash 和 FFmpeg 仅仅各种概念和协议 就让人一头雾水。SRS 希望能让视频的门槛不断降低 保持易用性让开发者少一些焦虑和压力 保持浓密的头发。


但 这不是 RTC 服务的全部挑战。生生不息 填坑不止 后端服务就没有做完的那一天。


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

image.png


本文转自网络,原文链接:https://developer.aliyun.com/article/783743
本站部分内容转载于网络,版权归原作者所有,转载之目的在于传播更多优秀技术内容,如有侵权请联系QQ/微信:153890879删除,谢谢!

推荐图文

  • 周排行
  • 月排行
  • 总排行

随机推荐