radio dream流媒体直播平台基于docker的运用.docxVIP

Radio Dream流媒体直播平台基于Docker的应用 Radio Dream项目是一个开源项目，前身为五雷轰顶网络电台，这个项目是我个人逐渐打磨了将近两年，最开始是因为猫扑网络电台停播，我个人是猫扑电台的老听众，很舍不得这个平台，后来想想，干脆自己做一个网络电台，就是因为这些想法催生了这个项目的成立。 关于这个电台的架构，我们从流媒体协议选型到架构实现等多个方面拆分的讲解这个平台实现方法，另外时速云镜像仓库里Radio Dream的镜像demo，总体来说这套系统部署起来还是十分复杂，虽然对系统要求极其低，单核心CPU，128M内存，20GB左右的硬盘就能跑起来，但是从最开始的架构设计我就打算做成一个集群化的方案，方便动态扩容，服务更多用户，由于我个人比较懒，所以做了很多自动化运维的工作，这样我就可以解放双手和更多的时间去开发新的功能。 传统架构下的Radio Dream 技术层面的分层： 展现层-----WEB页面，第三方集成代码，后台管理 逻辑层-----媒体分发调度，直播监控，故障判断 执行层-----流媒体直播执行，ffmpeg推流，拉取 媒体层-----对媒体直播处理，切片 业务逻辑分层 Radio dream控制中心 Radio dream控制中心是整个电台播控集群的核心控制端，负责整个集群调度，处理故障服务器，监控直播流，录播调度，微直播调度等相关任务。 直播控制 直播控制组件是负责通知录播推流集群停止推流和继续推流，由于直播服务器只支持单流推送，所以需要一个控制端来进行控制本地推送服务，当点击页面开始直播，推流服务器就会停止工作，RTMP服务就会等待主播编码器链接推送音频。点击结束直播，推流服务就会开始工作。 媒体管理中心 媒体管理中心负责服务器内所有的AAC音频文件管理，例如上传，下载，删除，审核，试听，分发URL，CDN分发部分。 录播控制 录播控制组件是控制本地音频文件转换成流的方式进行伪直播。 转播控制 转播控制是在不替换现有直播架构方式进行试用新的解决方案的方法，另外可以转播别的电台直播节目。支持RTMP、MMS、RTSP、HLS等主流流媒体格式。 录播分发 录播分发是提供下载和在线收听等功能。 RTMP接收 RTMP接收组件是整个直播服务集群最为核心部分，负责接收录播端和主播端的直播音频部分。 切片服务 切片服务组件是接收RTMP流过来后转换成HLS的TS切片，并且生成M3U8格式的播放列表，实现HTTP方式的流媒体。 分发服务 分发服务（边缘服务器）是负责整个流媒体切片和录播的文件进行对外分发，如果是分布式架构，此处根据自己用户量大小进行带宽调整。国际广播格式48Kbps单用户收听1小时消耗带宽18MB，可以根据此公式计算。 集群工作流程，首先一个问题， 主播不可能24小时在线，没有主播时段会有很长的空白期，这段时间用户如果想收听，没有节目肯定不行， 解决办法：那么我们就做了一个伪直播的功能，通过把本地文件转成直播流的方式，推送到直播服务器，这样用户收听就不会出现空白期 直播录播切换，如何去做才能实现无缝切换，让听众“无感切换” 解决方案：直播流是使用ffmpeg进行本地文件读取，推送到rtmp直播服务器，主播点击直播按钮，会请求一个API，这个API会调用一个shell脚本，杀死推流进程，主播的直播流就会推送到服务器上，直播服务器会把这个流推送到各个分发、切片服务器。 然后我们分享架构流程，大家可以看一下上面的图 首先我们的“伪直播服务”是全天工作的，有主播连线直播后，会杀死伪直播的服务，直播流会迅速的连上，因为分发部分使用的是HLS协议进行分发，所以会有10秒左右的延迟，而且有直播服务器和切片服务器两个中间层，用户根本不会感觉到有顿卡，直播就已经切换成了真正的直播 直播服务器会推送本地的直播流到切片服务器，切片服务器一般会有多台，这个是通过调度API进行获取推流服务器的IP地址，端口、application、直播名称等信息。每个切片服务器启动时候都会通告控制中心自身的IP地址、服务状态、监听端口、application名称、直播名称。控制中心会给直播服务器这些信息，直播服务器调用自身的直播流，分发到各个切片服务器。 切片服务器会对推送过来的流进行切片生成TS文件，并且生成M3U8的索引文件，遵循HLS直播协议进行分发。 由于切片服务器有多个，所以和CDN服务对接时候使用多个IP地址，CDN会根据就近原则，使用到达速度最快的节点进行拉取源文件。 选择HLS也是有两方面考虑 RTMP的并发性并不好 节约成本 我测试过，现有实现rtmp直播最多支持2000个用户拉取流，而且CPU占用会很高，由于网络电台会延迟的敏感性并不是特别高，所以选择HLS，因为