feat:boke参考
This commit is contained in:
bujinyuan
266
boke.md
Normal file
266
boke.md
Normal file
@@ -0,0 +1,266 @@
|
|||||||
|
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的职责
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
#### 📌 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
|
||||||
|
• 飞书会议
|
||||||
|
在思想上都是一致的
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Reference in New Issue
Block a user