RTC服务架构演进——边缘云原生方向
Posted LiveVideoStack
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了RTC服务架构演进——边缘云原生方向相关的知识，希望对你有一定的参考价值。
音视频服务器要解决的核心问题是一样的，因此无论哪个公司的服务，都不会从0开始码代码，都会基于开源项目改。那么从开源到能提供商业服务，到底有哪些路要走？本次LiveVideoStackCon 2021 上海站中，我们邀请到了阿里云RTC传输网络负责人杨成立（忘篱）为我们从边缘云原生的角度详细解析RTC服务架构的演进。
文 / 杨成立（忘篱）
大家好，我是杨成立（忘篱），目前在阿里云负责RTC的传输网络，之前在蓝汛CDN负责直播的传输网络，这十年左右一直在做视频的后端服务，也是开源视频服务器SRS的作者，SRS目前是全球Top1的开源视频服务器。
后端服务都架构在云上，CDN的趋势也是边缘云，这是因为云计算成为各种服务的基础设施，当然也包括视频的后端服务。开发者可以便捷的直接使用云厂商的SDK和视频云服务，也可以使用开源方案在云上构建自己的系统。
我正好活跃在视频开源和云服务这两个领域，一直都有朋友询问这两个的差异，借这次机会正好分享下这个话题，希望通过这次分享，大家可以了解，从一个开源服务器，到可以提供服务的商业系统，到底有哪些路要走。
因为有些朋友不是做服务器的，我还是先介绍下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社区。
视频服务器的主要问题是：门槛高、领域广、更新快，开源和云服务不同步。
领域广：直播和RTC是互联网成规模的应用，其实还有监控和IoT发展也非常快，公有云、专有云、边缘云多个云的情况也不同，我们需要一个跨视频领域的服务器。Janus等专门的会议服务器，在超大规模上有结构性的问题（或者说这是直播要解的问题，所以Janus不需要解）。
更新快，开源和云服务不同步：视频比云服务发展更早，而云服务的很多要求，开源视频服务器并不满足，很多开源项目并不考虑云架构，因此从基于开源的自建系统，迁移到云就非常难。
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就差很多，不能用同样的机制做迁移。
流多且有关联，还有切网问题：直播的流之间没有关联性，可以在服务器负载高时调度新的会话到其他服务器，而RTC流之间有关联性，有时候不能随意调度，导致负载均衡很难做。
性能优化难：RTC必须加密，UDP在内核协议栈的性能低下，QoS算法的不断迭代消耗了性能。这让RTC的服务不再是单纯的IO密集型服务器，性能是整个系统的基础，影响其他所有的方面。
客户端版本和算法多，很难做回归测试。牵一发而动全身，很难知道一次修改，是否会导致客户端出问题，很难知道是否所有线上的大版本和小版本是否会出问题。
这些问题，前四个和云原生是有非常紧密的关系。后面几个问题，每个都是很大的话题，限于时间关系，我们会在以后给大家分享。
云的发展方向，不管是中心云、边缘云还是专有云，都是云原生方向。云本身就云里雾里，云原生更加云山雾罩了，我们可以看看云本身的思考。
可以说，开源项目如果做了云原生的改造和重新设计，具备了云架构的能力，就解决了商业化服务一个大问题。我们一起来看，需要做哪些改造。
长会话：RTC中最长有48小时的会议，甚至更长，直播有时候也是非常长时间推流，比如昨天雷军的视频号直播，折叠小米手机的折叠屏，连续直播折叠三天。这三天直播服务怎么升级？
为何重要：真正提供服务的线上系统，不是在升级，就是在升级的路上，一天到晚都是升级。是不可能完全停下来，中断服务，全量升级后再提供服务。长会话意味着必须支持无中断升级，否则就会造成不可用和服务中断的问题，严重影响客户体验。
扩缩容也会受到长会话的影响。业务量增长时，需要增加机器扩容，现有长会话无法迁移到新的机器，扩容只能应对新的流量。业务量降低后，可以缩容降低成本，如果长会话的周期，超过了业务周期，就无法实现缩容。
直播的业务质量，是按百分比计算，比如百分之N的卡顿是可以接受的。而在RTC中，会议中有一个人不可用，整个会议就无法继续。每个会议都很重要的，一个会议的重要性，并不一定低于另外一百个会议。
现状和未来：开源SRS改进了退出逻辑，可以做到等待一定时间后退出。SRS还做不到无状态升级，因为要做到无状态化需要依赖存储，而开源的SLA还不需要那么高。
GRTN(Tenfold)已经做到无状态化升级，可随时升级（当然会选择业务低峰期升级）。由于可以无状态重启，我们也顺便解决了Crash后恢复的问题，C++的程序，就像移动端的Crash率一样的，一定会有Crash。
未来GRTN(Tenfold)还会做到状态迁移和K8S的滚动升级。
中心、边缘、专有云SLA差异大：中心云的网络状况，基础设施的完善度很高，会话的迁移相对比较容易。而边缘和专有云的SLA就差很多，不能用同样的机制做迁移。
问题：没有100%的SLA，底层设施一定会出问题，迟早会出问题，宕机、IO Hang、网络不可用；中心、边缘、专有云，SLA差异大，迁移难。
为何重要：当底层基础设施出现问题，虽然概率不大，但一旦出现问题，服务就是不可用了。一台服务器不可用时，影响的不仅仅是这台服务器的会话，而是这个服务器上的所有会议，一个会议一般会跨多个服务器。
中心云的迁移，可用的基础设施比较完善。边缘云和专有云，网络状况和基础设施可靠性，不如中心云，迁移的难度更大。
现状和未来：SRS没有支持迁移，开源的SLA容忍度高一些，同类开源服务器也没有迁移能力；未来计划使用体验差的重连方案支持迁移。
GRTN(Tenfold)具备了底层迁移能力，预计今年可以支持中心云迁移。未来需要不断优化迁移能力，支持边缘云和专有云的迁移；还需要考虑计划中的迁移，比如流量再均衡。
端口和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)已经支持多级级联，跨区域级联，有粗略的水位评估。正在做精确的水位评估，未来会考虑做流量均衡。
总结来说，云原生解决的都是脏活累活，而且还是干不完的脏活累活。云原生往前走了一大步，让基础设施可以不断的标准化发展，应用只要遵守云原生的规范，就可以在多个云上悠然自得。
视频的门槛真的非常非常非常的高，还记得十一年前刚开始接触Flash和FFmpeg，仅仅各种概念和协议，就让人一头雾水。SRS希望能让视频的门槛不断降低，保持易用性让开发者少一些焦虑和压力，保持浓密的头发。
但，这不是RTC服务的全部挑战。生生不息，填坑不止，后端服务就没有做完的那一天。
The cover from creativeboom.com
讲师招募 LiveVideoStackCon 2021 北京站
LiveVideoStackCon 2021 北京站（9月3-4日）正在面向社会公开招募讲师，欢迎通过 speaker@livevideostack.com 提交个人及议题资料，无论你的公司大小，title高低，老鸟还是菜鸟，只要你的内容对技术人有帮助，其他都是次要的，我们将会在24小时内给予反馈。
以上是关于RTC服务架构演进——边缘云原生方向的主要内容，如果未能解决你的问题，请参考以下文章
云原生架构下的微服务选型和演进
构建云原生架构版图：安信证券服务化平台实践
云原生微服务治理技术朝无代理架构的演进之路
音视频架构演进：边缘计算与云原生
云计算与云原生 — 云原生微服务架构的技术内涵
云原生微服务架构的技术内涵
