最佳实践:如何扩展你的SRS并发能力?-阿里云开发者社区

开发者社区> 阿里云视频云> 正文
登录阅读全文

最佳实践:如何扩展你的SRS并发能力?

简介: 当我们用SRS快速搭建了视频服务,业务也开始上线运行了,很快就会遇到一个问题:如何支持更多的人观看?如何支持更多的人推流?这本质上就是系统的水平扩展能力,SRS当然是支持的,而且有多种扩展的方法,这篇文章就就详细分析各种扩展的方案,以及各种方案的应用场景和优缺点。

作者:忘篱
来源:SRS 开源服务器

image.png

从哪里开始

我们看最简单的视频服务,推一个流,只有一个播放器消费流,我们只需要一个 SRS Origin 源站服务就可以:

listen              1935;
max_connections     1000;
vhost __defaultVhost__ {
}

Remark:SRS 启动时默认就是 Origin 源站模式。

假设我们把 SRS 源站部署在杭州阿里云的 ECS 上,主播使用 OBS 在上海推流,观众在北京观看,如下图所示:
image.png

Remark:虽然地域较远,但 ECS 是 BGP 带宽,效果其实不错的。

Remark:虽然只有一台服务器,SRS 能支持 3K 个推流流,或者 7.5K 个播放,详细参考 SRS 的性能报告。

Note:可能你实测的数据不同,以上数据是在特定环境的结果,包括:流的码率,服务器 CPU 主频和带宽能力,选择的协议,SRS 的版本等差异影响。

如何支持更多的播放

不管是移动端 Native 播放的 RTMP/FLV,还是移动端浏览器播放的 HLS,或者 WebRTC 播放器,所有的视频服务最终是有播放的,在会议中叫订阅或与会者,本质上就是消费视频流。

在直播场景中,一个流会被非常多的播放器消费,比如一个球赛、国庆活动、一个电商大 V 的直播,直播对于播放的扩展能力是核心诉求,这也是 CDN 解决的关键问题之一,当然我们使用 SRS 也可以构建这样的能力,区别在于 CDN 的带宽成本会更低,而 SRS 一般部署在 BGP 云机房,网络稳定性更高但成本更高。

在会议或在线教育中,一个流可能不会被那么多人消费,比如一个 100 人的会议,可能一个视频流只会被另外 99 个人消费,如果在 MCU 模式下这些流会被合并后被其他与会者消费,如果开启语音激励或者用户选择,可能只有说话的人会被其他人消费,本质上和直播的连麦很像,在视频服务中大部分是不对等的情况,推流的少播放的多或者多太多。

在监控或者一对一聊天场景中,一个流会被少量的播放器消费,一对一就是一个播放器消费,监控可能更特殊些可能没有人消费只有在某些时候才会被消费,比如 GB28181 使用 SIP 协议,在有播放器消费流时才邀请摄像头把流送上来。

SRS 支持 Edge 边缘服务器,来扩展源站的支持播放的能力。我们将源站部署在阿里云杭州 ECS 上,主播从上海使用 OBS 推流,杭州我们需要支持 4K 播放,北京我们需要支持 8K 播放,我们就可以在杭州和北京部署 SRS 边缘服务器,如下图所示:
image.png

Remark:播放器如何找到对应的SRS边缘服务器,可以新增一个调度服务器,播放器请求调度服务器的HTTP API,调度返回边缘服务器的IP就可以。

Remark:调度服务也可使用DNS服务,现在云厂商一般也提供DNS服务,可以根据播放所在的区域,解析到对应的IP上。

这个结构是可以水平扩展的,一个 SRS 源站,最多可以支持 7K 个边缘节点。如果 7K 个节点不够,还可以使用多级边缘服务器,完成无数个节点的扩展能力。

SRS 如何用多个 CPU

SRS 使用单进程单线程模型,可以避免线程切换的消耗,也可以避免并发和竞争条件,所以默认情况下 SRS 只能使用一个 CPU,也就是虽然机器有 4 个 CPU 最高能跑到 400%,但 SRS 只能用一个 CPU 最高只能跑 100%。

当然这是默认情况,是有解法的:

  • 降低机器的 CPU 个数,比如申请 ECS 时只申请 2 个 CPU 的,这样就不会有多个 CPU 的烦恼了。

  • 使用 K8S 和 Docker 虚拟化资源,使用 Docker 跑 SRS,这样每个 SRS 最多用 100%,但可以跑多个 Docker。

  • 使用 SRS 的多进程和集群方案,如果确实需要使用多 CPU 能力,还是会有方案的,下面详细讲这种。

我们先考虑单个源站服务器如何使用多进程,比如 4CPU,单个 SRS 只能支持 7K 播放,我们可以扩展 4 倍能力到 28K 播放。单进程的部署结构如下:
image.png

源站的多进程部署结构如下:
image.png

Remark:这种部署结构只能扩展源站的播放能力,因为新增的是 Edge 服务器,流最终还是要回源到 Origin 服务器。

当然这种结构如果将源站单独部署到一台服务器后,就变成了上一章所讲的结构了,差异在于上一章的每个 Edge 服务器还是单进程,没有使用 Reuse Port 扩展多进程能力,这两个结构是可以结合起来用的,如下图所示:
image.png

Remark:在这个结构中,每个Edge服务器上也部署了多个SRS Edge进程,这样可以将边缘服务器的多核能力用起来。

到目前为止,我们更多关注的是播放的扩展能力,如何扩展推流能力呢?下面开始讲这个。

如何收更多的流

推流能力,一般也叫收流的能力,因为推流就是指客户端将流推送到 SRS,而从 SRS 角度看就是把客户端的流收了提供服务。

在 SRS 的角色中,Edge 主要解决播放或下行的扩展能力,而 Origin 则是解决上行或推流的扩展能力。

Origin 源站提供了多个方案来实现扩展,按照上面的场景,我们假设杭州有 3K 的主播,为了业务稳定性我们不能部署一个 Origin 服务器来支持 3K,这会导致 CPU 跑得比较高,而且一般源站还需要录制或转 HLS,需要预留一些 CPU 出来做其他业务。

SRS 支持 Vhost,可以将流分成不同的逻辑域,比如 3K 个流,我们可以分成 2 个 Vhost,这样每个 Vhost 的流只有 1.5K,可以推流到 2 个源站,如下图所示:
image.png

Remark:我们用两个颜色区分了两个 Vhost,对于 Edge 来说不同的 Vhost 可以回源到不同的 Origin,所以可以从同一个 Edge 播放不同的 Vhost 的流。

Note:图中播放器连接的是 Edge 服务器,实际上推流也可以推到边缘的,没有必要必须推源站。

Note:建议客户端连接 Edge,而不直接连接 Origin,这样可以获得更好的一致性,比如播放时只需要加 Query 参数指定 vhost 就可以,而不用关心 Origin 会根据不同 Vhost 有不同的地址。

Note:Vhost 的优势是完全独立的源站,不会互相干扰,在客户端指定了 vhost,相当于在客户端做了负载均衡,系统结构比较简单,劣势是业务是有感知的。

如果业务不按照 Vhost 区分,或者一个 Vhost 的流也非常多,那么 SRS 提供了 Origin Cluster 源站集群扩展源站,如下图所示:
image.png

Remark:两个 Origin 服务器之间会互相查询流,若 Edge 请求的流不在本源站上,会将 Edge 定向到有流的 Origin,详细请参考 OriginCluster 的 WIKI 说明。

Note:同样的,建议不要直接推流到 Origin,而推流到 Edge。

Note:源站集群优势是部署时比较简单,不需要根据业务配置 Vhost,劣势是源站之间是需要互相访问的。

值得说明的是,由于源站是流的最终所在地,所以他本质上是有状态的,两个源站并不是完全等价的。而边缘可以认为是合并回源的代理,两个 Edge 是没有差别的,它们并没有存储流的信息,都是通过源站获取流。因此,推流的扩展能力,比播放的扩展能力,对系统的挑战是更大的。

在监控领域,可能有 10 万或 100 万摄像头,如果需要把这些摄像头的流全部推送到服务器处理,那这个量级还是非常的大的。一般会在本地处理后,再把流送到服务器,比如图像识别到摄像头有活动,可以把信息送到服务器,需要观看这个流后,再把流送到服务器。

不建议的做法

发现还是会有少对 SRS 的误用,这里列出来一些不建议的做法:

  • 不建议 Forward,Forward 并不是扩展集群的能力,而是把流复制一份给别的系统,一般在系统迁移,或者需要两个系统有同样的流时,才需要用 Forward。

  • 不建议在边缘切 HLS 和 DVR,因为边缘没有流,所以无法切片 HLS,只能在有播放 RTMP 或 FLV 时,才会去把流拉到边缘。所以如果边缘做 HLS 切片,会发现播放 HLS 前要播放 RTMP,这是很奇怪的做法。

  • 不建议把所有业务放一台服务器,比如有些流是指需要出 HLS,有些流只需要 DVR,有些流只需要 FLV,那么这些流就应该分成不同的 Vhost,送到不同的源站处理,这样可以避免互相干扰。比如 HLS 和 DVR 需要写磁盘,可能会导致 IO 负载高,可能会影响到 FLV 流。

  • 不建议把业务做到 SRS 中,比如无人播放时停止推流,那么不应该让 SRS 断开连接,而应该业务系统观察到无人播放时,通知推流停止推流。这样可以让 SRS 集中在流媒体处理,而不是因为业务代码 Crash。

  • 不建议 Edge 前面挂 F5 或 Proxy,Edge 本身就是 Proxy,再挂个 Proxy 意欲何为呢,流量一点都没有节省。有些可能是为了让客户端访问的 IP 保持一致,那么可以用 DNS 域名方式,这样客户端看到的都是一个 DNS 名称,会解析成不同的 Edge 的 IP。

还有些值得特别说明的:

  • 以上扩展能力,可以组合使用,比如源站可以是单个 SRS,也可以用一个 Origin 和多个 Edge 组成小集群源站,再让 Edge 使用 Reuse Port 对外就是一个 IP 和端口。

  • Edge 拉流可以支持多个协议,对于扩展同样是适用的,比如 WebRTC 也可以使用 Edge 扩展播放的能力,同样 GB28181 推流后播放的协议和源站架构无关。但目前 WebRTC 推流和源站集群的能力还在开发中。

  • 一般来说,Edge 就是为了扩展播放的能力,但推流也可以走 Edge 这是为了让推流的地址更简单,而不用关注 Origin 的部署结构。一般来说,源站 Origin 是为了扩展收流的能力,但对于 WebRTC 这种结构,可能没有固定的 Origin 和 Edge,它可能需要的是一种切换角色的能力。

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

阿里云社区.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

分享视频云行业和技术趋势,打造“新内容”、“新交互”。

官方博客
官网链接