Radio Dream流媒体直播平台基于Docker的应用

摘要：支持等主流流媒体格式。控制中心会给直播服务器这些信息，直播服务器调用自身的直播流，分发到各个切片服务器。自动化运维故障恢复这部分主要是监控推流，和切片，以及直播源是否正常。

本文整理自【时速云微信群线上分享】第十一期

首先介绍一下背景，Radio Dream项目是一个开源项目，前身为五雷轰顶网络电台，这个项目是我个人逐渐打磨了将近两年，最开始是因为猫扑网络电台停播，我个人是猫扑电台的老听众，很舍不得这个平台，后来想想，干脆自己做一个网络电台，就是因为这些想法催生了这个项目的成立。

说完背景开始聊聊这个电台的架构，我们从流媒体协议选型到架构实现等多个方面拆分的讲解这个平台实现方法，另外时速云镜像仓库里Radio Dream的镜像demo，总体来说这套系统部署起来还是十分复杂，虽然对系统要求极其低，单核心CPU，128M内存，20GB左右的硬盘就能跑起来，但是从最开始的架构设计我就打算做成一个集群化的方案，方便动态扩容，服务更多用户，由于我个人比较懒，所以做了很多自动化运维的工作，这样我就可以解放双手和更多的时间去开发新的功能。

展现层—–WEB页面，第三方集成代码，后台管理
逻辑层—–媒体分发调度，直播监控，故障判断
执行层—–流媒体直播执行，ffmpeg推流，拉取
媒体层—–对媒体直播处理，切片

1.Radio dream控制中心

Radio dream控制中心是整个电台播控集群的核心控制端，负责整个集群调度，处理故障服务器，监控直播流，录播调度，微直播调度等相关任务。

2.直播控制

直播控制组件是负责通知录播推流集群停止推流和继续推流，由于直播服务器只支持单流推送，所以需要一个控制端来进行控制本地推送服务，当点击页面开始直播，推流服务器就会停止工作，RTMP服务就会等待主播编码器链接推送音频。点击结束直播，推流服务就会开始工作。

3.媒体管理中心

媒体管理中心负责服务器内所有的AAC音频文件管理，例如上传，下载，删除，审核，试听，分发URL，CDN分发部分。

4.录播控制

录播控制组件是控制本地音频文件转换成流的方式进行伪直播。

5.转播控制

转播控制是在不替换现有直播架构方式进行试用新的解决方案的方法，另外可以转播别的电台直播节目。支持RTMP、MMS、RTSP、HLS等主流流媒体格式。

6.录播分发

录播分发是提供下载和在线收听等功能。

7.RTMP接收

RTMP接收组件是整个直播服务集群最为核心部分，负责接收录播端和主播端的直播音频部分。

8.切片服务

切片服务组件是接收RTMP流过来后转换成HLS的TS切片，并且生成M3U8格式的播放列表，实现HTTP方式的流媒体。

9.分发服务

分发服务（边缘服务器）是负责整个流媒体切片和录播的文件进行对外分发，如果是分布式架构，此处根据自己用户量大小进行带宽调整。国际广播格式48Kbps单用户收听1小时消耗带宽18MB，可以根据此公式计算。

集群工作流程，首先一个问题

主播不可能24小时在线，没有主播时段会有很长的空白期，这段时间用户如果想收听，没有节目肯定不行

解决办法：那么我们就做了一个伪直播的功能，通过把本地文件转成直播流的方式，推送到直播服务器，这样用户收听就不会出现空白期

直播录播切换，如何去做才能实现无缝切换，让听众“无感切换”

解决方案：直播流是使用ffmpeg进行本地文件读取，推送到rtmp直播服务器，主播点击直播按钮，会请求一个API，这个API会调用一个shell脚本，杀死推流进程，主播的直播流就会推送到服务器上，直播服务器会把这个流推送到各个分发、切片服务器。

然后我们分享架构流程，大家可以看一下上面的图

首先我们的“伪直播服务”是全天工作的，有主播连线直播后，会杀死伪直播的服务，直播流会迅速的连上，因为分发部分使用的是HLS协议进行分发，所以会有10秒左右的延迟，而且有直播服务器和切片服务器两个中间层，用户根本不会感觉到有顿卡，直播就已经切换成了真正的直播.

直播服务器会推送本地的直播流到切片服务器，切片服务器一般会有多台，这个是通过调度API进行获取推流服务器的IP地址，端口、application、直播名称等信息。每个切片服务器启动时候都会通告控制中心自身的IP地址、服务状态、监听端口、application名称、直播名称。控制中心会给直播服务器这些信息，直播服务器调用自身的直播流，分发到各个切片服务器。

切片服务器会对推送过来的流进行切片生成TS文件，并且生成M3U8的索引文件，遵循HLS直播协议进行分发。

由于切片服务器有多个，所以和CDN服务对接时候使用多个IP地址，CDN会根据就近原则，使用到达速度最快的节点进行拉取源文件。

a) RTMP的并发性并不好
b) 节约成本

我测试过，现有实现rtmp直播最多支持2000个用户拉取流，而且CPU占用会很高，由于网络电台会延迟的敏感性并不是特别高，所以选择HLS，因为HLS是走http协议，这样就可以使用nginx实现大规模并发。

节约成本这块主要是CDN成本，支持rtmp的CDN厂商一般价格会比http请求流量贵35%左右，使用http就会节省一部分成本。

自动化运维&故障恢复

这部分主要是监控rtmp推流，和hls切片，以及直播源是否正常。

工作流程：

检测分发m3u8索引文件是否存在,如果是单台节点不存在，证明单点故障，会检测rtmp源否推送正常，如果正常，则会重启一下服务，然后进行一次检查，7秒钟后，还没有检查到M3U8文件索引，会传输故障恢复脚本，进行一次常见故障恢复.

例如，检查文件权限，检查内部是否可以拉取到源，检查内部是否可以获取到m3u8文件，然后进行恢复，如果恢复都不成功，就会发送通告到控制中心，当前服务器已经不工作，控制中心会将这台机器剔除服务集群，通告CDN厂商API，将这台机器剔除，直播服务器也不会对这个服务进行推送，然后调用云主机API，将这台系统进行重装系统，分发当前角色的自动化部署脚本.

部署完毕后，会通告控制中心，进行一次试推送，检查如果正常，会把这个服务器加回到服务集群队列。如果检查不正常，则会尝试三次，三次后，还不能够恢复，就会发短信到手机通告故障问题。需要人工介入排查。

其他服务节点类似，

● 故障难以恢复

● 浪费资源

● 价格过高

● 高可用过度依赖于自身监控

容器的出现恰恰解决的这些问题，尤其对故障恢复方面，有着对传统虚拟机无与伦比的优势，首先启动速度快，故障不会和传统虚拟机一样装机时间很漫长。秒级启动的容器，非常适合大规模部署，只要制作好相应服务的镜像。

故障难以恢复：

虽然自动化运维听着很高大上，但是其中的苦逼只有自己知道，我现在整个电台的自动恢复服务有47个脚本，每一个都一堆的逻辑判断，我自己改写起来都得读很长时间，容器方式实现这种微服务方式就不会有这些问题，哪个服务挂了，直接删除容器，重启一个就完事了。

资源浪费：

其实每个服务都可以拆分成很多小服务，而且资源占用都极低，Docker容器启动，内存占用只有一个shell，和宿主机共用一个内核，这样就保证了，只有应用在使用内存，不会启动多个内核和系统服务造成资源的重复浪费。

价格过高：

传统的VPS都是按月计费，这样如果突发性用户过多，而且每天只有6点-10点左右用户量会增加，平时如果开着这么多服务器来处理很少的用户很不划算，但是时速云的容器可以实现秒级计费，系统负载过高了，直接多开几个容器就OK了，用户少了删除一些容器，只保证最低使用量。

高可用过度依赖于自身监控:

传统VPS挂了那就挂了，不会发短信警告和重启VPS，但是容器挂掉会自动重启，内存占用过高等问题，时速云会直接发邮件&短信通知，这样本身的监控压力就会小很多，只需要关注业务层面的问题，而不需要过多的关注系统底层的问题。

时速云使用demo：

首先在镜像市场搜索radiodream镜像，如果只是选择做测试可以不挂载存储卷

成功启动后，查看地址，查看1935映射对应端口是什么

打开vlc播放器或者potpplayer，输入rtmp://xxxx.xxx.xxx:xxx/radiodream/live,就可以收到伪直播节目了,更多的设置选项请观看时速云官方视频教程 https://tenxcloud.com/tutorial

如何参与线上分享？
添加微信号：时速云小助手(tenxcloud6)，我们即可拉您进群