实时音频流网络应用的架构

Question

需要您对实时音频流应用的架构提出意见。

目前，我正在本地网络上对其进行测试，似乎一切正常，但我怀疑它在生产中的表现如何。

我的架构：

                         1               2 
Broadcaster HTTP client ---> App Server ---> Listening clients (React.js App)

1 — 通过 HTTP 通信，2 — 通过 HTTP 和 WebSocket 通信

我想做的事情：

1. 当用户打开我的 React 应用程序并且 Broadcaster 尚未流式传输时，React 应该显示类似“OFFLINE”的内容
2. 接下来，当 Broadcaster 开始流式传输到 App Server 时，React App 应显示“流已启动”并自动开始播放。
3. 最后，当 Broadcaster 停止播放时，React App 应该会再次显示“OFFLINE”。

我目前是怎么做的： 我的应用程序服务器使用两种协议：HTTP（用于音频流和其他内容）和 WebSocket（仅用于发送服务器上发生的情况的 JSON 状态消息）。

1. 当 Broadcaster 开始流式传输到应用服务器（通过 HTTP）时，应用服务器向 React App 发送 WebSocket 消息：“流已经开始，您可以在 http://my-domain/stream 访问它，即应用服务器通过常规 HTTP 将音频流式传输到 React。
2. React App 看到此消息并呈现 HTML <audio> 元素并开始播放音频。
3. 当 Broadcaster 停止播放时，App Server 向 React App 发送 WebSocket 消息“播放结束”，React 隐藏播放器，显示“OFFLINE”

因此，我通过 HTTP 进行所有流式传输（从 Broadcaster 到 App Server 以及从 App Server 到 React 客户端）并使用 WebSocket 来传达实时流状态更新。

这个架构有多好？

Answer 1

How good is this architecture?

这不是好坏的问题，而是它是否适合您的用例的问题。我注意到这基本上就是 SHOUTcast 和 Icecast 等互联网广播服务器 20 多年来一直工作的方式，所以它不会那么糟糕。 :-)