前言
计划重新构建一套
音视频大型会议直播系统，底层使用mediasoup，信令业务层使用Golang，前端使用uniapp + mediasoup-client，然后就是数据库服务postgresql+redis等等，一步一步，逐步来
太好了，这一步你已经从"技术选型"迈进到系统工程设计了。我会把这份项目计划写成一份可直接作为你后续详细设计蓝本的总纲，而不是泛泛而谈的 PPT 文案。
下面内容分 7 个部分，你可以把它当成「音视频会议系统 0→1 架构说明书」。
⸻
一、项目整体目标与定位
🎯 项目目标
构建一套 跨端可用、可扩展、可演进 的实时音视频系统，支持：
• 多人音视频会议
• 互动直播室
• 后期可扩展：录制、转推、跨服务器、超大房间
🎯 技术核心思想
控制面与媒体面彻底分离
业务系统与实时系统解耦
这是你选用 Go + mediasoup 的最大价值所在。
⸻
二、整体技术架构（总览）
技术栈总览
cpp
┌────────────────────────────┐
│ Client 层 │
│ uniapp + mediasoup-client │
└───────────▲────────────────┘
│ WebSocket / HTTPS
┌───────────┴────────────────┐
│ Go 控制层 │
│ (信令 / 会议 / 鉴权) │
└───────────▲────────────────┘
│ RPC / HTTP
┌───────────┴────────────────┐
│ mediasoup Node 层 │
│ (媒体控制 API) │
└───────────▲────────────────┘
│ IPC
┌───────────┴────────────────┐
│ mediasoup Worker │
│ (C++ SFU) │
└────────────────────────────┘⸻
三、各组成部分详细说明（这是核心）
1️⃣ 客户端层（uniapp + mediasoup-client）
📌 构成
• uniapp
• UI、页面、交互
• 多端统一（H5 / App / 小程序）
• mediasoup-client
• WebRTC 协商
• 音视频采集 / 编码 / 发送 / 接收
📌 uniapp职责
📌 mediasoup-client 核心作用一句话
把"业务信令"翻译成"浏览器能跑的 WebRTC 行为"
📌 与其他模块的连接
• WebSocket ⇄ Go 信令层
• RTP / DTLS ⇄ mediasoup Worker（直连）
⸻
2️⃣ Go 控制层（系统中枢）
这是整个系统的"大脑"
📌 核心职责
✅ 信令系统
• WebSocket 长连接
• 消息广播
• 状态同步
✅ 会议系统
• 房间创建 / 销毁
• 用户进房 / 退房
• 主持人 / 角色管理
• 发言权限控制
✅ 安全与鉴权
• JWT / Token
• 防止客户端滥用 mediasoup API
✅ 媒体控制编排
• 什么时候创建 Transport
• 什么时候 Produce / Consume
• 什么时候关闭流
📌 不负责的事情（很重要）
• ❌ 不处理 RTP
• ❌ 不参与媒体转发
• ❌ 不做 WebRTC 协议
📌 与其他模块的连接
⸻
3️⃣ mediasoup Node 层（媒体控制适配层）
📌 本质定位
C++ SFU 的"遥控器"
📌 职责
• 管理 Worker
• 创建 Router
• 创建 WebRtcTransport
• 管理 Producer / Consumer
📌 特点
• 不懂业务
• 不懂用户
• 只懂"媒体对象"
📌 为什么单独拆出来？
• C++ Worker 高性能
• Node 层方便控制与扩展
• 解耦 Go 与 C++
⸻
4️⃣ mediasoup Worker（真正的 SFU）
📌 这是"发动机"
负责：
• RTP 转发
• 拥塞控制
• 带宽自适应
• 多人流转发
📌 特点
• 极高性能
• 完全不关心业务
• 媒体一旦开始，不再经过 Go
⸻
5️⃣ PostgreSQL（强一致数据）
📌 存什么？
• 用户
• 房间元信息
• 会议记录
• 权限配置
📌 特点
• 强一致
• 可审计
• 不放"实时状态"
⸻
6️⃣ Redis（实时状态 & 协调）
📌 存什么？
• 房间在线用户
• Transport / Producer 映射
• 用户状态（mute / speaking）
• 跨 Go 实例共享状态
📌 特点
• 高速
• 非持久
• 非常适合会议系统
⸻
7️⃣ 消息中间件（可选但推荐）
📌 什么时候需要？
• 多 Go 实例
• 跨服务器会议
• 录制 / 转码 / AI 分析
📌 用途
• 会议事件分发
• 异步处理
• 解耦系统模块
⸻
四、系统运行时的完整流程（简化版）
cpp
1. 用户打开客户端
2. WebSocket 连接 Go
3. Go 校验并允许进房
4. Go 调用 mediasoup 创建资源
5. 前端 mediasoup-client 建立 WebRTC
6. 媒体流直达 mediasoup Worker
7. Go 只负责控制和状态⸻
五、这样设计的好处（非常关键）
✅ 高性能
• 媒体流不经过 Go
• SFU 专注转发
✅ 高可扩展
• Go 可横向扩展
• Worker 可多进程 / 多机
✅ 易演进
• 后期加录制、转推、AI
• 不影响现有会议
✅ 技术边界清晰
• Go 写业务
• JS 写 WebRTC
• C++ 跑媒体
⸻
六、这个方案非常"工程化"的原因
这个方案已经是"公司级音视频系统"的标准形态
这套架构：
• 腾讯会议
• Zoom
• 飞书会议
在思想上都是一致的
⸻