音视频会议服务搭建(设计方案-Go服务端API业务逻辑流程图)-04

前言

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

EchoMeet 会议API接口流程图文档

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

📋 目录

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

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 数据流向

  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实时通信的处理逻辑。每个流程图都展示了详细的业务逻辑和错误处理,为开发和维护提供了清晰的指导。

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