过去两年，聊聊语音聊天网的日活用户从12万增长到87万，其中语音聊天场景占比超过六成。用户对实时性和稳定性的要求，远比文字聊天室苛刻——延迟超过400ms，对话就会明显“抢话”。这迫使我们重新审视底层架构。

核心挑战：从文字到语音的跨越

传统聊天室基于WebSocket做消息广播，技术栈成熟。但多人语音聊天面临三重压力：音频流持续上行、混音计算密集、网络抖动敏感。早期我们采用中心化MCU方案，单房间20人时CPU占用就逼近80%，扩容成本极高。

方案选型：SFU + 边缘节点

经过压测对比，我们转向SFU架构，每个房间由边缘节点转发音频流，客户端只上传一路、订阅多路。关键优化点：

• Opus编码动态码率24-48kbps，配合FEC抗丢包
• WebRTC传输层启用BWE带宽估计，弱网下自动降码率
• 边缘节点部署在北上广深等8个区域，端到端延迟控制在180ms以内

实践中的取舍

纯SFU不做混音，客户端下行带宽随人数线性增长。50人房间下行约2.4Mbps，对移动端仍有压力。我们引入选择性转发：只订阅发言活跃度Top 8的流，其余静音流仅保留信令。这个策略让卡顿率从7.3%降到1.8%。

如果你也在搭建语音聊天系统，建议先压测单节点承载上限，再决定是否引入级联。别过早优化，但一定要预留水平扩展能力。