游戏服务器架构

案例1：寝室斗地主

• 登录
• 对局 游戏逻辑：发牌、规则判定、结算
• 数据记录
• 单机运行
• 简易维护

案例2：社区斗地主

• 业务实现：房间列表、自动匹配、大量级存储、服务安全、公告系统
• 运行维护：多机、带宽、下载、更新

什么是服务器架构

• 对服务器软件和硬件以及运行的一体化规划
• 架构结构：分层分块
• 架构技术选择：编程语言、通信方式、存储技术
• 运行质量：运行环境、部署工具方法、更新方案

案例：MMORPG 轩辕** 服务器架构 分区多世界

MMORPG：大型 多人 在线 角色扮演

分区多世界：运营视角

• 世界与世界是隔离的
• 世界之间的互通方式：跨服、转服、合服

分区多世界：运维视角

• SET部署：每开一组服就增加一组机器、部署一套进程

  
  
  

  分区多世界：运维视角

双通服：世界上最遥远的距离，是从电信到网通的距离。

分区多世界：客户端视角

• TCLS组件：显示所有服务器列表

分区多世界：服务器视角

• 一组服：一套进程

轩辕服务器为什么要这么多进程和机器 - 多维度切分

初始设计

一个进程包揽所有游戏服务器功能

问题：开第2个服应该怎么做呢？

按世界分离

• 分区多世界原型v1
  一个大区包含多台物理机、一台物理机仅运营一个游戏世界、一个游戏世界对应一个游戏进程
• 问题：跨世界共享的功能会变得重复
  游戏账号登录、客户端版本升级、游戏大区列表、游戏账号信息

公共服分离

• 跨世界共享功能的分离部署
• 问题：公共服的单点故障
  针对单点故障，最常用的方式是主备从模式

公共服热备

• 主备从模式
• 问题：一台物理机一个进程？

按功能分离

• 按“接入-逻辑-存储”分离
  分离业务逻辑（不稳定的）与基础功能（稳定的）

• 问题：逻辑处理和持久化数据在一个物理机上
  DB的文件IO会拖慢整体系统（百万级玩家，几百个G的数据）、进程运行中每天输出大量日志（几个G数据）、物理机故障时DB可能会丢失

  
  
  

  接入-逻辑-存储

按重要性分离

百万注册 = 10W活跃 = 1W在线，缓存应重点放在活跃身上。

设计演进：分区多世界原型v2

• cluster云级服务：整个游戏一组
• world级服务：每个游戏世界一组
• 各组服包含“接入-逻辑-存储（DB/DR/LOG分离）”

继续分离公共服

分离逻辑部分弱相关的功能，公共服分离服务器列表、版本升级、账号信息等功能。

切分逻辑进程

当前的现状是所有鸡蛋都放在一个篮子里，所有玩家都在一个进程上，好处是一个特性可以方便地操作到所有玩家上，风险是一个特性的bug可能会影响到所有玩家。

所有特性都在一个进程所带来的风险是：特性的不断的引入会使该进程稳定性和服务质量降低。

设计演进：分区多世界原型v3

如何做切分，参考原则如下：

• 为可扩展性：一组服一套进程
• 为可运维性：一组服一套机器
• 为可靠性：弱相关的功能可分离
• 提高更新便利性：将频繁更新的部分分离
• 按服务重要性切分：如支付系统独立
• 按服务特点切分：接入、存储、逻辑分离
• 切分稳定的基础功能和不稳定的业务逻辑

服务器为长线运营的准备

基本原则：可用、可控、可扩展性

接入与负载

• 多tconnd：分离下行广播包的压力
• 多scene：可扩展性，提高单服承载人数

可用性

• resume机制
• minidump
  避免因为coredump导致resume时间过长，支持输出出错时基本上下文（调用栈、寄存器）

在线控制

• reload机制：资源、配置文件热加载

• GM系统

  
  
  

  GM系统

过载保护

• 请求频率控制：按功能模块控制如移动、技能...

• DB频率控制：按业务模块配额，区分优先级（存盘优先）

• 边界情况检测：某类内存分配占用量超过阈值，某类请求/timer执行时间过长

  DB设计

• 表格设计：按QQ号分表，简单列+统一blob格式（meta）

• 数据升级：旁路进程，自动分批升级

服务器中服务介绍

版本升级tcus

• 支持升级策略：强制、推荐、后台、预下载、自定义
• 支持灰度更新

目录服务tdir

显示服务器列表，繁忙程度（参照在线人数）。

游戏过程world/scene

运营支持 GM平台/idip