多人会议架构：Mesh/MCU/SFU对比、SFU转发逻辑、混流与转发决策
聊到多人会议，很多刚接触WebRTC的朋友第一反应就是——把两个人通话的逻辑复制N份不就行了？嗯，理论上可以，但实际跑起来你会发现，带宽、CPU、内存全都在报警。我在早期做视频会议项目时，就踩过这个坑。
今天咱们把三种主流架构掰开揉碎讲清楚。Mesh、MCU、SFU，它们各自适合什么场景？SFU的转发逻辑到底怎么设计的？什么时候该混流，什么时候该转发？
一、三种架构的核心差异
先看一张对比图，心里有个整体印象。
二、Mesh 架构：最简单的方案，但别贪心
Mesh 架构说白了就是每个客户端跟其他所有人直连。4个人开会，每个人要维护3个PeerConnection，总共6条连接。
优点很明显：不需要服务器转发，延迟最低，部署最简单。我早期做内部工具时就用过，几行代码就能跑起来。
但坑也在这里。我曾经在一个项目里试过6人Mesh，结果某个同事的笔记本风扇直接起飞。你想想看，每个人要上传5路、下载5路视频流，带宽和CPU都扛不住。
适用场景：2-4人的小规模会议，或者对延迟极度敏感的场景（比如远程操控）。
注意：超过4人请果断放弃Mesh。我曾经见过一个团队硬撑8人Mesh，结果会议变成幻灯片播放。
三、MCU 架构：服务器扛下所有
MCU 的思路是——服务器把所有人的流收上来，解码、混流、再编码，最后推给每个客户端。客户端只收一路流，压力最小。
听起来很完美对吧？但代价是服务器要干所有脏活累活。我记得有个项目用MCU跑30人会议，服务器CPU直接飙到90%，还得配GPU做硬件编码。
| 对比项 | MCU | SFU |
|---|---|---|
| 服务器CPU消耗 | 高（解码+编码+混流） | 低（只转发） |
| 客户端CPU消耗 | 低（只收1路流） | 中（收N-1路流） |
| 延迟 | 较高（多一次编解码） | 低（透传） |
| 灵活性 | 低（布局固定） | 高（客户端自由布局） |
| 带宽消耗 | 低（下行1路） | 较高（下行N-1路） |
我的建议：MCU适合大型直播或录制场景，比如在线教育、大型 webinar。但实时互动会议，我一般不推荐。
四、SFU 架构：目前的主流选择
SFU 是目前最流行的方案。服务器只做一件事——转发。它不解码、不编码、不混流。客户端上传一路流，服务器根据订阅关系，把流转发给需要的其他客户端。
为什么会成为主流？说白了就是平衡。服务器压力可控，客户端也能接受，延迟还低。我最近做的几个项目，无一例外都选了SFU。
SFU 的转发逻辑
SFU 的核心逻辑其实不复杂，但细节很多。我画个流程图你就明白了。
实际实现时，SFU 还要处理几个关键问题：
- Simulcast（联播）：客户端同时推多路不同分辨率的流，SFU 根据接收端带宽选择转发哪一路。我习惯让客户端推 720p、360p、180p 三路。
- SVC（可伸缩编码）：只推一路流，但编码时分层。SFU 可以丢弃增强层来降低带宽。这个方案更优雅，但编码器支持有限。
- 带宽估计：SFU 需要实时监控每条链路的带宽，动态调整转发策略。我曾经遇到过网络抖动导致视频卡成PPT，后来加了带宽估计才解决。
核心原则：SFU 只做转发，不做处理。任何需要解码的操作都交给客户端。
五、混流与转发决策
这是很多架构师纠结的地方。什么时候该混流？什么时候该转发？
我的经验是这样的：
- 默认用转发：90%的场景用SFU转发就够了。客户端自己渲染多路流，布局灵活，延迟低。
- 混流的场景：
- 录制：需要把多路流合成一个视频文件
- 直播：推给CDN或RTMP服务器时，只能推一路
- 低端设备：有些手机解码能力有限，混流后只收一路
- 动态切换：我做过一个方案，正常情况下用SFU转发，当检测到客户端CPU过高时，自动切换到MCU模式。嗯，这个实现起来有点复杂，但效果很好。
避坑指南：我曾经在混流时忽略了音频同步问题。不同客户端的采样率、时钟漂移都不一样，混出来的音频有回声和延迟。后来加了NTP时间戳对齐才搞定。
六、实际项目中的选择建议
说了这么多，到底怎么选？我直接给结论：
| 参会人数 | 推荐架构 | 理由 |
|---|---|---|
| 2-4人 | Mesh | 延迟最低，无需服务器 |
| 4-20人 | SFU | 平衡服务器和客户端压力 |
| 20-100人 | SFU + Simulcast | 通过分层流控制带宽 |
| 100人以上 | SFU + 选择性转发 | 只转发活跃发言人的流 |
| 录制/直播 | MCU | 需要混流输出 |
个人习惯：我现在做项目，默认选SFU。只有在录制或推CDN时，才在SFU后面挂一个MCU模块做混流。这样既灵活又可控。
好了，多人会议架构的核心内容就这些。Mesh简单但有限，MCU强大但昂贵，SFU是目前最务实的方案。理解清楚它们的差异和适用场景，你设计系统时就不会纠结了。
公众号:蓝海资料掘金营，微信deep3321