在做郑州某大型商圈直播系统时，我直接碰到的是场景分散、互动需求多样的现实痛点：同一套系统要支撑电商带货、企业培训、线下活动转播和社交房间，延迟、并发、连麦策略都不一样，不能一刀切。那一刻我意识到，架构设计必须以场景为颗粒度，而不是以协议或单点服务为中心。

      具体技术抉择上，我倾向于把WebRTC作为实时连麦的主力通道，用SFU（mediasoup或Janus）处理多路转发以降低上行带宽压力；而将RTMP作为主播稳定入流方案，借助SRS或Nginx-RTMP做接入层，再用FFmpeg做硬件加速转码，输出HLS/CMAF用于大流量回放。两条路并行，兼顾低延迟交互和高并发分发，这是实践中反复验证的折衷。

      连麦与NAT穿透常常是故障根源。部署coturn做TURN服务，配合短连接的WebSocket信令，能显著提升移动端成功率。调试时我常用chrome://webrtc-internals抓取RTP统计，再用tcpdump和ffprobe对比丢包与关键帧间隔，问题多数出在编码器设定或MTU不匹配，这类细节别轻视。

      大规模观众场景，引入CDN和边缘转发是必然。工程上把转码放在边缘节点，采用ABR（多码率分发）并结合低延迟HLS或LL-CMAF，可以在不牺牲连麦体验的前提下扩展到十万级观众。我个人实践中对GPU转码（NVENC/VA-API）依赖较大，但要注意容器中驱动与权限问题，常用nvidia-docker与调度策略解决。

      互动功能（弹幕、投票、打赏）不应与媒体链耦合。用独立的消息层：WebSocket或MQTT负责实时事件，Redis做轻量状态管理，Kafka作为可靠流水线。经验告诉我，保持媒体链专注于时延与质量，业务逻辑在外层解耦，故障恢复更快，开发迭代也更顺畅。

      性能与监控是反复优化的战场。Prometheus + Grafana采集CPU/GPU利用率、RTT、丢包率和Pacer比率；报警规则要贴近业务SLA，而非单纯阈值。我习惯把SLO设为“用户端观测到的首帧时间”和“连麦成功率”，这两项改变时就会推动底层策略调整——比如降码、切换SFU实例或临时启用FEC。

      结尾留下一点实践建议：先用小规模多场景灰度验证技术路径，再在边缘部署能力逐步放大。工具链上优先选择可观测且社区活跃的组件，遇到性能异常先从网络和编码参数排查。未来也许会更多接入AV1或基于QUIC的传输，但现阶段以稳定、可运维为主导，通常更可靠。