4.2 错误&日志
上图展示了SRS的日志,其中存在进程号与ID。一个ID代表服务器上的一个连接,一个服务器为成百上千个用户与进程提供服务,ID用于定位问题出现的位置与所属上下文日志。流媒体与HTTP不同,作为传输流存在上下文。长时间的数据交换使得其日志不仅仅只有一条,中间发生的事情都会通过日志来呈现。特别是RTC的日志非常多,如何从服务器中摘取关键信息?其实SRS设计了一套机制,也就是知道每个用户的日志究竟是什么,并及时从中摘取出。
除了日志之外,上图还展现了SRS中的错误反馈,错误参考了Go的机制,因为Go中出现错误可以Wrap打包错误,这样大家在反馈错误时就可以粘贴相应日志,就可以知道堆栈是什么。常规情况下出现错误只会呈现一个错误码,开发者并不知道究竟发生了什么。但如果有错误相应的堆栈以及给出每一层堆栈的变量,查询定位错误的过程就会变的非常方便。一般在关注一个新的开源项目时大家不太会关注这个问题。但当问题出现需要大家去查找问题源头时,堆栈的作用非常关键。这意味着我们不仅能够确定该问题的源头,也能妥善解决问题。
5. 高性能
性能是一项基础要求,一般情况下SRS的性能是其它服务器的两倍左右。对性能的要求在RTC中其实会更严苛,因为RTC的性能消耗更多。
6. SRS发展
关于SRS的发展,从2013年开始SRS一直都在稳步发展。初期由于应用场景相对固定,更新力度并不大。而现在,随着Original Cluster边缘集群相继得到支持,直播场景的覆盖也愈发完善,RTC也在不断发展。大家可以看到最近各个视频行业都在互联网化,因此最近SRS的活跃度也非常高。
2019年左右,SRS-Forks超越了NGINX-RTMP,预计未来SRS-Forks的增长是NGINX-RTMP的两倍。
回顾SRS的发展脉络,2013年v1.0实现了对直播基础协议的支持如RTMP、HLS等。随后的v2.0则主要支持FLV等以及移动互联网应用,v3.0则提供了对Original Cluster的支持,同时很早就提供了对边缘集群的支持,边缘集群主要应对很多人播放的场景。而Original Cluster则主要用于支持流播,例如监控摄像头等。边缘不会存储流而Original Cluster则会存储流,所以需要集群的存在,目前对直播场景的支持相对完善