在streamABC上，我们正在为广播电台和其他媒体公司构建音频流基础架构已有好几年了。
作为我在streamABC的工程师和开发人员的活动的一部分，我的任务是完全重新考虑和重建现有基础结构。 该技术栈主要基于Icecast（正是Icecast的KH分支）。 过去，只有一台大型主服务器可以接受传入的音频流，而有些边缘服务器则需要繁重的工作来为所有侦听器服务。 所有部署和手动操作。 尽管这在过去的几年中效果很好，但仍然存在很多缺点，这些缺点越来越难以克服。
破烂不堪
- 客户之间没有分隔（例如，广播电台）。 如果只有几个，这是可以的，但随着越来越多的客户和对单个解决方案的需求增加而变得更加不安。
- Icecast是一款可靠的软件，可以完成工作。 但是同时，它已经很老了，无法满足最新的需求，例如更好的日志记录和见解，实时指标，可伸缩性。
- 现有的设置几乎不可能满足市场的新需求，例如地理位置感知流，流中和流中广告，可跳过流和用户特定的元数据。
- 大型整体服务器结构，需要更多的操作工作才能提供良好的可用性。
- 随着无线电台提供越来越多的多达数百个单独频道的趋势，变得难以手动维护配置并保持较低的初始成本和上线时间。
还有很长的路要走
我们的目标是能够快速建立新的流，而无需麻烦，包括源安装，代码转换，分布式边缘，实时监控，注入的元数据，虚拟流URL甚至是播放系统，以从音频播放列表中流式播放文件。 而这一切都不需要庞大的团队。
我们从2015年开始重新考虑音频流。作为第一步，我们创建了用于实时监控现有基础架构的解决方案。 （我在这里写过）。 因为没有开箱即用的解决方案，所以我们使用Go，InfluxDB，Grafana和Docker来构建所需的产品。
由于这在生产中表现出令人惊讶的良好效果，我们决定进一步扩大。 因此，我们提出了以下正在生产的解决方案。
新热点
- 我们决定将节点分布在多个数据中心中，以克服诸如网络问题之类的副作用，并为每个侦听器提供最佳的连接性。
- Ansible用于部署新节点。 它用于引导每个节点，安装基本工具，安装Docker和部署服务。 Ansible也用于更新服务。
- 所有服务都部署为Docker容器。 Docker映像是通过由Git推送和标签触发的Drone CI自动构建的。 我们通过与Git标签对齐的Docker标签来部署服务。 这样可以在出现问题时轻松回滚。
- Icecast（KH分支）仍然很重要，因为许多旧版工具仍然依赖于它，但它始终处于后台。 Icecast本身也是dockerized服务。
- 为了克服Icecast问题并获得更大的灵活性，我们创建了自己的专用代理解决方案，该解决方案位于侦听器和Icecast之间。 它包含用于位置感知流，广告注入，元数据处理和指标收集的逻辑。
- Liquidsoap的经过docker化和调整的版本用于提供转码功能。
- Consul在后台使用，以跟踪分布式服务并使用其K / V存储集中配置设置。
- 所有服务都是根据模板进行自动配置的，这些模板具有Consul的设置。
- RabbitMQ充当事件队列以实时连接我们的服务。
- Web前端，Liquidsoap，RabbitMQ和几个Go微服务的集合用于为播放列表频道提供播放系统。
- 使用RabbitMQ主题分发元数据（例如，艺术家，播放的音乐歌曲）并将其注入流中，并使用Go微服务推送到外部端点。
- 提供Websocket连接和轮询的基于NodeJS的服务允许将元数据分发到应用程序和Web播放器。
- AWS Route53用于根据我们集成到所有服务中的运行状况检查在所有节点上分配流量。
结论
似乎我们在已经工作的堆栈中增加了很多复杂性。 但最终，它使根据客户需求扩展基础架构变得容易得多。 关键是要尽可能地自动化。
现在，只需在Web前端中单击几下即可创建完整的音频流链。 最重要的是，我们可以访问更多的指标和数据，以观察堆栈的每个部分都按预期工作并且可以对其进行更好的调整。
另一方面，我们的客户可以从新渠道的超快速上线中受益。 所有这些功能都具有许多新功能，例如对广告注入的精细控制，实时的每个听众会话详细指标，基于云的播放等等。
所有这些都可以通过Quantum Cast获得，它是一种基于云的集成解决方案，用于创建音频流或点播音频。
