Q6: 单服架构 vs 分布式架构，如何选择？
核心结论
这不是一个“谁更先进”的问题，而是一个“当前阶段最合适什么复杂度”的问题。
- 单服架构适合早期验证、玩法较轻、团队较小、运维能力有限的项目
- 分布式架构适合大世界、高并发、长周期运营、需要弹性扩容和故障隔离的项目
- 真正成熟的方案通常不是一开始就全面分布式，而是按瓶颈逐步演进
一、先把概念说清楚
实际讨论里，“单服”和“分布式”经常被混用。更准确的划分应该是三层：
1. 单进程单机
所有网络、业务、状态、定时器、数据库访问都在一个进程里。
特点：
- 开发和调试最简单
- 内存共享，函数调用成本低
- 没有跨进程序列化和网络转发
- 容量、隔离性、容错性都受限于单进程
2. 单机多进程
仍然部署在一台机器上，但开始按职责拆进程，例如网关进程、逻辑进程、数据库代理进程。
特点：
- 复杂度明显低于多机分布式
- 可以先建立进程边界和协议边界
- 方便后续平滑迁移到多机部署
- 仍然受限于单机 CPU、内存、网络和故障域
3. 多机分布式
不同职责或不同分片部署到多台机器上，通过 RPC、消息总线或专用协议通信。
特点：
- 可以横向扩容
- 可以做资源隔离和故障隔离
- 部署、调试、监控、一致性问题都更复杂
- 对团队工程能力和运维能力要求更高
因此，很多项目的真实路径不是“单服 or 分布式”二选一，而是：
单进程单机 -> 单机多进程 -> 多机分布式
二、两类架构的本质差异
| 维度 | 单服架构 | 分布式架构 |
|---|---|---|
| 计算边界 | 一个进程或一台机器内 | 多进程、多机 |
| 通信方式 | 函数调用 / 共享内存 | RPC / 消息 / 网络协议 |
| 状态管理 | 本地状态集中管理 | 状态需要分片、复制或迁移 |
| 故障影响面 | 进程或整机级别 | 组件级别，可隔离 |
| 扩容方式 | 升级单机配置为主 | 横向扩容为主 |
| 调试难度 | 低 | 高 |
| 运维成本 | 低 | 高 |
| 数据一致性 | 相对简单 | 明显更难 |
| 延迟开销 | 低 | 更高，需要控制链路长度 |
本质上，单服用“简单性”换开发效率，分布式用“复杂性”换容量、弹性和隔离性。
三、不要只看在线人数
在线人数很重要，但不是唯一指标。架构选择至少要看五个维度。
3.1 玩法是否天然要求空间拆分
如果游戏是以下类型，分布式价值很高：
- 大世界 MMORPG
- 大地图生存
- 多区域并行模拟
- 高密度实时交互场景
因为核心瓶颈不是登录连接数，而是：
- 空间模拟负载
- AOI 广播负载
- 战斗结算负载
- 实体迁移和跨区路由
如果是以下类型，单服往往更合适：
- 卡牌
- 回合制
- 房间制小游戏
- 低实时性社交玩法
这类项目的核心压力往往在数据库、网关连接、活动峰值，而不是连续空间模拟。
3.2 热点是否可被切开
分布式并不自动解决热点。
如果一个场景里 2000 人必须共享同一个战场状态、同一套技能事件流、同一套 AOI 结果，那么再多机器也未必能把这个热点轻松拆掉。因为热点本身可能是强耦合的。
这类问题需要先回答：
- 能否按地图分区
- 能否按房间拆分
- 能否按频道拆分
- 能否按逻辑域拆分
- 能否接受局部降级
如果热点天然不可分，分布式只能缓解外围压力，不能消灭核心热点。
3.3 团队是否驾驭得住复杂度
分布式会引入一整套新增问题：
- 服务发现
- 路由与寻址
- 超时、重试、幂等
- 状态迁移
- 节点摘除和恢复
- 灰度发布
- 全链路监控
- 分布式一致性
如果团队当前连单机性能分析、线上诊断、压测建模都不稳定，过早分布式通常只是把问题扩散到更多节点。
3.4 是否需要长期运营能力
只做版本验证、成本敏感、生命周期短的项目，单服通常更划算。
但如果目标是：
- 长周期商业化运营
- 活动期波峰明显
- 需要跨服活动
- 需要不停服迁移或弹性扩容
- 强依赖容灾和快速恢复
那分布式的投入通常是值得的。
3.5 是否已经出现了明确瓶颈
正确的迁移方式不是“预判未来会火，所以先上全套分布式”，而是基于实际瓶颈推进。
常见信号包括：
- 单进程 CPU 已长期接近上限
- 特定地图或战斗线程成为稳定热点
- 登录、聊天、排行榜等外围系统拖累主逻辑
- 发布、重启、故障恢复成本过高
- 单机升级已经不能有效解决问题
四、MMO 场景下如何判断
4.1 什么情况下单服就够
以下情况通常可以先做单服或单机多进程：
- 项目还在验证玩法
- 世界规模不大
- 单场景人数上限不高
- 交互强度不高
- 先把战斗、任务、成长链路跑通更重要
典型目标是：
- 尽快上线
- 尽快压测
- 尽快看真实玩家行为
这时最有价值的不是“架构看起来很大”，而是“系统可快速迭代、问题可快速定位”。
4.2 什么情况下必须认真考虑分布式
以下情况通常说明已经接近分布式门槛：
- 存在持续运行的大地图或连续空间
- 单地图要承载大量实时实体
- AOI、广播、战斗结算成为主要瓶颈
- 不同地图、频道、战场需要独立扩容
- 玩家跨区迁移是常态能力而不是偶发需求
- 线上容灾、热迁移、弹性扩容是刚需
这类项目里，空间逻辑和账户逻辑分层通常很重要。像 KBEngine 的 BaseApp / CellApp 划分，本质上就是把“玩家持久状态”和“空间实时状态”拆开，以便分别扩展和迁移。
五、分布式并不等于“无限扩展”
很多文档喜欢写“理论上只要不断加机器就能无限扩展”，这只能作为方向性的表述，不能当成工程结论。
实际限制通常来自：
- 单场景热点无法拆分
- 跨节点同步开销上升
- 广播扇出增长过快
- 数据一致性和回滚成本变高
- 调度器和管理节点出现瓶颈
- 数据库、缓存、消息队列成为新的中心瓶颈
更准确的说法应该是：
分布式可以显著提高系统上限，但能否扩得动，取决于负载是否可拆、状态是否可迁、链路是否足够短、热点是否可控。
六、一个更实用的选择方法
6.1 先做架构分层，再决定是否分布式
即使当前只部署单机，也建议先把边界拆清楚：
- 接入层：连接、鉴权、限流
- 会话层：玩家在线态、会话路由
- 空间层：地图、AOI、战斗、移动
- 数据层：持久化、缓存、索引
- 后台层：邮件、排行榜、GM、活动
这样做的好处是：
- 单机阶段仍然简单
- 模块依赖更清晰
- 后续可以按边界拆进程，而不是重写一遍
6.2 推荐的演进路线
阶段 1：单进程单机
适合：
- 原型验证
- 小团队第一版
- 核心玩法未稳定
目标：
- 尽快形成可玩版本
- 建立压测和监控基础
阶段 2：单机多进程
先拆出高价值边界：
- 网关
- 场景逻辑
- 数据访问
- 后台异步任务
这个阶段最关键，因为它决定后面是否能平滑进入真正分布式。
阶段 3：多机分布式
在以下前提成立后再推进：
- 负载热点已明确
- 协议边界已稳定
- 监控、日志、追踪已具备
- 运维流程已成型
这时再把网关、会话、空间、后台系统按机器拆开，投入产出比更高。
七、一个务实的对比表
| 场景 | 更适合的选择 | 原因 |
|---|---|---|
| 小团队首个 MMO 原型 | 单服或单机多进程 | 优先验证玩法和流程 |
| 房间制游戏 | 单服 | 状态天然按房间隔离，单机足够 |
| 中小规模回合制 | 单服 | 实时性和空间连续性要求不高 |
| 大世界 MMORPG | 分布式 | 空间模拟、AOI、迁移都需要拆分 |
| 大量跨服活动 | 分布式 | 需要独立扩缩容和隔离 |
| 运营期成熟项目 | 分布式 | 发布、容灾、弹性要求更高 |
需要特别注意：
MMORPG = 分布式不是绝对结论，小规模 MMO 也可以先单服起步FPS/MOBA = 分布式也不是绝对结论，很多房间制对局服务本质上是大量独立单房间实例- 真正该看的不是题材名，而是状态耦合度、实时性、容量目标和运营要求
八、实践建议
8.1 小团队的优先级
如果团队规模有限，建议优先保证四件事：
- 架构边界清楚
- 压测模型真实
- 监控和日志可用
- 热点能被定位
这些能力比“先上分布式”更重要。
8.2 什么时候不要急着分布式
以下情况通常不适合马上上分布式：
- 核心玩法还没定
- 连单机瓶颈都没测出来
- 没有线上监控和追踪
- 没有稳定的自动化部署
- 团队对故障定位经验不足
因为这时复杂度增加的速度，往往会快于收益增长的速度。
8.3 什么时候值得投入分布式
以下情况通常说明投入分布式已经划算：
- 单机性能上限被持续命中
- 热点可以被相对干净地拆分
- 业务进入长期运营阶段
- 架构团队和运维流程已经具备
- 单点故障和扩容效率开始影响业务目标
九、总结
一个更稳妥的判断方式是：
- 先用单机把玩法和工程基础打稳
- 再用多进程建立模块边界
- 最后针对真实瓶颈做分布式拆分
因此，单服和分布式不是对立关系，而是同一个项目在不同阶段的不同形态。
如果项目核心是“快速验证”，优先单服。 如果项目核心是“持续运营的大世界高并发模拟”，优先分布式。 如果现在还不确定，通常说明最合理的选择是先做可演进的单机架构，而不是一步到位把系统做重。