6、多人架构设计：Mesh架构、SFU架构、MCU架构、架构选型对比
说到多人视频会议，很多刚接触WebRTC的朋友第一反应是：“不就是把两个人通话改成三个人、四个人吗？”
嗯，真没那么简单。我刚开始做第一个多人项目时，也天真地以为把PeerConnection多new几次就行。
结果呢？浏览器直接卡死，风扇狂转。那场面，至今难忘。
今天我们就来聊聊多人架构的三种主流方案：Mesh、SFU、MCU。
我会结合自己的踩坑经历，帮你理清它们的区别和适用场景。
一、Mesh架构：最简单，也最“暴力”
Mesh架构，说白了就是每个客户端都和所有其他客户端建立连接。
比如4个人开会，每个人都要维护3个PeerConnection。数据是点对点直传的，服务器只负责信令转发，不碰媒体流。
- 每个客户端上行带宽 = 自己的一路视频 × (N-1)
- 每个客户端下行带宽 = (N-1) 路视频
- 服务器压力最小，几乎只做信令中转
我在一个内部培训项目中试过Mesh，5个人开会，每个人的上行带宽就要达到4路视频的码率。
如果每人用1Mbps的720p视频，上行就是4Mbps。对于大多数家庭宽带，上传也就5-10Mbps，很快就撑爆了。
所以，Mesh只适合3-5人的小型会议，且参与者网络条件都比较好。
Mesh的优点也很明显：部署简单，不需要专门的媒体服务器，成本低。
如果你只是做个家庭聚会或者小团队内部工具，Mesh完全够用。
二、SFU架构：目前最主流的选择
SFU（Selective Forwarding Unit）是目前业界最流行的方案。
它的做法是：每个客户端只上传一路视频到服务器，服务器再把这路视频转发给其他所有人。
你想想看，这样每个客户端的上行带宽就固定了，不管多少人开会，都只上传一路。
下行带宽呢？服务器会转发N-1路给你，所以下行压力还是在客户端，但上行压力大大减轻。
- 客户端上行带宽 = 1路视频（固定）
- 客户端下行带宽 = (N-1) 路视频
- 服务器负责转发，不进行编解码，延迟低
我记得在做一个在线教育项目时，我们选了SFU。老师端只需要上传一路视频，服务器转发给200个学生。
学生端虽然要下载200路，但我们可以通过Simulcast（ simulcast 是 WebRTC 的编码技巧，让发送端同时编码多个分辨率的流，接收端按需订阅） 来优化。
比如老师的主画面用高清，其他学生用小窗低清，这样下行带宽也能控制住。
所以选云服务器时，一定要算好带宽预算，别等用户多了才发现撑不住。
SFU的缺点是需要一台性能不错的媒体服务器。常见的开源方案有 Janus、Mediasoup、LiveKit 等。
我个人比较推荐 Mediasoup，它底层用C++实现，性能好，而且API设计得很干净。
三、MCU架构：最“重”但最省客户端资源
MCU（Multipoint Control Unit）是传统的硬件视频会议方案。
它的做法是：所有客户端都把视频上传到服务器，服务器在服务器端混流，合成一路视频，再下发给每个客户端。
说白了，服务器就像一个视频剪辑师，把所有人的画面拼成一个画面，然后只输出一路视频流。
这样客户端只需要解码一路视频，压力最小。
- 客户端上行带宽 = 1路视频
- 客户端下行带宽 = 1路视频（合成后的）
- 服务器负责解码、合成、编码，CPU/GPU消耗极大
我曾经在政府项目中接触过MCU方案，他们用的是硬件MCU设备，一台机器几十万。
软件MCU也有，比如 FFmpeg + 自定义混流，但性能开销非常大。4路1080p混流，CPU占用就能到80%以上。
如果对实时性要求高（比如直播互动），MCU可能不太合适。
MCU的优势在于客户端兼容性极好。哪怕用户用的是老旧手机，只需要解码一路视频就行。
所以，如果你要支持大量低端设备，MCU是唯一选择。
四、架构选型对比：一张表说清楚
| 维度 | Mesh | SFU | MCU |
|---|---|---|---|
| 客户端上行带宽 | 高（N-1路） | 低（1路） | 低（1路） |
| 客户端下行带宽 | 高（N-1路） | 高（N-1路） | 低（1路） |
| 服务器压力 | 极低 | 中等（转发） | 极高（编解码） |
| 延迟 | 低 | 低 | 中高 |
| 客户端CPU消耗 | 高（多路解码） | 高（多路解码） | 低（1路解码） |
| 服务器成本 | 几乎为零 | 中等 | 高 |
| 适用人数 | 3-5人 | 10-100人 | 50-500人 |
| 典型场景 | 家庭聚会、小团队 | 在线教育、远程办公 | 大型会议、直播 |
五、架构选型决策流程
怎么选？我一般会问自己三个问题：
- 多少人同时开摄像头？ 少于5人 → Mesh；5-50人 → SFU；50人以上 → MCU或SFU+选择性转发。
- 客户端设备性能如何？ 如果大部分是手机或老旧电脑，优先考虑MCU或SFU+Simulcast。
- 预算多少？ 没钱 → Mesh；有点钱 → SFU（一台云服务器即可）；不差钱 → MCU。
我个人习惯是：默认选SFU。因为它在成本和性能之间取得了最好的平衡。
如果项目后期发现客户端解码压力大，再考虑引入MCU做混流，或者用Simulcast做分层订阅。
六、核心知识体系图
下面这张图总结了三种架构的核心逻辑和选型要点：
七、总结
三种架构没有绝对的好坏，关键看你的场景。
Mesh 适合练手和小规模；SFU 是当前的主流选择；MCU 虽然重，但在特定场景下不可替代。
我个人建议：从 SFU 入手，先用 Mediasoup 或 LiveKit 搭一个原型，跑通 10 人会议。
等遇到性能瓶颈了，再考虑混流或分层优化。别一开始就追求大而全，容易把自己绕进去。
嗯，关于架构选型，今天就聊到这里。如果你在实际项目中遇到什么坑，欢迎交流。