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