案例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