第20章多人视频会议架构

课程目录第20章多人视频会议架构

多人视频会议架构：Mesh、MCU、SFU 与选型对比

说到多人视频会议，很多刚接触 WebRTC 的朋友第一反应是：「不就是把两个人通话改成多个人吗？简单！」

嗯，我当年也是这么想的。直到我在一个创业项目里，硬着头皮用 Mesh 架构做了个 8 人会议，结果用户的 MacBook 风扇直接起飞，CPU 飙到 90%。那场面，至今难忘。

多人视频通信，说白了就是一场「带宽 vs 性能 vs 成本」的博弈。今天咱们就把三种主流架构——Mesh、MCU、SFU——掰开揉碎聊清楚。

Mesh 架构是最直观的方案。每个客户端都跟其他所有客户端建立一条独立的 PeerConnection。

举个例子：4 个人开会，每个人都要发送 3 路视频流，同时接收 3 路视频流。总共需要建立 6 条连接。

  核心特点：
  没有中心服务器转发媒体流
每个客户端既是发送者也是接收者
上行带宽 = 单路码率 × (N-1)
下行带宽 = 单路码率 × (N-1)

我在一个内部工具项目里试过 6 人 Mesh，效果还行。但一旦超过 8 人，普通笔记本就开始卡顿。为什么？你想想看，每个客户端要同时编码 N-1 路视频，还要解码 N-1 路。这计算量是 O(N²) 增长的。

避坑指南：我曾经在 Mesh 架构里忘记限制视频分辨率，结果 6 个人都开了 1080p，网络直接炸了。建议 Mesh 场景下强制限制为 360p 或 480p。

MCU（Multipoint Control Unit）是传统视频会议的老大哥。它的思路很简单：所有客户端把视频流发给中心服务器，服务器把多路视频合成一路，再分发给所有人。

说白了，服务器就是个「视频合成器」。你看到的画面是服务器拼好的，客户端只需要解码一路视频流。

  核心特点：
  服务器负责混流、转码、合屏
客户端只收一路合成后的视频
上行带宽 = 单路码率
下行带宽 = 单路码率
服务器 CPU/GPU 消耗极高

我记得有一次给客户做方案，对方坚持要用 MCU，理由是「客户端要兼容老旧的 Windows 平板」。MCU 确实适合这种终端性能弱的场景，但服务器成本嘛……嗯，一台高性能服务器撑死了支持 20-30 路 720p 混流。

个人经验：MCU 架构里，合屏布局是个坑。如果你要支持「演讲者模式」和「画廊模式」动态切换，服务器端需要做实时布局重算。我建议用 libavfilter 做 GPU 加速混流，否则 CPU 扛不住。

SFU（Selective Forwarding Unit）是 Mesh 和 MCU 的折中方案。服务器不混流，只做「选择性转发」。每个客户端依然发送一路视频流到服务器，服务器根据订阅关系，把需要的流转发给对应的客户端。

举个例子：4 人会议，A 想看 B 和 C 的画面，服务器只把 B 和 C 的流转发给 A。D 的画面？不转发，省带宽。

  核心特点：
  服务器只转发，不混流
客户端需要解码多路视频（但比 Mesh 少）
上行带宽 = 单路码率
下行带宽 = 订阅路数 × 单路码率
服务器 CPU 消耗低，带宽消耗高

我现在做的产品用的就是 SFU。为什么？因为它的扩展性最好。你可以轻松支持几十人甚至上百人的会议，只要服务器带宽够。而且 SFU 天然支持 Simulcast——发送端同时发多路不同分辨率的流，接收端按需订阅。

一个小技巧：SFU 架构里，建议开启 Simulcast。比如发送端同时发 720p、360p、180p 三路流。客户端根据窗口大小自动选择订阅哪一路。这样大屏看高清，小屏看低清，带宽利用率拉满。

这个问题没有标准答案。我个人的经验是：

注意：不要盲目追求「纯 SFU」。如果你的业务需要「统一画面录制」或「多路合屏直播」，SFU 本身做不了，必须搭配混流服务。我踩过这个坑——产品经理说「就用 SFU」，结果上线后发现录制的视频是 N 个独立文件，根本没法用。

下面这张图展示了三种架构的核心区别。我习惯用这种图来跟团队对齐方案。

聊了这么多，其实就一句话：没有最好的架构，只有最适合你场景的架构。

我个人现在的默认选择是 SFU。它平衡了服务器成本和客户端体验，而且生态成熟——medooze、Janus、mediasoup 都是不错的选择。如果你刚开始做多人视频，从 SFU 入手准没错。

但如果你只是做个内部小工具，Mesh 完全够用。别为了「架构先进」而上 MCU，那玩意儿维护成本高得吓人。

嗯，关于架构选型，今天就聊到这儿。下次咱们可以深入聊聊 SFU 的 Simulcast 和 SVC 到底怎么选——这两个东西，我当年可是花了好几个通宵才搞明白。