音频流媒体服务的系统设计

教程

音频流媒体应用的系统设计在处理特殊的业务需求方面非常独特。通常，音频流媒体需要在网络通信通道的有限带宽内传输大量数据。

成功的音频流媒体服务必须处理来自不同地理位置的数百万活跃用户和数千个内容提供商。不同设备和平台（智能手机、台式机、智能音箱）可能支持不同的音频格式如MP3、FLAC、ALAC等。

在本博文中，我们将探讨设计这样一个涵盖功能和非功能需求的复杂系统的细微差别。

功能需求

功能需求将涵盖内容创建者和音频用户或听众所需的功能。

内容管理。内容创建者可以上传、删除或更新任何格式的音频。每个音频应具有标题、作者、描述、类别和元数据标签。
通知。内容创建者会收到有关上传音频成功或失败的通知。音频听众或用户会收到有关音频成功上传的通知。
无缝流式传输。用户可以播放、暂停、倒带和下载他们选择的格式的音频。
订阅。用户应能够订阅其选择的音频，以接收有关新内容或更新内容的通知。
用户登录。内容创建者必须经过身份验证并获得授权才能访问系统。用户可以在系统中注册以设置其个人资料。
搜索。用户应能够根据特定属性或元数据搜索音频。

注：直播和支付服务不在本文范围内。

功能用例的顺序图

架构设计

让我们定义服务组件来支持功能需求。

第一个功能需求是使用任何格式（如MP3、FLAC、ALAC等）上传音频。这些音频文件可以容纳大量数据。音频编解码器在有效存储、传输和播放这些数据方面起着至关重要的作用。主要有两种类型的编解码器：

无损编解码器 – 压缩音频而不丢失任何数据，并且可以完全恢复而不会失去质量。
有损编解码器 – 删除一些数据，有助于显著减小文件大小。这可能会影响音质。

内容提供者通常使用无损格式进行录制和编辑。这确保在操作音频、应用效果和制作最终产品时不会损失质量。在简单的术语中，音频母带是音频制作过程中的最后一步。

一旦最终音频经过母带处理，就会转换为有损格式进行普遍分发。有损格式可以将文件大小大大减小，使流媒体和下载变得更加容易和快速。

压缩后的音频需要通过支持的网络带宽传输到听者设备。带宽可能会动态变化，网络负载会根据连接的用户数量或用户在收听音频时从一个网络区域移动到另一个区域而变化。

为了支持这种变化的网络带宽，编解码器可以使用“自适应比特率”机制。自适应比特率流媒体会实时检测用户的带宽，相应地调整流媒体。它可以根据用户当前的带宽动态切换比特率流媢，从而减少缓冲时间，加快启动时间，并为高端和低端连接提供良好体验。

编码器会以多个比特率对音频文件的单一源进行编码。这些字节流会被打包并存储在对象存储中，以供听者访问。一旦音频成功上传，通知服务会向内容提供者发送通知。

内容创建者在上传音频时还提供元数据，可以直接保存到 NoSQL 数据库中通过 音频数据服务。这些数据将被索引以提供更好的音频搜索能力。

音频系统需要一个认证和授权服务来处理新用户注册、使用用户凭据登录以及基于用户角色（听众和内容提供者）的授权。API 网关服务可以集中管理认证和授权。该服务可用于执行请求路由，并编排从前端到后端服务的流程。

音频用户（听众）可以搜索感兴趣的音频，该请求将被转发到 音频数据服务 以返回相关音频的位置，从音频元数据存储中提取信息。用户点击链接后，将返回经 打包服务 打包和存储的音频字节。

用户配置文件服务管理 用户偏好、粉丝和关注者。

上述图表描述了由内容提供者触发的基本“上传音频”流程和由音频用户/听众触发的“收听音频”流程。

使用流水线和过滤器设计模式与消息队列支持服务之间的数据流，以实现并行处理和容错性，从而有效地扩展流程。

现在，让我们转向非功能需求。

非功能需求

可伸缩性。系统应支持数千个并发用户，并能够自由扩展和收缩。
容错性。系统应具有容错能力，通常具有冗余数据，且宕机时间较短。
性能。系统在内容播放过程中应具有低延迟和高响应速度。
安全性。系统必须能够防止未经授权的访问或有害攻击，如 DDoS 攻击。

可伸缩性

音频系统应能够支持数千名活跃内容创作者。为了管理负载，该设计包括运行多个 API 网关服务、应用 Web 服务和音频数据服务的实例，并由负载均衡器进行前置。

然而，随着内容创作者数量的增加，这种方式将不具备可伸缩性。音频文件通常很大，在通过多个服务组件时会使用大量网络和计算资源。为了优化系统资源使用，可以使用已签名的 URL（也称为预签名 URL）来提供时间限制的访问权限，以直接上传音频文件到对象存储。这消除了需要通过 API 网关和 API Web 服务路由流量的必要性。已签名的 URL 可以配置具有细粒度权限和过期规则，以提供更好的安全性。