14、SFU服务器实现：Mediasoup简介、Mediasoup架构、Transport概念、Producer与Consumer
各位同学，今天我们来聊聊SFU服务器实现里一个绕不开的明星——Mediasoup。
说实话，我第一次接触Mediasoup的时候，心里是有点发怵的。文档不算多，社区里中文资料也少。但真正用起来之后，我发现它的设计思路非常清晰，说白了就是“把复杂留给自己，把简单留给开发者”。
这一章，我会带着大家把Mediasoup的四个核心概念掰开揉碎：架构、Transport、Producer、Consumer。嗯，这些都是你写SFU服务器必须啃下的硬骨头。
1. Mediasoup简介：它到底是什么？
Mediasoup是一个基于WebRTC的SFU（Selective Forwarding Unit）服务器。它用C++写核心，Node.js做API层。你想想看，这意味着什么？
- 性能强悍：C++处理媒体流，效率极高。
- 开发友好：Node.js暴露API，前端工程师也能快速上手。
- 不依赖浏览器：它自己就是一个独立的媒体服务器，不跑在浏览器里。
我个人习惯把Mediasoup比作一个“智能路由器”。它不负责编解码（那是客户端的事），它只负责把音视频流从发送方转发给接收方。但它的转发策略非常灵活——你可以选择转发给谁、不转发给谁，甚至可以动态调整码率。
我在项目中遇到过一个问题：一开始用MCU方案，服务器CPU直接飙到90%。换成Mediasoup之后，CPU降到了20%以下。这就是SFU的魅力。
2. Mediasoup架构：一张图看懂全局
我们先来看一张架构图，这是我用SVG画的，帮你快速建立整体认知。
从这张图你能看到，Mediasoup的层次非常清晰：
- Worker：底层C++进程，负责真正的媒体处理。
- Router：逻辑上的“房间”，一个Worker可以有多个Router。
- Transport：传输通道，连接客户端和Router。
- Producer / Consumer：流的生产者和消费者。
我记得刚开始看文档时，最让我困惑的就是Router和Transport的关系。后来我明白了：Router是房间，Transport是门。每个客户端进门（Transport），然后在房间里说话（Producer）或听别人说话（Consumer）。
3. Transport概念：连接的门户
Transport是Mediasoup里非常核心的一个概念。它本质上是一个端到端的传输通道，负责在客户端和服务器之间传递媒体数据。
Mediasoup支持三种Transport：
| Transport类型 | 适用场景 | 特点 |
|---|---|---|
| WebRtcTransport | 浏览器客户端 | 基于ICE/DTLS，支持NAT穿透 |
| PlainTransport | 非浏览器设备（如摄像头、编码器） | 纯UDP，无ICE，简单直接 |
| PipeTransport | 服务器与服务器之间 | 用于多Worker或多服务器通信 |
这里我要特别提醒一下：WebRtcTransport是最常用的，因为它支持ICE打洞，能应对复杂的网络环境。但如果你是在内网做设备对接，PlainTransport会更轻量。
创建Transport的代码大致是这样的：
// 创建 WebRtcTransport
const transport = await router.createWebRtcTransport({
listenIps: [
{ ip: '0.0.0.0', announcedIp: 'your.public.ip' }
],
enableUdp: true,
enableTcp: true,
preferUdp: true,
initialAvailableOutgoingBitrate: 1000000, // 1Mbps
});
// 获取本地ICE参数和DTLS指纹，发送给客户端
const iceParameters = transport.iceParameters;
const iceCandidates = transport.iceCandidates;
const dtlsParameters = transport.dtlsParameters;嗯，这里要注意：announcedIp一定要填你的公网IP，否则客户端连不上。我曾经在这里踩过坑，折腾了一下午才发现是IP没配对。
4. Producer与Consumer：流的灵魂
有了Transport，接下来就是真正的媒体流了。在Mediasoup里，Producer代表发送端，Consumer代表接收端。
一个Producer对应一个媒体轨道（音频或视频）。比如一个用户开启了摄像头和麦克风，那他就需要创建两个Producer：一个视频Producer，一个音频Producer。
Consumer则是从Producer那里订阅流。你可以订阅一个Producer，也可以订阅多个。Mediasoup会自动做带宽自适应——如果接收端网络不好，它会自动降低码率。
创建Producer的代码示例：
// 客户端通过Transport发送媒体流
const producer = await transport.produce({
kind: 'video', // 或 'audio'
rtpParameters: rtpParameters, // 从客户端获取的RTP参数
appData: { userId: '123' }, // 自定义数据
});
// 监听producer事件
producer.on('score', (score) => {
console.log('Producer score:', score);
// score可以反映网络质量
});创建Consumer的代码示例：
// 从某个Producer创建Consumer
const consumer = await transport.consume({
producerId: producer.id,
rtpCapabilities: rtpCapabilities, // 接收端的能力
paused: false, // 是否暂停
});
// 获取Consumer的流信息
const { kind, rtpParameters } = consumer;
// 将Consumer的RTP参数发送给客户端
// 客户端通过这个参数来接收媒体流rtpCapabilities。结果客户端无法解码，画面黑屏。记住：Consumer的创建必须基于客户端的解码能力，否则流发过去也是白搭。
另外，Mediasoup还提供了一个很实用的功能：Consumer的暂停和恢复。比如用户切换到了后台，你可以暂停Consumer，节省带宽。等用户切回来再恢复。
// 暂停Consumer
await consumer.pause();
// 恢复Consumer
await consumer.resume();5. 整体流程串起来
好了，我们把今天讲的内容串成一个完整的流程：
- 创建Worker：启动一个C++进程。
- 创建Router：在Worker里创建一个Router，对应一个房间。
- 创建Transport：每个客户端连接时，创建WebRtcTransport。
- 创建Producer：客户端发送媒体流，服务器创建Producer。
- 创建Consumer：其他客户端订阅，服务器创建Consumer，转发流。
- 动态管理：根据网络状况、用户行为，暂停/恢复/关闭Producer或Consumer。
这个流程看起来简单，但实际项目中会有很多细节。比如：如何处理客户端的重连？如何做多码率适配？这些我们后面的章节会深入讲。
好了，这一章的内容就到这里。Mediasoup的设计非常优雅，但需要你花时间去理解它的抽象层次。记住：Transport是通道，Producer是源头，Consumer是终点。搞懂这三者的关系，你就掌握了SFU服务器的核心。
如果你在搭建过程中遇到问题，欢迎随时交流。我们下一章见。