
前言
- 这一篇是 关于
Go服务端相关的音视频会议的接口API业务逻辑流程图
- 肯定是
不能完全复用
到你的项目中去的,但是希望对你有一些参考性的帮助- 嗯,我也是在不断的进行完善和优化,并不是最终的结构,
先定好大方向,然后不断调整
EchoMeet 会议API接口流程图文档
本文档详细描述了EchoMeet会议系统中各个API接口的完整执行流程,包括Controller层、Service层、DAO层的调用关系和业务逻辑处理。
📋 目录
1. 创建会议流程图
API路由:POST /api/v1/meetings
失败 成功 前端发起创建会议请求 POST /api/v1/meetings Controller.CreateMeeting
解析请求参数 参数验证 返回400错误 获取用户ID from JWT Service.CreateMeeting 验证创建者存在 解析时间格式 生成会议代码 创建Meeting实体 密码加密处理 DAO.Create保存到MySQL 缓存会议信息到Redis 构造MeetingResponse 返回201成功响应
关键业务逻辑:
- 参数验证:验证会议标题、时间格式、持续时间(最长8小时)
- 用户验证:确认创建者存在且有效
- 会议代码生成:6位随机字符串,确保唯一性
- 密码处理:可选密码加密存储
- 数据持久化:MySQL存储 + Redis缓存
- 响应构造:返回完整的会议信息
2. 加入会议流程图
API路由:POST /api/v1/meetings/:id/join
失败 成功 已结束/已取消 正常 密码错误 密码正确 人数已满 未满 已在会议中 未在会议中 是 否 前端发起加入会议请求 POST /api/v1/meetings/:id/join Controller.JoinMeeting
解析会议ID和请求参数 验证会议ID和用户认证 返回400/401错误 Service.JoinMeeting DAO.GetByID验证会议存在 检查会议状态 返回400错误 检查会议密码 返回400错误 检查人数限制 返回400错误 检查用户是否已在会议中 返回400错误 AddOrUpdateParticipant
添加参与者记录 会议状态是否为未开始 更新会议状态为进行中
设置实际开始时间 获取会议详情 获取参与者列表 获取历史消息 构造JoinResponse响应 返回200成功响应
关键业务逻辑:
- 多重验证:会议存在性、状态、密码、人数限制、重复加入
- 状态自动更新:首个用户加入时自动将会议状态改为"进行中"
- 参与者管理:记录加入时间、角色分配(默认为普通参与者)
- 数据聚合:返回会议信息、参与者列表、历史消息
- WebSocket准备:为实时通信做好数据准备
3. 离开会议流程图
API路由:POST /api/v1/meetings/:id/leave
失败 成功 不在会议中 在会议中 普通参与者 主持人 有其他参与者 无其他参与者 前端发起离开会议请求 POST /api/v1/meetings/:id/leave Controller.LeaveMeeting
解析会议ID 验证会议ID和用户认证 返回400/401错误 Service.LeaveMeeting DAO.GetByID验证会议存在 DAO.GetParticipant获取参与者信息 检查用户是否在会议中 返回400错误 UpdateParticipantStatus
更新状态为已离开 检查是否为主持人 记录离开日志 GetMeetingParticipants
获取其他参与者 是否还有其他参与者 TODO: 转移主持人权限 EndMeeting自动结束会议 更新会议状态为已结束 更新所有参与者状态为已离开 清理Redis缓存 返回200成功响应
关键业务逻辑:
- 权限检查:验证用户确实在会议中
- 主持人逻辑:主持人离开时的特殊处理
- 自动结束:最后一个参与者离开时自动结束会议
- 权限转移:计划中的主持人权限转移功能
- 状态同步:更新参与者状态和会议状态
4. 结束会议流程图
API路由:POST /api/v1/meetings/:id/end
失败 成功 非主持人/协作主持人 有权限 已结束/已取消 进行中/未开始 前端发起结束会议请求 POST /api/v1/meetings/:id/end Controller.EndMeeting
解析会议ID 验证会议ID和用户认证 返回400/401错误 Service.EndMeeting DAO.GetByID验证会议存在 DAO.GetParticipant获取参与者信息 检查用户权限 返回403权限错误 检查会议状态 返回400错误 更新会议状态为已结束
设置实际结束时间 DAO.Update保存会议状态 GetMeetingParticipants
获取所有参与者 循环更新所有在线参与者
状态为已离开 UpdateParticipantStatus
批量处理参与者 clearMeetingCache
清理Redis缓存 记录结束日志 返回200成功响应
关键业务逻辑:
- 严格权限控制:只有主持人和协作主持人可以结束会议
- 状态一致性:同时更新会议状态和所有参与者状态
- 批量操作:高效处理多个参与者的状态更新
- 缓存清理:确保Redis中的会议缓存被及时清理
- 完整日志:记录会议结束的详细信息
5. 获取会议详情流程图
API路由:GET /api/v1/meetings/:id
失败 成功 不存在 存在 无权限 有权限 是 否 是 否 是 否 前端发起获取会议详情请求 GET /api/v1/meetings/:id Controller.GetMeetingInfo
解析会议ID 验证会议ID和用户认证 返回400/401错误 Service.GetMeetingByID DAO.GetByID获取会议基本信息 会议是否存在 返回404错误 checkMeetingPermission
检查用户权限 用户是否有权限访问 返回403错误 UserDAO.GetInfoById
获取创建者信息 DAO.GetMeetingParticipants
获取参与者列表 构造MeetingResponse响应 设置会议基本信息
状态文本/参与者数量等 返回200成功响应 checkMeetingPermission详细逻辑 是否为创建者 有权限 是否为参与者 是否为公开会议 无权限
关键业务逻辑:
- 细粒度权限控制:创建者、参与者、公开会议的不同访问权限
- 数据聚合:整合会议信息、创建者信息、参与者统计
- 状态文本转换:将数字状态码转换为可读文本
- 实时统计:计算当前在线参与者数量
- 完整响应:提供前端所需的所有会议详情
6. 获取用户会议列表流程图
API路由:GET /api/v1/meetings
失败 成功 仅参与的会议 所有会议 前端发起获取会议列表请求 GET /api/v1/meetings?page=1&pageSize=10 Controller.GetUserMeetings
解析查询参数 验证用户认证 返回401错误 Service.GetUserMeetings 构建查询条件
状态/创建者/关键词/时间范围 检查OnlyJoined参数 DAO.GetUserMeetings
查询用户参与的会议 DAO.GetList
根据条件查询所有会议 循环处理会议列表 获取每个会议的创建者信息 获取每个会议的参与者统计 构造MeetingResponse列表 计算分页信息 构造MeetingListResponse 返回200成功响应 查询条件构建详情 状态过滤: 未开始/进行中/已结束 创建者过滤: 指定用户ID 关键词搜索: 标题/描述模糊匹配 时间范围: 开始时间/结束时间 私有会议: 是否有密码 录制会议: 是否启用录制
关键业务逻辑:
- 灵活过滤:支持多种条件组合过滤会议
- 分页处理:高效的分页查询和结果返回
- 数据聚合:为每个会议获取完整的展示信息
- 性能优化:批量处理,减少数据库查询次数
- 用户权限:区分"我创建的"和"我参与的"会议
7. WebSocket实时通信流程图
WebSocket连接:ws://localhost:8081/ws
失败 成功 join_room leave_room chat_message media_control webrtc_signal 前端建立WebSocket连接 ws://localhost:8081/ws WebSocket.HandleConnection JWT Token验证 认证是否成功 关闭连接 ConnectionManager.AddConnection 开始消息监听循环 接收WebSocket消息 解析消息类型 RoomHandler.HandleJoinRoom RoomHandler.HandleLeaveRoom RoomHandler.HandleChatMessage MediaHandler.HandleMediaControl WebRTCHandler.HandleSignal 验证会议权限 AddOrUpdateParticipant 更新连接状态为在线 广播用户加入消息 UpdateParticipantStatus 更新连接状态为离线 广播用户离开消息 SaveChatMessage保存到数据库 广播聊天消息给所有参与者 UpdateParticipantMedia 广播媒体状态变化
WebSocket消息类型:
- join_room:用户加入会议房间
- leave_room:用户离开会议房间
- chat_message:发送聊天消息
- media_control:音视频控制(开启/关闭)
- webrtc_signal:WebRTC信令交换
8. 架构设计说明
8.1 分层架构
┌─────────────────┐
│ Controller层 │ ← HTTP请求处理、参数验证、响应格式化
├─────────────────┤
│ Service层 │ ← 业务逻辑处理、事务管理、数据转换
├─────────────────┤
│ DAO层 │ ← 数据库操作、查询优化、事务执行
├─────────────────┤
│ Database层 │ ← MySQL数据持久化、Redis缓存
└─────────────────┘
8.2 数据流向
- HTTP Request → Controller → Service → DAO → Database
- Database → DAO → Service → Controller → HTTP Response
- WebSocket Message → WebSocket Handler → Service → DAO → Database
- Database Change → Service → WebSocket Broadcast → Frontend Update
8.3 关键设计原则
- 职责分离:每层只处理自己的职责,不跨层调用
- 依赖注入:使用Wire进行依赖管理,便于测试和维护
- 错误处理:统一的错误码和错误信息管理
- 日志记录:每个关键操作都有详细的日志记录
- 事务管理:确保数据的一致性和完整性
- 缓存策略:使用Redis缓存频繁访问的数据
- 实时通信:WebSocket与HTTP API的协调工作
8.4 性能优化措施
- 连接池管理:数据库和Redis连接池优化
- 批量操作:减少数据库查询次数
- 索引优化:关键字段建立索引
- 缓存策略:热点数据Redis缓存
- 异步处理:非关键操作异步化
- 分页查询:大数据量分页处理
总结
本文档详细描述了EchoMeet会议系统的核心API流程,涵盖了从会议创建到结束的完整生命周期,以及WebSocket实时通信的处理逻辑。每个流程图都展示了详细的业务逻辑和错误处理,为开发和维护提供了清晰的指导。
系统采用严格的分层架构,确保了代码的可维护性和可扩展性,同时通过完善的错误处理和日志记录机制,保证了系统的稳定性和可观测性。