前言

• 这一篇是 关于 Go服务端相关的音视频会议的接口API业务逻辑流程图
• 肯定是不能完全复用到你的项目中去的，但是希望对你有一些参考性的帮助
• 嗯，我也是在不断的进行完善和优化，并不是最终的结构，先定好大方向，然后不断调整

EchoMeet 会议API接口流程图文档

本文档详细描述了EchoMeet会议系统中各个API接口的完整执行流程，包括Controller层、Service层、DAO层的调用关系和业务逻辑处理。

📋 目录

1. 创建会议流程图
2. 加入会议流程图
3. 离开会议流程图
4. 结束会议流程图
5. 获取会议详情流程图
6. 获取用户会议列表流程图
7. WebSocket实时通信流程图
8. 架构设计说明

---

1. 创建会议流程图

API路由：POST /api/v1/meetings

关键业务逻辑：

• 参数验证：验证会议标题、时间格式、持续时间（最长8小时）
• 用户验证：确认创建者存在且有效
• 会议代码生成：6位随机字符串，确保唯一性
• 密码处理：可选密码加密存储
• 数据持久化：MySQL存储 + Redis缓存
• 响应构造：返回完整的会议信息

---

2. 加入会议流程图

API路由：POST /api/v1/meetings/:id/join

关键业务逻辑：

• 多重验证：会议存在性、状态、密码、人数限制、重复加入
• 状态自动更新：首个用户加入时自动将会议状态改为"进行中"
• 参与者管理：记录加入时间、角色分配（默认为普通参与者）
• 数据聚合：返回会议信息、参与者列表、历史消息
• WebSocket准备：为实时通信做好数据准备

---

3. 离开会议流程图

API路由：POST /api/v1/meetings/:id/leave

关键业务逻辑：

• 权限检查：验证用户确实在会议中
• 主持人逻辑：主持人离开时的特殊处理
• 自动结束：最后一个参与者离开时自动结束会议
• 权限转移：计划中的主持人权限转移功能
• 状态同步：更新参与者状态和会议状态

---

4. 结束会议流程图

API路由：POST /api/v1/meetings/:id/end

关键业务逻辑：

• 严格权限控制：只有主持人和协作主持人可以结束会议
• 状态一致性：同时更新会议状态和所有参与者状态
• 批量操作：高效处理多个参与者的状态更新
• 缓存清理：确保Redis中的会议缓存被及时清理
• 完整日志：记录会议结束的详细信息

---

5. 获取会议详情流程图

API路由：GET /api/v1/meetings/:id

关键业务逻辑：

• 细粒度权限控制：创建者、参与者、公开会议的不同访问权限
• 数据聚合：整合会议信息、创建者信息、参与者统计
• 状态文本转换：将数字状态码转换为可读文本
• 实时统计：计算当前在线参与者数量
• 完整响应：提供前端所需的所有会议详情

---

6. 获取用户会议列表流程图

API路由：GET /api/v1/meetings

关键业务逻辑：

• 灵活过滤：支持多种条件组合过滤会议
• 分页处理：高效的分页查询和结果返回
• 数据聚合：为每个会议获取完整的展示信息
• 性能优化：批量处理，减少数据库查询次数
• 用户权限：区分"我创建的"和"我参与的"会议

---

7. WebSocket实时通信流程图

WebSocket连接：ws://localhost:8081/ws

WebSocket消息类型：

• join_room：用户加入会议房间
• leave_room：用户离开会议房间
• chat_message：发送聊天消息
• media_control：音视频控制（开启/关闭）
• webrtc_signal：WebRTC信令交换

---

8. 架构设计说明

8.1 分层架构

┌─────────────────┐
│   Controller层   │  ← HTTP请求处理、参数验证、响应格式化
├─────────────────┤
│    Service层     │  ← 业务逻辑处理、事务管理、数据转换
├─────────────────┤
│     DAO层       │  ← 数据库操作、查询优化、事务执行
├─────────────────┤
│   Database层    │  ← MySQL数据持久化、Redis缓存
└─────────────────┘

8.2 数据流向

1. HTTP Request → Controller → Service → DAO → Database
2. Database → DAO → Service → Controller → HTTP Response
3. WebSocket Message → WebSocket Handler → Service → DAO → Database
4. Database Change → Service → WebSocket Broadcast → Frontend Update

8.3 关键设计原则

• 职责分离：每层只处理自己的职责，不跨层调用
• 依赖注入：使用Wire进行依赖管理，便于测试和维护
• 错误处理：统一的错误码和错误信息管理
• 日志记录：每个关键操作都有详细的日志记录
• 事务管理：确保数据的一致性和完整性
• 缓存策略：使用Redis缓存频繁访问的数据
• 实时通信：WebSocket与HTTP API的协调工作

8.4 性能优化措施

• 连接池管理：数据库和Redis连接池优化
• 批量操作：减少数据库查询次数
• 索引优化：关键字段建立索引
• 缓存策略：热点数据Redis缓存
• 异步处理：非关键操作异步化
• 分页查询：大数据量分页处理

---

总结

本文档详细描述了EchoMeet会议系统的核心API流程，涵盖了从会议创建到结束的完整生命周期，以及WebSocket实时通信的处理逻辑。每个流程图都展示了详细的业务逻辑和错误处理，为开发和维护提供了清晰的指导。

系统采用严格的分层架构，确保了代码的可维护性和可扩展性，同时通过完善的错误处理和日志记录机制，保证了系统的稳定性和可观测性。