游戏类型与架构选型对照
游戏类型决定了服务端架构的核心约束。不同类型游戏对实时性、一致性、状态规模、并发模型的要求差异极大，选择错误的架构会导致后期返工甚至推倒重来。
按实时性分类
强实时对战（延迟敏感 < 100ms）
典型游戏类型：
- FPS/TPS（CS:GO、使命召唤手游）
- MOBA（王者荣耀、英雄联盟）
- 格斗游戏（街霸、拳皇）
- 竞速游戏（QQ飞车、跑跑卡丁车）
- 弹幕射击（雷电、飞机大战）
架构特点：
- 客户端预测 + 服务端权威
- 帧同步或状态同步
- 房间制：一局一房间，短生命周期
- 状态服务进程：单进程承载有限房间
- 专用战斗服务器（可能物理机部署）
技术选型：
- 语言：C++/Go/Rust（低延迟要求）
- 网络：UDP（KCP/QUIC）
- 同步模型：帧同步（确定性）或状态同步（权威服务端）
- 数据库：Redis（实时状态）+ MySQL（持久化）
中等实时（延迟容忍 100-500ms）
典型游戏类型：
- 卡牌对战（炉石传说、游戏王）
- 回合制（梦幻西游、阴阳师）
- 自走棋（云顶之弈、多多自走棋）
- 策略对战（文明觉醒、万国醒）
- 弹幕互动（抖音弹幕游戏）
架构特点：
- 服务端权威 + 客户端表现
- 房间制或匹配制
- 状态可以分阶段更新
- 对延迟容忍度较高
技术选型：
- 语言：Go/Java/C++
- 网络：TCP/WebSocket/长连接
- 同步模型：回合制同步或状态广播
- 数据库：MySQL + Redis
弱实时/异步（延迟容忍 > 1s）
典型游戏类型：
- 挂机放置（刀塔能挂机、西游）
- 模拟经营（开心农场、卡通农场）
- 卡牌养成（阴阳师、原神抽卡）
- 策略养成（率土之滨、三国志战略版）
- 社交休闲（动物森友会）
架构特点：
- 请求-响应模式为主
- 状态可以批量更新
- 后台定时任务驱动
- 对并发要求相对较低
技术选型：
- 语言：Go/Python/Java
- 网络：HTTP/WebSocket
- 同步模型：请求-响应 + 推送通知
- 数据库：MySQL + Redis + 定时任务
按玩家规模分类
单服独立（1服1世界）
典型游戏类型：
- 独立手游（单机联网验证）
- 小型休闲游戏
- 测试期产品
架构特点：
- 单进程或少量进程
- 所有状态在一个数据库
- 简单部署和运维
技术选型：
- 语言：Python/Node.js/Go
- 框架：Skynet/自建轻量框架
- 数据库：MySQL/SQLite
分服运营（多服独立）
典型游戏类型：
- 传统MMO（传奇、奇迹）
- 卡牌养成（梦幻西游）
- 策略游戏（率土之滨）
架构特点：
- 每个服务器独立运行
- 玩家选择服务器进入
- 服务器之间数据隔离
- 需要合服、滚服机制
技术选型：
- 语言：C++/Java/Go
- 框架：MMORPG框架（BigWorld/自建）
- 数据库：MySQL（分服分库）
- 缓存：Redis（每服独立）
全服/跨服（1服多世界）
典型游戏类型：
- 现代MMO（原神、幻塔）
- 大逃杀（和平精英）
- 开放世界（我的世界服务器）
- 区块链游戏
架构特点：
- 全服统一入口
- 动态分区/分服
- 跨服匹配、跨服战斗
- 状态需要全局可见
技术选型：
- 语言：Go/C++/Java
- 架构：微服务 + 服务网格
- 数据库：分布式数据库（TiDB/CockroachDB）
- 缓存：Redis Cluster
- 消息：Kafka/NATS
按状态模型分类
房间制（短生命周期状态）
典型游戏类型：
- MOBA/RTS（一局20-40分钟）
- FPS（一局10-30分钟）
- 自走棋（一局30-45分钟）
- 棋牌（一局5-30分钟）
架构特点：
- 房间创建 → 游戏进行 → 结算 → 销毁
- 状态在房间生命周期内有效
- 房间可以动态分配到不同进程
- 容易做水平扩展
设计要点：
- 房间管理器：创建、查找、销毁
- 房间状态机：等待、游戏中、结算
- 房间分配：负载均衡策略
- 房间迁移：进程重启时的状态恢复
世界制（长生命周期状态）
典型游戏类型：
- MMO（天龙八部、剑网3）
- 沙盒（我的世界）
- 模拟人生（动物森友会）
- 大逃杀（和平精英）
架构特点：
- 玩家状态持续存在
- 地图/场景持久化
- 实体状态需要跨进程同步
- 需要 AOI（兴趣区域）管理
设计要点：
- 地图分区：网格/BSP/动态分区
- 实体管理：玩家、NPC、怪物、掉落物
- AOI 管理：九宫格、十字链表、广播树
- 状态同步：增量同步、快照同步
数据制（状态以数据为主）
典型游戏类型：
- 卡牌养成（阴阳师、原神）
- 策略养成（率土之滨）
- 模拟经营（开心农场）
- 挂机放置（刀塔能挂机）
架构特点：
- 状态主要在数据库
- 读多写少
- 定时任务批量处理
- 状态一致性要求高
设计要点：
- 数据分层：热数据/温数据/冷数据
- 缓存策略：LRU、定时回写
- 事务处理：关键操作需要事务保证
- 数据归档：历史数据清理策略
按社交模型分类
弱社交（单人为主）
典型游戏类型：
- 单机手游
- 挂机放置
- 解谜游戏
- 模拟经营
架构特点：
- 玩家交互少
- 好友系统简单
- 排行榜是主要社交
- 无需跨服交互
中社交（公会/好友）
典型游戏类型：
- 卡牌养成
- 策略游戏
- MMO
- 回合制
架构特点：
- 公会系统
- 好友互动
- 跨服公会战
- 需要社交状态同步
强社交（实时交互）
典型游戏类型：
- MMO
- MOBA
- FPS
- 大逃杀
架构特点：
- 实时组队
- 实时聊天
- 跨服匹配
- 大规模社交状态
架构选型决策树
text
游戏类型确定后，按以下顺序决策：
1. 实时性要求
├── 强实时（< 100ms）→ UDP + 帧同步/状态同步
├── 中等实时（100-500ms）→ TCP/WebSocket + 房间制
└── 弱实时（> 1s）→ HTTP + 请求-响应
2. 玩家规模
├── 单服独立 → 简单架构
├── 分服运营 → MMORPG框架 + 分服分库
└── 全服/跨服 → 微服务 + 分布式
3. 状态模型
├── 房间制 → 房间管理器 + 动态分配
├── 世界制 → AOI + 地图分区 + 实体管理
└── 数据制 → 数据分层 + 缓存策略
4. 社交模型
├── 弱社交 → 简单好友 + 排行榜
├── 中社交 → 公会系统 + 跨服交互
└── 强社交 → 实时社交 + 大规模同步常见误区
- 误区一：所有游戏都用 MMO 架构 → 过度设计，维护成本高
- 误区二：强实时游戏用 HTTP → 延迟无法保证
- 误区三：挂机游戏用帧同步 → 资源浪费，复杂度高
- 误区四：分服游戏不做合服 → 运营后期服务器空置
- 误区五：全服游戏不做分区 → 性能瓶颈
下一步
选择具体架构前，先回答三个问题：
- 玩家最频繁的核心行为是什么？
- 哪些状态一旦错就会直接伤害体验？
- 哪些故障恢复不了，或者恢复成本远高于预防？