《游戏服务端编程实践》1.3.0 游戏服务器的核心模块与职责

一、概述：游戏世界的“服务解剖图”

在前几章中我们从「架构形态」的角度认识了 MMO、SLG、MOBA、FPS 的差异与统一。
而当我们进入具体工程实践时，这些宏观架构都可以被拆解为以下几个通用核心模块：

graph TD
Login[登录/认证服] --> Gateway[网关服]
Gateway --> Match[匹配服]
Match --> Room[房间服]
Room --> Battle[战斗服]
Battle --> World[世界服]
World --> Data[数据存储服]
World --> Chat[聊天服]
World --> Quest[任务/活动服]
World --> Mail[邮件服]
World --> GM[管理/运维服]

无论什么类型的网络游戏，这 10 大核心模块几乎都会存在，只是职责侧重不同、调用顺序有异。

二、模块分层与职责概览

2.1 三层逻辑分层

graph TD
A["接入层 Gateway/Login"]
B["逻辑层 Match/Battle/World"]
C["数据与支撑层 Data/Cache/Chat/Quest/Mail/GM"]
A --> B
B --> C

2.2 服务职责矩阵

三、登录与认证模块（Login Service）

3.1 职责说明

• 用户注册 / 登录
• 第三方平台认证（微信 / Apple / Google）
• Token 签发与刷新
• 区服选择与灰度控制
• 在线状态写入 Redis

3.2 登录流程图

sequenceDiagram
Client->>Login: POST /login {username, password}
Login->>AuthDB: 校验凭证
AuthDB-->>Login: OK + UID
Login->>JWT: 生成Token
Login-->>Client: Token + ServerInfo

3.3 Go 代码示例

type LoginRequest struct {
    Username string `json:"username"`
    Password string `json:"password"`
}

func LoginHandler(c *gin.Context) {
    var req LoginRequest
    c.BindJSON(&req)
    user := db.FindUser(req.Username)
    if CheckPassword(user.Password, req.Password) {
        token := jwt.Generate(user.ID)
        c.JSON(200, gin.H{"token": token})
    } else {
        c.JSON(401, gin.H{"error": "unauthorized"})
    }
}

3.4 关键设计点

四、网关模块（Gateway Service）

4.1 职责说明

• 统一接入（TCP/WebSocket）
• 维护连接、心跳与掉线
• 解析消息头并路由到对应逻辑服
• 转发响应给客户端

4.2 网关结构图

graph TD
Client --> Gateway
Gateway --> Auth
Gateway --> Match
Gateway --> Battle
Gateway --> Chat

4.3 Go 实现片段

type Session struct {
    ID     int64
    Conn   net.Conn
    SendCh chan []byte
}

func (s *Session) Start() {
    go func() {
        for msg := range s.SendCh {
            s.Conn.Write(msg)
        }
    }()
}

4.4 消息分发机制

type Message struct {
    Cmd  uint16
    Data []byte
}

type Router struct {
    handlers map[uint16]func(*Session, []byte)
}

• 根据 Cmd 查找目标模块；
• 通过 gRPC 或 MQ 转发。

4.5 心跳与掉线恢复

• 客户端每 10 秒发送一次心跳；
• 若超过 30 秒未响应，踢出；
• Redis 保存 SessionID；
• 重连后可恢复 Token。

五、匹配模块（Matchmaking Service）

5.1 职责说明

• 匹配队列（按段位 / 区域 / 模式）
• 规则匹配（ELO、MMR、Glicko2）
• 队列超时回退
• 匹配结果推送房间服

5.2 匹配流程图

sequenceDiagram
Client->>Gateway: RequestMatch
Gateway->>Match: Enqueue
Match->>Redis: StoreQueue
Match-->>Battle: CreateRoom
Battle-->>Client: JoinRoom

5.3 Go 示例

func MatchPlayer(player PlayerInfo) {
    score := player.MMR
    matchKey := fmt.Sprintf("queue:%d", score/100)
    redis.ZAdd(matchKey, redis.Z{Score: float64(time.Now().Unix()), Member: player.ID})
}

5.4 匹配策略

六、房间模块（Room Service）

6.1 职责

• 创建 / 销毁房间
• 分配战斗实例节点
• 玩家准备与开始同步
• 房间广播

6.2 房间结构体

type Room struct {
    ID       int64
    Players  []int64
    State    string
    StartAt  time.Time
}

6.3 生命周期

七、战斗模块（Battle Service）

7.1 职责

• 帧同步 / 状态同步逻辑循环
• 战斗结果计算
• 快照与回放
• 掉线重连
• 数据上报

7.2 战斗循环（Tick Loop）

func (r *Room) StartBattle() {
    ticker := time.NewTicker(time.Millisecond * 50)
    for range ticker.C {
        r.UpdateLogic()
        r.BroadcastState()
    }
}

7.3 关键机制

八、世界模块（World Service）

8.1 职责

• 地图管理 / 世界事件
• 公会 / 领地系统
• 服务器全局广播
• 跨服交互

8.2 地图数据结构

type Tile struct {
    X, Y     int
    OwnerID  int64
    Type     string
    Resource int
}

8.3 世界广播机制

使用 Redis Pub/Sub 或 Kafka Topic：

• topic:world:events
• 发布系统事件（占领、击杀、Boss）。

九、数据模块（Data Service）

9.1 职责

• 玩家数据持久化
• 异步批量写入
• 分库分表
• 数据快照与回档

9.2 Go 示例

func SavePlayer(p Player) {
    data, _ := json.Marshal(p)
    kafka.Publish("player.save", data)
}

Worker 消费写入 MySQL。

9.3 数据模型设计

十、聊天模块（Chat Service）

10.1 职责

• 公共频道 / 私聊 / 联盟聊天
• 频道订阅
• 敏感词过滤

10.2 Pub/Sub 模型

redis.Publish("chat:world", msg)
redis.Subscribe("chat:world", handler)

10.3 聊天消息结构

type ChatMsg struct {
    From    int64
    Channel string
    Content string
    Time    time.Time
}

十一、任务与活动模块（Quest & Event Service）

11.1 职责

• 日常任务、主线任务
• 定时活动（限时 Boss）
• 奖励发放
• 条件触发（Event-Driven）

11.2 事件触发器机制

eventBus.Subscribe("BATTLE_WIN", func(evt Event) {
    questSystem.UpdateProgress(evt.PlayerID, "WIN_10_TIMES")
})

十二、邮件模块（Mail Service）

12.1 职责

• 系统奖励邮件
• 离线补偿
• 联盟奖励
• 附件领取

12.2 邮件表结构

十三、GM 与监控模块（GM & Ops Service）

13.1 职责

• 在线人数监控
• 玩家封禁 / 踢下线
• 游戏参数热更新
• 运维工具（指令执行）

13.2 热更新机制

config := LoadYaml("game.yaml")
watcher.OnChange("game.yaml", func() {
    config = ReloadYaml("game.yaml")
})

13.3 可观测性设计

十四、模块间通信机制

十五、安全与容灾设计

• 认证与加密：JWT + AES
• 网络防护：限流 / 黑名单 / 防重放
• 数据容灾：主从复制 + Binlog
• 服务容灾：K8s 自动恢复
• 战斗恢复：快照 + 重放

十六、模块协同示例：一次战斗的完整链路

sequenceDiagram
Client->>Login: 登录认证
Login-->>Client: Token
Client->>Gateway: 建立连接
Gateway->>Match: 匹配请求
Match-->>Room: 分配房间
Room-->>Battle: 启动战斗
Battle-->>Data: 上报结果
Battle-->>Quest: 触发任务
Battle-->>Mail: 发放奖励

十七、未来演进方向

十八、总结：模块化是“世界的工程秩序”

游戏服务端的本质不是“写逻辑”，
而是构建一个能稳定承载“虚拟世界规则”的分布式操作系统。

每个模块是世界的一个“器官”：

整个系统协调工作，才能让一个虚拟世界像生命一样持续存在。