音频流服务的系统设计

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

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

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

功能要求

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

内容管理。内容创建者可以上传、删除或更新任何格式的音频。每个音频都应有元数据，如标题、作者、描述、类别和元数据标签。
通知。内容创建者会收到上传音频成功或失败的通知。音频收听者或用户会收到成功上传音频的通知。
无缝流媒体。用户可以播放、暂停、倒带和下载所选格式的音频。
订阅。用户应能订阅自己选择的音频，以接收新内容或更新内容的通知。
用户登录。内容创建者必须经过验证和授权才能访问系统。用户可以在系统中注册，建立自己的档案。
搜索。用户应能根据某些属性或元数据搜索音频。

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

功能用例序列图

架构设计

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

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

无损编解码器：在不丢失任何数据的情况下压缩音频，并且可以在不降低质量的情况下完全恢复。
有损编解码器：删除部分数据，有助于大幅减小体积。这可能会影响音质。

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

音频最终制作完成后，会将其转换为有损格式，以便广泛传播。有损格式可以大幅缩小文件大小，让流媒体和下载更加轻松快捷。

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

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

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

内容创建者在请求上传音频时额外提供元数据，该元数据可通过音频数据服务直接保存到 NoSQL DB 。这些数据将被索引，以便为音频听众提供更好的搜索能力。

音频系统需要身份验证和授权服务来处理新用户注册、使用用户凭证登录以及基于与用户（听众和内容提供商）关联的角色的授权。API网关服务可以集中管理身份验证和授权。可以利用此服务执行请求路由，并协调从前端到后端服务的流程。

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

用户资料服务管理用户偏好、关注者和关注对象。

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

正在使用带有消息队列的管道和过滤设计模式来支持服务之间的数据流，以并行性和容错性有效地扩展流程。

现在，让我们讨论非功能性需求。

非功能性需求

可扩展性。系统应支持数千个并发用户，并能扩展和缩小。
容错性。系统应具有容错能力，通常具有冗余数据，停机时间短。
性能。系统在内容播放期间应具有低延迟和高响应能力。
安全性。系统必须能够抵御未经授权的访问或 DDoS 等有害攻击。

可扩展性

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

但是，随着内容创建者数量的增加，这种方法将无法扩展。音频文件通常很大，在遍历多个服务组件时会占用大量网络和计算能力。为了优化系统资源使用率，可以使用签名 URL（也称为预签名 URL）提供对对象存储的限时访问，以直接上传音频文件。这样就无需通过 API 网关和 API Web 服务路由流量。签名 URL 可以配置细粒度的权限和过期规则，以提高安全性。