image.png
# 前言

> 计划重新构建一套 `音视频大型会议直播` 系统，底层使用` 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的职责

![职责	是否负责
UI 展示	✅
摄像头 / 麦克风	✅
WebRTC 连接	✅
会议规则	❌
房间管理	❌](https://i-blog.csdnimg.cn/direct/022e41e28c9a47c3be74c77aabaed381.png)


#### 📌 mediasoup-client 核心作用一句话
	•	把“业务信令”翻译成“浏览器能跑的 WebRTC 行为”

#### 📌 与其他模块的连接
	•	WebSocket ⇄ Go 信令层
	•	RTP / DTLS ⇄ mediasoup Worker（直连）

---

### 2️⃣ Go 控制层（系统中枢）

这是整个系统的“大脑”

#### 📌 核心职责

##### ✅ 信令系统
	•	WebSocket 长连接
	•	消息广播
	•	状态同步

##### ✅ 会议系统
	•	房间创建 / 销毁
	•	用户进房 / 退房
	•	主持人 / 角色管理
	•	发言权限控制

##### ✅ 安全与鉴权
	•	JWT / Token
	•	防止客户端滥用 mediasoup API

##### ✅ 媒体控制编排
	•	什么时候创建 Transport
	•	什么时候 Produce / Consume
	•	什么时候关闭流

#### 📌 不负责的事情（很重要）
	•	❌ 不处理 RTP
	•	❌ 不参与媒体转发
	•	❌ 不做 WebRTC 协议

#### 📌 与其他模块的连接

![对象	方式
客户端	WebSocket
mediasoup Node	HTTP / RPC
Redis	状态缓存
PostgreSQL	持久化](https://i-blog.csdnimg.cn/direct/b0b592baa6974635b8af8fbd13053c03.png)



---

### 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
	•	飞书会议
在思想上都是一致的

---




