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