前言

计划重新构建一套 音视频大型会议直播 系统，底层使用 mediasoup ，信令业务层使用 Golang ，前端使用 uniapp + mediasoup-client ，然后就是数据库服务postgresql+redis等等，一步一步，逐步来

从“技术选型”迈进到系统工程设计。项目计划可直接作为后续详细设计蓝本的总纲，不是泛泛而谈的 PPT 文案。

下面内容分 7 个部分，可以把它当成「音视频会议系统 0→1 架构说明书」。

---

一、项目整体目标与定位

🎯 项目目标

构建一套 跨端可用、可扩展、可演进 的实时音视频系统，支持：

•	多人音视频会议
•	互动直播室
•	后期可扩展：录制、转推、跨服务器、超大房间

🎯 技术核心思想

•	控制面与媒体面彻底分离 
•	业务系统与实时系统解耦

这是选用 Go + mediasoup 的最大价值所在。

---

二、整体技术架构（总览）

技术栈总览

┌────────────────────────────┐
│        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的职责

📌 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 分析

📌 用途

•	会议事件分发
•	异步处理
•	解耦系统模块

---

四、系统运行时的完整流程（简化版）

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
•	飞书会议

在思想上都是一致的

---