实时通信（四）：服务端架构，P2P、SFU、MCU 与生产级 RTC 平台

P2P 是端到端直连，SFU 是服务器选择性转发，MCU 是服务器解码、混流、再编码。三者不是谁替代谁，而是不同成本结构：P2P 省服务器但端侧和网络要求高；SFU 平衡延迟和扩展性；MCU 服务端成本高，但对弱设备和传统终端友好。

SFU（Selective Forwarding Unit，选择性转发单元）的核心是“不理解画面内容，只理解媒体流结构”。它根据订阅关系、带宽估计、simulcast/SVC 层级、活跃说话人、客户端能力，把合适的流转发给合适的人。

graph TD
    A["Client A 发布高/中/低三层视频"] --> S["SFU"]
    B["Client B 弱网订阅低层"] --> S
    C["Client C 大屏订阅高层"] --> S
    D["Recorder 订阅归档流"] --> S
    S --> B
    S --> C
    S --> D

LiveKit、mediasoup、Janus 都可以理解为 SFU/媒体服务器生态里的不同选择。LiveKit 更偏完整 RTC 平台和开发者体验，提供房间、权限、SDK、录制、转码等整套能力；mediasoup 更像底层可编程 SFU 库，适合自己搭业务控制面；Janus 是模块化 WebRTC Gateway，适合插件化网关和传统协议接入。

生产级 RTC 平台至少要观测四层：客户端采集/编码/播放，WebRTC 连接和统计，SFU 转发和订阅，机房网络和带宽成本。只看服务端 CPU 或总带宽不够，因为用户体验可能坏在某个房间、某个链路方向、某个 codec、某个运营商路径上。

排障不要从猜开始。先确定影响范围：是所有房间、某个地域、某个运营商、某个设备型号，还是某个用户上行。再定位方向：发布端上行坏、SFU 转发坏、订阅端下行坏、播放端解码坏。最后下钻到 RTP：sequence 是否连续、jitter 是否突增、PLI/NACK 是否异常、关键帧是否到达。