在线联机原型全集：第 1 章　聊天室（Echo Chatroom）

聊天室（Echo Chatroom）

• 类别：网络通信基础原型
• 目标：验证在线通信系统的最小可行架构，作为后续所有多人游戏的底座。
• 原型代号：proto-001-echo-chatroom
• 版本：v1.0
• 推荐语言栈：Go / Node.js / Rust
• 网络协议：WebSocket over HTTPS

一、概述（Overview）

“回声聊天室（Echo Chatroom）” 是所有在线联机系统的最小原型。

在任何网络游戏、多人协作应用、甚至分布式系统的开发早期，
最关键的验证点并不是复杂的逻辑，而是“是否能可靠地建立、维持、
管理并监控一个持续存在的实时通信通道”。

聊天室的本质是：

连接、身份、状态、消息、广播、心跳、恢复。

因此它不仅是一种简单的“产品体验”，更是整个联机架构的基础模块。
在后续的 59 个原型中，这个聊天室会作为“网关 / Session Hub”存在，
支撑匹配、回合、状态同步、观战、回放、甚至 AI 驱动的系统交互。

一句话定义：

“回声聊天室是所有在线系统的 Hello World ——
一条消息的往返，意味着你的世界开始有了生命。”

二、核心玩法与系统目标（Gameplay & Objectives）

2.1 产品体验简述

• 用户可以登录聊天室，与他人实时发送消息；
• 支持房间创建、加入、退出；
• 支持表情、文本、系统通知等多种消息类型；
• 断线后可自动重连，并恢复消息流；
• 支持同时存在多个房间（如“大厅”、“私聊”、“频道”）。

2.2 功能目标

三、系统架构设计（Architecture）

3.1 系统组成

graph TD
A["Client Web/Mobile"] -->|WebSocket| B["Gateway Server"]
B --> C["Session Manager"]
B --> D["Room Service"]
B --> E["Message Dispatcher"]
E --> F["Redis Pub/Sub"]
E --> G["Metrics & Logging"]

模块说明：

3.2 架构分层

1. 接入层（Access Layer）

   • WebSocket Server
   • JWT 校验中间件
   • 连接上下文注入

2. 逻辑层（Logic Layer）

   • 房间状态管理（Room → Users）
   • 消息路由与广播（Topic-based Routing）
   • 指令分发器（Command Dispatcher）

3. 存储层（Storage Layer）

   • Redis（Session + Pub/Sub）
   • PostgreSQL（Message Archive）
   • Loki（日志查询）

4. 监控层（Metrics Layer）

   • Prometheus（连接、延迟、消息吞吐）
   • Grafana（可视化监控）

3.3 架构特性

四、功能模块详解（Functional Modules）

4.1 Gateway Server 模块

职责：

• 管理所有连接会话；
• 建立 WebSocket 握手；
• 维持心跳；
• 转发消息到 Room Service。

主要接口：

事件序列：

onConnect → verifyJWT → registerSession → joinRoom → ready

4.2 Session Manager 模块

• 存储每个用户的连接状态：
  {user_id, conn_id, room_id, last_ping}
• 管理断线恢复：
  若 30 秒内重连相同 user_id → 恢复 Session。

4.3 Room Service 模块

数据结构：

type Room struct {
  ID string
  Members map[string]*Session
  History []Message
}

核心操作：

• CreateRoom()
• JoinRoom(userID)
• LeaveRoom(userID)
• Broadcast(message)

4.4 Message Dispatcher 模块

负责消息分发逻辑：

1. 校验消息格式；
2. 写入 Redis Channel；
3. 分发到所有连接节点；
4. 异步写入 PostgreSQL。

消息模型：

{
  "type": "text",
  "room": "001",
  "from": "u01",
  "content": "Hello world",
  "timestamp": 1730688000
}

4.5 Metrics & Logging 模块

监控指标：

日志记录采用结构化 JSON，方便 Loki 搜索。

五、状态机与流程图（State & Flow）

5.1 状态机

stateDiagram-v2
  [*] --> Disconnected
  Disconnected --> Connecting: connect()
  Connecting --> Authenticating: JWT verify
  Authenticating --> Joined: join_room
  Joined --> Active: receive/send messages
  Active --> Reconnecting: network lost
  Reconnecting --> Active: recover session
  Active --> Disconnected: logout/timeout

5.2 消息生命周期

sequenceDiagram
Client->>Gateway: send(message)
Gateway->>RoomService: forward(message)
RoomService->>Dispatcher: publish(message)
Dispatcher->>Redis: push to channel
Redis-->>AllNodes: broadcast
AllNodes-->>Clients: deliver(message)
Client->>User: display

六、事件与接口定义（API Specification）

6.1 WebSocket 消息类型

七、数据模型（Data Schema）

消息表 (chat_messages)

八、验证指标（Metrics & KPI）

九、扩展功能（Extensions）

1. 私聊 / 群聊 / 频道分层

   • 支持 private:{uid}、group:{gid}、channel:{topic} 形式的房间；
   • 服务器通过路由前缀识别广播范围。

2. 消息审计

   • 审核模块异步消费 Redis Stream；
   • AI 过滤脏字、敏感图像；
   • 审核结果写入 audit_logs。

3. 文件与图片消息

   • 图片上传到 OSS / MinIO；
   • 消息中仅传链接与缩略图。

4. 服务降级机制

   • 当负载超过阈值时自动切换到只读模式；
   • 拒绝新消息写入但仍允许浏览。

十、技术选型与实现建议（Implementation Notes）

十一、压测与运维（Load Testing & Ops）

11.1 压测场景

11.2 运维指标

• CPU / Mem 使用率
• 活跃房间数
• 断线重连次数
• 日志错误占比

十二、设计反思与演化（Reflection & Evolution）

12.1 设计反思

• 聊天室是验证通信栈的最佳实验场。

• 但真实游戏环境比聊天室复杂百倍：

  • 游戏逻辑需要更严格的顺序与一致性；
  • 状态同步、命令锁步、反作弊比消息更敏感；
  • 因此聊天室只是通信底座，不是最终模型。

12.2 设计演化路径

总结

回声聊天室不是“最简单”的项目，而是“最基础”的系统。
它验证了连接、状态、延迟、容错这四个核心。
当一条消息能在 100ms 内往返全球、被记录、被重放、被分析、被恢复——
你就拥有了一个“有生命的网络内核”。

• Minigame
• Echo Chatroom
• PRD