17、多人视频会议架构：Mesh、SFU、MCU 怎么选？
多人视频会议，说白了就是让一群人同时看到彼此。
但这里有个核心问题：视频流怎么分发？
你想想看，如果 4 个人开会，每个人都要看到其他 3 个人的画面。如果每个人都把自己的视频发给所有人，那网络压力会爆炸。我刚开始做 WebRTC 时，就天真地以为直接点对点连就行，结果 6 个人开会，客户端直接卡成幻灯片。
所以，我们需要一个合理的架构来管理这些视频流。
目前主流的方案有三种：Mesh（网格）、SFU（选择性转发单元）、MCU（多点控制单元）。每种方案都有自己的脾气，选错了，项目可能就黄了。
17.1 Mesh 架构：简单粗暴，但别贪多
Mesh 架构，也叫全连接架构。
每个参与者都把自己的视频流发给其他所有人。比如 4 个人开会，每个人都要发送 3 路视频，同时接收 3 路视频。总连接数 = n*(n-1)/2。
核心特点：没有中心服务器，每个客户端既是发送者也是接收者。
我在项目中遇到过一个小团队协作工具，就用了 Mesh。当时觉得简单，不用搭服务器，省钱。结果呢？5 个人开会，每个人的上行带宽就要吃掉 3 路视频的流量。如果每路视频 1Mbps，那上行就是 3Mbps。普通家庭宽带的上行也就 5-10Mbps，稍微一多就扛不住。
我的建议：Mesh 架构只适合 4 人以内的小型会议。超过 4 人，客户端 CPU 和带宽都会报警。
优点：
- 部署简单，不需要中心服务器
- 延迟低，点对点直连
- 成本低，没有服务器开销
缺点：
- 上行带宽压力大，每个人都要发多路
- 客户端 CPU 负载高，编解码多路视频
- 扩展性差，人数一多就崩
17.2 SFU 架构：目前最流行的选择
SFU，全称 Selective Forwarding Unit，选择性转发单元。
它的思路很简单：客户端只发一路视频给服务器，服务器再转发给其他人。
比如 4 个人开会，每个人只发 1 路视频给 SFU 服务器，服务器再把这路视频复制 3 份，发给其他 3 个人。这样，每个客户端的上行带宽只需要 1 路视频的流量。
核心特点：服务器只转发，不解码、不混流。视频流是独立的。
我个人习惯用 SFU 架构做多人会议。为什么？因为它灵活。你可以让每个客户端根据自己的网络状况，选择接收不同分辨率的视频流。比如手机端网络差，就只接收低分辨率流；PC 端网络好，就接收高清流。
我曾经帮一家在线教育公司搭建直播系统，用的就是 SFU。老师端发一路高清流，学生端根据自己的带宽选择接收。有的学生用 4G，就自动切到 360p；有的用 WiFi，就收 720p。体验非常好。
避坑指南：我曾经遇到过 SFU 服务器 CPU 飙升的问题。后来发现是转发逻辑没优化，每个流都做了不必要的拷贝。记住，SFU 的核心是「零拷贝转发」，尽量用内存映射或共享内存。
优点：
- 客户端上行带宽低，只发一路
- 支持动态码率调整，适应不同网络
- 扩展性好，支持几十人到上百人
- 延迟低，只转发不处理
缺点：
- 需要部署服务器，成本增加
- 服务器带宽压力大，需要转发多路
- 客户端需要同时解码多路视频，CPU 负载依然存在
17.3 MCU 架构：老牌方案，但有点重
MCU，全称 Multipoint Control Unit，多点控制单元。
它的思路和 SFU 完全不同：服务器把所有视频流解码、混流、再编码成一路视频，发给每个客户端。
比如 4 个人开会，MCU 服务器收到 4 路视频，把它们合成一个画面（比如 2x2 的布局），然后编码成一路视频，发给每个人。这样，每个客户端只需要解码一路视频。
核心特点：服务器做混流，客户端只收一路。
我记得早期视频会议系统，比如思科、Polycom 的设备，基本都是 MCU 架构。那时候客户端性能弱，只能解码一路视频。MCU 把复杂工作都扛在服务器上。
但 MCU 有个致命问题：服务器压力巨大。每路视频都要解码、混流、再编码，CPU 和内存消耗非常高。我曾经测试过一个开源 MCU 方案，8 个人开会，服务器 CPU 直接跑到 90%。
注意：MCU 架构的延迟较高，因为服务器需要做完整的编解码处理。对于实时性要求高的场景（比如直播互动），不太推荐。
优点：
- 客户端负载极低，只解码一路视频
- 带宽占用低，只收一路流
- 适合老设备或低性能终端
缺点：
- 服务器成本高，需要强大的计算能力
- 延迟较高，编解码耗时
- 灵活性差，布局固定，无法单独调整
- 扩展性差，人数一多服务器扛不住
17.4 三种架构对比：一张表说清楚
| 维度 | Mesh | SFU | MCU |
|---|---|---|---|
| 服务器需求 | 无 | 需要转发服务器 | 需要高性能服务器 |
| 客户端上行带宽 | 高（发 n-1 路） | 低（发 1 路） | 低（发 1 路） |
| 客户端下行带宽 | 高（收 n-1 路） | 高（收 n-1 路） | 低（收 1 路） |
| 客户端 CPU 负载 | 高 | 中 | 低 |
| 服务器 CPU 负载 | 无 | 低（只转发） | 高（编解码混流） |
| 延迟 | 低 | 低 | 中高 |
| 扩展性 | 差（≤4 人） | 好（几十到上百人） | 一般（≤20 人） |
| 灵活性 | 高 | 高 | 低 |
| 部署成本 | 低 | 中 | 高 |
17.5 怎么选？我的经验之谈
选架构，说白了就是看你的场景和预算。
场景一：小团队内部沟通（2-4 人）
用 Mesh。简单、免费、零部署。我自己的小团队就用 Mesh 做日常沟通，够用。
场景二：在线教育、直播互动（几十人）
用 SFU。这是目前最主流的选择。我参与过的几个项目，包括在线教育和远程医疗，都用的 SFU。灵活、扩展性好，而且开源方案多（比如 mediasoup、Janus、LiveKit）。
场景三：大型会议、Webinar（上百人）
用 SFU + 分层编码（Simulcast 或 SVC）。让服务器根据客户端网络状况，自动选择转发合适的分辨率。我曾经给一个千人直播系统做过优化，就是用 SFU + Simulcast，效果很好。
场景四：老设备兼容、低性能终端
用 MCU。虽然服务器压力大，但客户端体验好。比如一些嵌入式设备或老旧手机，只能解码一路视频，那就只能用 MCU。
我的建议：除非你有特殊需求，否则优先选 SFU。它是最平衡的方案。MCU 除非你服务器资源非常充足，否则别碰。Mesh 只适合玩玩。
17.6 架构对比图：一目了然
17.7 总结一下
选架构，没有银弹。
Mesh 适合小规模、低成本场景；SFU 是当前的主流，灵活且扩展性好；MCU 适合老设备兼容，但服务器成本高。
我个人建议：如果你不确定选哪个，就选 SFU。它是最稳妥的选择。等你遇到性能瓶颈，再考虑优化方案，比如加 Simulcast 或分层编码。
嗯，架构选对了，项目就成功了一半。