音頻串流服務的系統設計

教學

音頻串流應用的系統設計在處理特定商業需求方面具有獨特性。通常，音頻串流需要在有限的網絡通信頻寬內傳輸大量數據。

一個成功的音頻串流服務必須能夠處理來自不同地理位置的數百萬活躍用戶和數千個內容提供者。不同的設備和平台（智能手機、桌面電腦、智能音箱）可能支持不同的音頻格式如 MP3、FLAC、ALAC 等等。

在這篇博客文章中，我們將探討設計這樣一個複雜系統的細微差別，涵蓋功能性和非功能性需求。

功能性需求

功能性需求將涵蓋內容創作者和音頻用戶或聆聽者所需的功能。

內容管理。內容創作者可以上傳、刪除或更新任何格式的音頻。每個音頻應該具有元數據，如標題、作者、描述、類別和元數據標籤。
通知。內容創作者將收到有關音頻上傳成功或失敗的通知。音頻聆聽者或用戶將收到音頻成功上傳的通知。
無縫串流。用戶可以播放、暫停、倒帶和下載他們選擇格式的音頻。
訂閱。用戶應該能夠訂閱他們選擇的音頻，以接收有關新內容或更新內容的通知。
用戶登錄。內容創作者必須經過身份驗證並獲得授權才能訪問系統。用戶可以註冊系統以設置其個人資料。
搜索。用戶應該能夠根據特定屬性或元數據搜索音頻。

注意：直播和付款服務超出本文範圍。

功能用例的順序圖

架構設計

讓我們定義服務組件以支持功能需求。

第一個功能需求是使用任何格式（如MP3、FLAC、ALAC等）上傳音頻。這些音頻文件可以容納大量數據。音頻編解碼器在高效存儲、傳輸和播放這些數據方面起著至關重要的作用。主要有兩種編解碼器：

無損編解碼器– 壓縮音頻而不丟失任何數據，可以完全恢復而不損失質量。
有損編解碼器– 刪除一些數據有助於顯著減小文件大小。這可能會影響音質。

內容提供者通常使用無損格式進行錄製和編輯。這確保了在操作音頻、應用效果和製作最終產品時不會損失質量。簡單來說，音頻母帶是音頻製作過程中的最後一步。

一旦最終音頻經過母帶處理，就會轉換為有損格式進行一般發行。有損格式可以將文件大小降低到更大程度，從而使音頻更容易更快地進行流媒體播放和下載。

壓縮後的音頻需要通過支持的網絡帶寬傳輸到聆聽設備。帶寬可能會動態變化，隨著連接的用戶數量或用戶在聆聽音頻時從一個網絡區域移動而改變網絡負載。

為了支持這種變化的網絡帶寬，編解碼器可能會使用“自適應位元率”機制。自適應位元率流式媒體在實時檢測用戶的帶寬，並相應調整流媒體。它可以根據用戶當前的帶寬動態切換位元率流式媒體。這將導致緩衝時間較短、啟動時間更快，並為高端和低端連接提供良好體驗。

編碼器將音頻文件的單一來源編碼為多個位元率。這些位元流被打包並存儲在對象存儲中，以便聽眾使用。一旦音頻成功上傳，通知服務會向內容提供者發送通知。

內容創作者在要求上傳音訊時，另外提供元數據，可以通過音訊數據服務直接保存到 NoSQL DB。這些數據將被索引，以提供更好的搜尋功能給音訊聆聽者。

音訊系統需要一個身份驗證和授權服務來處理新用戶註冊、使用用戶憑證登錄以及基於與用戶（聆聽者和內容提供者）相關聯的角色進行授權。API 網關服務可以集中管理身份驗證和授權。此服務可用於執行請求路由和從前端到後端服務的流程管理。

音訊用戶（聆聽者）可以搜索感興趣的音訊，將其轉發給音訊數據服務以返回相關音訊的位置，從音訊元數據存儲中提取信息。用戶點擊鏈接，將返回音訊位元組，由套裝服務打包和存儲。

用戶配置文件服務管理用戶偏好、粉絲和關注者。

上述圖表描述了由內容提供者觸發的基本“上傳音訊”流程和由音訊用戶/聆聽者觸發的“收聽音訊”流程。

使用管道和过滤设计模式与消息队列来支持服务之间的数据流，以实现有效的并行处理和容错能力。

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

非功能需求

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

可伸缩性

音频系统应支持数千名活跃内容创建者。为了管理负载，设计包括运行多个 API Gateway 服务实例、App Web 服务和音频数据服务，并由负载均衡器进行前端负载均衡。

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