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

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

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

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

传统架构下的Radio Dream

技术层面的分层：

展示层—–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会根据就近原则，使用到达速度最快的节点进行拉取源文件。

选择HLS也是有两方面考虑

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)，咱们便可拉您进群