11、多人通信架构：Mesh架构、MCU架构、SFU架构的对比与选型
多人实时通信，说白了就是「一群人同时开视频会」。你想想看，如果每个人都把自己的音视频流发给所有人，那网络压力有多大？我刚开始做WebRTC项目时，就踩过这个坑——以为点对点能直接扩展到多人，结果一上线就崩了。
今天咱们聊聊三种主流架构：Mesh、MCU、SFU。每种都有它的脾气，选错了，项目就等着返工吧。
11.1 为什么需要多人通信架构？
WebRTC本身是点对点的。两个人通话，直接连就行。但一旦超过3个人，问题就来了：
- 每个客户端要跟N-1个人建立连接
- 上行带宽要发N-1路流
- 下行带宽要收N-1路流
- CPU要解码N-1路视频
嗯，这里要注意：WebRTC的PeerConnection不是免费的。每个连接都要维护ICE、DTLS、SRTP，开销不小。我在项目中遇到过，4个人开会，笔记本风扇就开始狂转了。
所以，我们需要一个中间层来分担压力。这就是架构设计的初衷。
11.2 Mesh架构：最简单的方案
Mesh架构，就是每个客户端跟其他所有人直连。没有服务器中转，纯P2P。
核心特点：
- 每个客户端发送N-1路流
- 每个客户端接收N-1路流
- 服务器只做信令转发，不处理媒体
- 延迟最低，因为没有中转
我建议，Mesh只适合小规模场景。比如3-4个人的小会议。超过5个人，上行带宽就扛不住了。举个例子：
// 伪代码：Mesh架构中每个客户端的连接数
function getConnectionCount(participants) {
return participants - 1; // 每个客户端要连N-1个人
}
// 4人会议：每个客户端连3个人
// 8人会议：每个客户端连7个人
// 上行带宽 = 视频码率 × (N-1)
我曾经在一个教育项目里试过Mesh。6个学生+1个老师，结果老师那边上行带宽飙到20Mbps，普通家庭宽带根本扛不住。后来果断换了SFU。
避坑指南：我曾经以为Mesh「零服务器成本」很香，结果忽略了客户端性能。移动端设备解码能力有限，4路720p同时解码，手机直接烫手。Mesh不适合移动端多人场景。
11.3 MCU架构：中心化混流
MCU（Multipoint Control Unit）是传统视频会议的老方案。服务器把所有客户的流混合成一路，再发给每个人。
说白了，服务器就是个「视频合成器」。把4个人的画面拼成一个画面，编码成一路流，客户端只解码一路。
核心特点：
- 客户端只发送1路上行流
- 客户端只接收1路下行流
- 服务器做混流、转码、合屏
- 服务器CPU/GPU消耗巨大
MCU的好处很明显：客户端压力最小。手机、低配电脑都能跑。但坏处也致命：服务器成本高。
我记得有个客户，用MCU做100人直播。服务器配了双路Xeon+专业显卡，一个月电费就几千块。而且混流有延迟，每个人看到的画面都一样，没法单独选看某个人。
// MCU架构的带宽计算
// 客户端上行：1路 × 2Mbps = 2Mbps
// 客户端下行：1路 × 2Mbps = 2Mbps
// 服务器处理：N路输入 → 1路输出，需要解码N路再编码1路
个人经验：MCU适合「广播型」场景。比如在线课堂、大型直播。因为所有观众看到的内容一致，不需要个性化。但如果是「互动型」会议，比如几个人讨论，MCU就不太灵活了。
11.4 SFU架构：当前的主流选择
SFU（Selective Forwarding Unit）是目前最流行的方案。服务器不做混流，只做转发。每个客户端发1路上行流，服务器选择性转发给其他人。
你想想看，SFU就像个「智能路由器」。它知道谁在看谁，只转发需要的流。客户端可以自由选择订阅哪几路流。
核心特点：
- 客户端只发送1路上行流
- 客户端接收N-1路下行流（可选择性订阅）
- 服务器只转发，不转码
- 支持Simulcast（同时发送多分辨率）
- 延迟低，灵活性高
我建议，大多数新项目直接选SFU。为什么？
- 服务器压力小：只转发，不编码，CPU消耗低
- 客户端灵活：可以只看大图，小图用低分辨率
- 扩展性好：支持几十人到上百人
- 配合Simulcast，带宽自适应
我在项目中用SFU做过50人同时开会的场景。服务器用4核8G的云主机，CPU占用不到30%。客户端根据网络自动切换分辨率，体验很流畅。
// SFU架构的Simulcast示例
// 客户端发送3路流：720p、360p、180p
// 服务器根据订阅者网络状况，选择转发合适的分辨率
// 订阅逻辑伪代码
function subscribe(remotePeer, networkQuality) {
if (networkQuality === 'good') {
return '720p'; // 高清
} else if (networkQuality === 'fair') {
return '360p'; // 标清
} else {
return '180p'; // 流畅
}
}
个人技巧：SFU配合Simulcast时，注意客户端的编码能力。移动端建议只发2路（360p+180p），桌面端可以发3路。我曾经遇到过，手机发720p+360p+180p三路，CPU直接飙到80%，发热严重。
11.5 三种架构的对比
咱们直接看表格，一目了然：
| 维度 | Mesh | MCU | SFU |
|---|---|---|---|
| 客户端上行 | N-1路 | 1路 | 1路 |
| 客户端下行 | N-1路 | 1路 | N-1路（可订阅） |
| 服务器负载 | 极低 | 极高 | 中等 |
| 延迟 | 最低 | 较高（混流延迟） | 低 |
| 灵活性 | 差 | 差（画面固定） | 高（可自由选流） |
| 扩展人数 | ≤5人 | ≤50人 | ≤100人+ |
| 适用场景 | 小规模P2P | 广播/直播 | 互动会议/在线教育 |
11.6 架构选型建议
选型这事儿，没有银弹。我一般按这几个维度来判断：
- 人数规模：5人以下，Mesh可以试试。5-20人，SFU是首选。20人以上，必须SFU+Simulcast。
- 客户端类型：全是桌面端，Mesh勉强能用。有移动端，直接SFU。MCU适合低端设备。
- 服务器预算：预算有限，选SFU。预算充足且需要录制/转码，可以考虑MCU+SFU混合。
- 功能需求：需要个性化布局（比如自由切换大屏），必须SFU。所有观众看一样的内容，MCU也行。
避坑指南：我曾经在一个项目中，为了省服务器成本，强行用Mesh做10人会议。结果上线第一天就收到用户投诉——画面卡顿、声音断断续续。后来紧急切换到SFU，问题才解决。记住：架构选型要在设计阶段就定好，后期改架构成本极高。
11.7 三种架构的核心逻辑图
下面这张图，帮你直观理解三种架构的区别：
11.8 我的最终建议
如果你现在要做一个多人通信项目，我建议你：
- 直接选SFU。除非你有特殊理由，否则SFU是当前最平衡的方案。
- 不要自己造轮子。开源的SFU方案很多，比如mediasoup、Janus、LiveKit。我项目里用的mediasoup，稳定运行两年了。
- 考虑混合架构。比如SFU+MCU混合：互动用SFU，录制用MCU。我在一个教育项目里就这么做的，效果很好。
嗯，最后说一句：架构选型没有标准答案。关键是你得清楚自己的场景。人数、设备、预算、功能，这四个维度想明白了，选型就不难。
公众号:蓝海资料掘金营，微信deep3321