RTC服务架构演进——边缘云原生方向

LiveVideoStack 2021年5月15日

音视频服务器要解决的核心问题是一样的,因此无论哪个公司的服务,都不会从0开始码代码,都会基于开源项目改。那么从开源到能提供商业服务,到底有哪些路要走?本次LiveVideoStackCon 2021 上海站中,我们邀请到了阿里云RTC传输网络负责人杨成立(忘篱)为我们从边缘云原生的角度详细解析RTC服务架构的演进。


文 / 杨成立(忘篱)


01 个人介绍


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


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


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


02 RTC服务介绍


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


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


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


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

RTC服务架构演进——边缘云原生方向


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

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

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

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

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

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

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


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

RTC服务架构演进——边缘云原生方向


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


03 为何选择SRS


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


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


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


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

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


为什么这个问题很重要?


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


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

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


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


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

RTC服务架构演进——边缘云原生方向


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


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

RTC服务架构演进——边缘云原生方向


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


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


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

RTC服务架构演进——边缘云原生方向


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


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


04 什么是云原生


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

RTC服务架构演进——边缘云原生方向


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

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

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

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

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

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

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


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

RTC服务架构演进——边缘云原生方向


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


05 长会话,升级难


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

RTC服务架构演进——边缘云原生方向


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


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


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


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


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


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


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


06 SLA不同,迁移难


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

RTC服务架构演进——边缘云原生方向


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


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


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


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


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


07 端口和IP复用,扩容难


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

RTC服务架构演进——边缘云原生方向


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


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


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


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


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


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


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


08 流多且关联,负载均衡难


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

RTC服务架构演进——边缘云原生方向


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


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


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


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


09 SRS云原生


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

RTC服务架构演进——边缘云原生方向


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


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


还可输入800
全部评论
作者介绍

杨成立

阿里云

RTC服务器团队负责人

文章

粉丝

视频

阅读排行
  • 2周
  • 4周
  • 16周
热门视频

Monibuca的架构演进

李宇翔/Web端实时音视频SDK开发