13、多人通话架构：Mesh架构、MCU架构、SFU架构、架构选型对比
多人通话，说白了就是三个以上的人同时开视频会。你想想看，两个人通话很简单，点对点直连就行。但人一多，事情就复杂了。每个客户端都要处理多路音视频流，带宽、CPU、内存都扛不住。
我最早做WebRTC项目时，就踩过这个坑。当时想做个四人的视频聊天室，直接用了Mesh方案。结果用户一多，笔记本风扇狂转，画面卡成PPT。嗯，从那以后，我深刻理解了架构选型的重要性。
今天我们就来聊聊三种主流架构：Mesh、MCU、SFU。我会结合自己的实战经验，帮你理清它们的优缺点和适用场景。
一、Mesh架构：简单但有限
Mesh架构是最直观的方案。每个参与者都跟其他人建立P2P连接。比如4个人开会，每个人都要建立3个连接，总共6个连接。
它的优点很明显：
- 部署简单：不需要服务器转发，纯客户端实现
- 延迟低：数据直达，没有中间节点处理
- 成本低：不需要昂贵的媒体服务器
但缺点同样致命：
- 上行带宽爆炸：每个人都要上传多路视频。我记得有个项目，用户用手机4G网络，3个人还行，加到第4个人直接断流
- 客户端压力大：编码、解码、渲染多路流，CPU和内存消耗巨大
- 不适合大规模：一般建议不超过4-6人
二、MCU架构：中心化混流
MCU（Multipoint Control Unit）架构，就是服务器端把所有音视频流混合成一路，再发给每个客户端。客户端只接收一路流，压力很小。
我参与过一个在线教育项目，最初用的就是MCU。老师端只需要上传一路流，学生端也只接收一路混流，体验很流畅。
MCU的优点：
- 客户端压力最小：只需要解码一路流，手机、低配电脑都能跑
- 带宽节省：每个客户端只下载一路流
- 布局统一：服务器控制画面布局，比如老师大窗、学生小窗
但MCU的缺点也很突出：
- 服务器成本高：混流需要大量CPU/GPU资源。我记得当时部署MCU服务器，一台物理机只能支持20-30个会议
- 延迟增加：混流、转码都需要时间，端到端延迟可能达到500ms以上
- 灵活性差：客户端无法单独控制某一路流，比如不能单独放大某个人的画面
三、SFU架构：当前主流
SFU（Selective Forwarding Unit）架构，服务器只做转发，不做混流。每个客户端上传一路流，服务器根据需求转发给其他客户端。
举个例子：4个人开会，A上传的视频流，服务器会转发给B、C、D。但B可能只需要接收A和C的流，服务器就只转发这两路。
SFU的优点：
- 服务器压力小：只做转发，不转码，CPU消耗低。一台服务器可以支持几百个会议
- 延迟低：转发延迟通常在10-50ms
- 灵活性高：客户端可以自由选择订阅哪些流，比如只看某个人的画面
- 支持Simulcast：发送端可以同时发送多分辨率流，接收端按需选择
缺点：
- 客户端压力中等：需要解码多路流，但比Mesh好很多
- 上行带宽要求：每个人还是要上传一路流，但比Mesh好
- 实现复杂：需要处理信令、重协商、带宽估计等
四、架构对比：一张表看懂
| 维度 | Mesh | MCU | SFU |
|---|---|---|---|
| 服务器成本 | 无 | 高 | 中 |
| 客户端压力 | 高 | 低 | 中 |
| 延迟 | 低 | 高 | 低 |
| 灵活性 | 高 | 低 | 高 |
| 最大人数 | 4-6人 | 50-100人 | 20-50人 |
| 典型场景 | 小规模聊天 | 在线教育、直播 | 视频会议、远程协作 |
五、架构选型：我的一些建议
选型没有银弹。我一般会问自己三个问题：
- 多少人同时通话？ 4人以下，Mesh可以试试。超过4人，直接上SFU或MCU。
- 客户端是什么设备？ 全是PC，SFU没问题。有大量手机或低端设备，MCU更稳妥。
- 预算多少？ 预算充足，MCU体验最好。预算有限，SFU性价比最高。
我个人习惯：首选SFU。它平衡了成本、性能和灵活性。除非你的用户全是低端手机，或者你需要统一画面布局，否则SFU基本都能满足。
我记得有一次给一个创业团队做技术选型，他们想省钱用Mesh。我劝了半天，最后他们还是选了Mesh。结果上线后用户投诉不断，不得不紧急切换到SFU。嗯，有些坑真的得自己踩过才知道。
六、核心逻辑图：三种架构对比
七、总结
三种架构各有千秋。Mesh适合极小型场景，MCU适合对客户端要求高的场景，SFU是当前最平衡的选择。
如果你刚开始做WebRTC项目，我建议从SFU入手。开源方案比如Janus、Mediasoup、LiveKit都很成熟。我自己用Mediasoup做过几个项目，稳定性不错，社区也活跃。
最后说一句：架构选型没有标准答案。关键是要理解你的用户场景、设备分布、预算限制。多问自己几个为什么，选型就不会跑偏。