# EchoChat 系统架构设计 > 本文档从整体设计方案中提取并深化架构设计部分，便于独立查阅。 > 完整设计方案见 `docs/plans/2026-02-27-echochat-system-design.md` --- ## 一、架构概述 EchoChat 采用 **「精简单体 + 媒体微服务」** 架构，核心思想是 **控制面与媒体面彻底分离、业务系统与实时系统解耦**。 - **Go 单体服务**：处理所有业务逻辑（认证、IM、会议控制、好友、通知、后台管理），内部按模块化组织，保留后期拆分为微服务的能力 - **mediasoup Node 服务**：独立的媒体控制微服务，管理 SFU Worker，不涉及任何业务逻辑 - **mediasoup Worker**：C++ SFU 引擎，负责 RTP 转发、拥塞控制、带宽自适应 --- ## 二、架构分层图 ``` ┌─────────────────────────────────────────────────────────────┐ │ 接入层 (Nginx) │ │ SSL 终止 · 反向代理 · WebSocket 升级 · 静态资源 · 负载均衡 │ └─────┬───────────────────────┬───────────────────────────────┘ │ │ │ HTTPS / WSS │ HTTPS │ │ ┌─────┴──────────┐ ┌──────┴──────────┐ │ 前台用户端 │ │ 后台管理端 │ │ uniapp │ │ Vue3+Element │ │ (H5/App/小程序)│ │ Plus (PC Web) │ └─────┬──────────┘ └──────┬──────────┘ │ │ │ WebSocket + HTTP │ HTTP (RESTful) │ │ ┌─────┴───────────────────────┴──────────────────────────────┐ │ Go 单体服务（模块化） │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ auth │ │ im │ │ meeting │ │ admin │ │ │ │ 认证鉴权 │ │ 即时通讯 │ │ 会议控制 │ │ 后台管理 │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────────┘ │ │ ┌──────────┐ ┌──────────┐ │ │ │ contact │ │ notify │ 每个模块: Controller → │ │ │ 联系人 │ │ 通知 │ Service → DAO → Model │ │ └──────────┘ └──────────┘ │ │ │ │ │ │ │ ┌────┴──────────────┴──────────────┴──────┐ │ │ │ 公共基础设施层 (pkg/) │ │ │ │ db · redis · ws · middleware · utils │ │ │ └─────────────────────────────────────────┘ │ └────────┬──────────────────────┬─────────────────────────────┘ │ │ PostgreSQL Redis HTTP (持久化数据) (实时状态) │ ┌─────┴─────────────┐ │ mediasoup Node 服务 │ │ Router 管理 │ │ Transport 管理 │ │ Producer/Consumer │ └─────┬─────────────┘ │ IPC ┌─────┴─────────────┐ │ mediasoup Worker │ │ (C++ SFU 引擎) │ │ RTP 转发 │ │ 拥塞控制 │ │ 带宽自适应 │ └───────────────────┘ ``` --- ## 三、各层职责说明 ### 3.1 接入层 (Nginx) | 职责 | 说明 | |------|------| | SSL 终止 | 处理 HTTPS/WSS 加密，内部服务间通信使用 HTTP | | 反向代理 | 将请求分发到 Go 服务或前端静态资源 | | WebSocket 升级 | 处理 WebSocket 协议升级 | | 负载均衡 | 后期多实例部署时进行请求分发 | ### 3.2 Go 单体服务 系统的 **"大脑"**，处理所有业务逻辑。 | 模块 | 职责 | |------|------| | auth | 用户注册/登录、JWT Token 管理、RBAC 角色权限 | | im | 即时消息收发、会话管理、消息存储 | | contact | 好友关系管理、好友分组 | | meeting | 会议创建/管理、信令转发、mediasoup 资源编排 | | notify | 通知推送、会议邀请、好友申请通知 | | admin | 后台管理（用户管理、会议监控、系统配置） | **不负责的事情：** 不处理 RTP 媒体数据、不参与音视频转发、不做 WebRTC 协议协商。 ### 3.3 mediasoup Node 服务 mediasoup C++ SFU 的 **"遥控器"**，不懂业务、不懂用户、只懂媒体对象。 | 职责 | 说明 | |------|------| | Worker 管理 | 创建和管理 mediasoup C++ Worker 进程 | | Router 管理 | 每个会议房间对应一个 Router | | Transport 管理 | 为每个参与者创建 WebRTC Transport | | Producer/Consumer | 管理音视频流的推送和消费 | ### 3.4 mediasoup Worker 真正的 **"发动机"**，纯 C++ 实现的 SFU 引擎。 | 职责 | 说明 | |------|------| | RTP 转发 | 接收发送者的 RTP 包，转发给所有接收者 | | 拥塞控制 | 根据网络状况动态调整 | | 带宽自适应 | Simulcast/SVC 支持 | --- ## 四、数据流说明 ### 4.1 即时消息流 ``` 客户端A Go 服务 客户端B │ │ │ │── WS: 发送消息 ──→ │ │ │ │── 写入 PostgreSQL │ │ │── 更新 Redis 未读数 │ │ ←── WS: 发送确认 ──│ │ │ │── WS: 推送新消息 ────────→ │ │ │ │ ``` ### 4.2 音视频会议流 ``` 客户端 Go 服务 mediasoup Node Worker │ │ │ │ │── HTTP: 加入会议 → │ │ │ │ │── HTTP: 创建Router→│ │ │ │ ←── RTP能力 ──────│ │ │ ←── WS: 房间信息 ──│ │ │ │ │ │ │ │── WS: 创建Transport→│ │ │ │ │── HTTP: 创建 ────→ │── IPC ──────→ │ │ ←── WS: Transport参数│ │ │ │ │ │ │ │── WS: 开始推流 ──→ │ │ │ │ │── HTTP: Producer → │── IPC ──────→ │ │ │ │ │ │════════════════ RTP/DTLS 媒体流直连 ═══════════════════→│ │ (音视频数据不经过 Go 服务，直连 Worker) │ ``` --- ## 五、微服务演进路径 当前架构从第一天起就为微服务拆分做了准备： ### 5.1 代码层面的预留 | 规则 | 说明 | |------|------| | 模块间零直接引用 | `auth` 不会 import `im` 内部代码，通过 interface 通信 | | 独立路由注册 | 每个模块有自己的 `router.go`，注册独立的路由组 | | 数据库表按模块前缀 | `auth_users`、`im_messages`、`meeting_rooms`，后期可分库 | | Redis key 按命名空间 | `echo:auth:*`、`echo:im:*`、`echo:meeting:*` | ### 5.2 演进路径 ``` 第一阶段（当前） 第二阶段 第三阶段 ┌─────────────┐ ┌──────────────────┐ ┌─────────────────┐ │ Go 单体服务 │ → │ Go 实时服务 │ → │ auth-service │ │ (模块化) │ │ (信令+会议+IM) │ │ im-service │ │ │ │ │ │ meeting-service │ │ │ │ Go 业务服务 │ │ contact-service │ │ │ │ (用户+好友+管理) │ │ admin-service │ └─────────────┘ └──────────────────┘ └─────────────────┘ + API Gateway + 服务发现 + 链路追踪 ``` --- ## 六、部署架构 ### 6.1 开发环境 (Docker Compose) ```yaml services: go-service: # Go 后端 → :8080 media-server: # mediasoup Node → :3000 + :40000-40100/udp postgres: # PostgreSQL 16 → :5432 redis: # Redis 7 → :6379 nginx: # 反向代理 → :80/:443 ``` ### 6.2 生产环境 (预留 K8s) ``` ┌─────────────────────────────────────────┐ │ Kubernetes 集群 │ │ │ │ ┌─────────┐ ┌─────────┐ │ │ │ Go Pod │ │ Go Pod │ (水平扩展) │ │ │ (副本1) │ │ (副本N) │ │ │ └────┬────┘ └────┬────┘ │ │ └──────┬─────┘ │ │ │ │ │ ┌───────────┴───────────┐ │ │ │ Service (LB) │ │ │ └───────────────────────┘ │ │ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ mediasoup │ │ mediasoup │ │ │ │ Pod (副本1) │ │ Pod (副本N) │ │ │ └──────────────┘ └──────────────┘ │ │ │ │ PostgreSQL (StatefulSet / 外部 RDS) │ │ Redis (StatefulSet / 外部 ElastiCache) │ └─────────────────────────────────────────┘ ``` --- ## 七、技术选型依据 | 技术 | 选型理由 | |------|---------| | **Go (Gin)** | 高并发、静态编译、内存占用小，适合实时系统 | | **GORM** | Go 生态最成熟的 ORM，社区活跃 | | **Wire** | 编译时依赖注入，零运行时开销 | | **zap** | 高性能结构化日志，Uber 出品 | | **Viper** | 配置管理标准库，支持 YAML + 环境变量覆盖 | | **mediasoup** | 最高性能的开源 SFU，C++ 实现 | | **PostgreSQL 16** | 强一致性、JSONB 支持、性能优异 | | **Redis 7** | 实时状态存储、发布订阅、高速缓存 | | **uniapp (Vue 3)** | 一套代码多端运行（H5/App/小程序） | | **Element Plus** | Vue 3 生态最成熟的 PC 端组件库 | | **Docker Compose** | 轻量级容器编排，适合初期和开发环境 |