游戏与互联网后台的本质差异

强状态 vs 无状态、Tick 驱动 vs 请求驱动——为什么两套技术栈难以直接复用。

场景问题

从互联网后台转到游戏后台（或反过来），最容易犯的错是把另一套的银弹直接搬过来：

• 用互联网的思路做游戏——"加机器不就行了？"，结果发现一个战斗区是单进程有状态，加不了机器；
• 用游戏的思路做互联网——为无状态的下单接口设计一套复杂的 checkpoint 恢复，纯属过度设计。

这两套后台服务的用户体感相似（都是"客户端连服务器"），但底层的状态模型、并发模型、计算特征、容错方式是两条不同的物种演化路线。看不清这层差异，架构选型就会南辕北辙。

实现方案

多维对比表

状态模型：世界状态 vs 无状态

游戏进程内跑着一个世界——所有玩家、NPC、投射物的位置和状态都活在内存里，每帧演进：

// 游戏：世界状态活在进程内存里，Tick 驱动演进
type World struct {
    players map[uint64]*Player  // 全区玩家状态，纯内存
    npcs    map[uint64]*NPC
    frame   int64               // 当前逻辑帧
}

// 每个 Tick（如 66ms）推进整个世界一步，单线程串行，无需加锁
func (w *World) Tick(dt time.Duration) {
    w.frame++
    w.handleInputs()   // 消费本帧输入
    w.stepPhysics(dt)  // 碰撞、移动
    w.resolveCombat()  // 技能/伤害结算
    w.syncAOI()        // 按视野推送状态给客户端
}

互联网服务则相反——进程不留状态，每个请求自带上下文，状态外置：

// 互联网：无状态处理，状态在 DB/缓存，进程可随意水平扩
func CreateOrderHandler(w http.ResponseWriter, r *http.Request) {
    req := parse(r)
    order := buildOrder(req)
    db.Save(order)      // 状态落 DB，进程本身不留任何东西
    w.Write(ok(order))  // 处理完即忘，下一个请求可落到任意副本
}

打个比方：游戏后台像KTV 包厢——你一进门就得一直坐在里面，灯光、点歌单、麦克风音量都要为你这几个人持续在线维护，中途换个包厢代价极高（要搬歌单、搬饮料、搬所有人）；互联网后台像便利店结账——你走到收银台扫码付钱就走，下一位顾客换哪个收银员都行，收银机本身不记住"你上一次买了什么"，全靠会员卡（外置数据库）查历史。类比失效边界：这只是"连接生命期与状态归属"维度的对比，不代表两边工程栈全不同——冷启动、镜像构建、CDN 分发、监控告警、CI/CD 这些基础设施层两边其实高度相通，甚至可以直接复用同一套 K8s、Prometheus、日志采集，别因为"游戏很特殊"就把成熟组件全推翻重造。

并发模型：单线程 Tick vs 多协程无共享

• 游戏：单区单进程、单线程按 Tick 串行推进。因为世界状态高度耦合（一次技能结算要读写几十个实体），加锁会锁到崩溃，索性不共享、不加锁，用单线程消除竞态。多核靠多开进程/多开区利用。
• 互联网：请求之间天然独立，多协程各处理各的，共享状态推给 DB/缓存去做并发控制。加机器就能线性提吞吐。

容错：checkpoint 恢复 vs 副本自愈

游戏进程崩溃，内存里的世界状态就没了，只能回放最近的 checkpoint（丢失两次存档之间的帧），且一个进程挂 = 一整区玩家受影响；互联网副本挂了，健康检查摘除、拉起新副本，状态在 DB 里毫发无损，用户几乎无感。

发布：preStop 等清场 vs 权重灰度

# 游戏 DS 不能硬杀——要等本局结束/玩家撤离，否则整局数据丢失
lifecycle:
  preStop:
    exec:
      command: ["/bin/drain.sh"]  # 停止接新局 → 等待在局玩家自然结束 → 再退出
terminationGracePeriodSeconds: 1800   # 给足清场时间（可能长达 30 分钟）

互联网副本则可随时替换：滚动更新按权重把流量从旧副本切到新副本，旧副本处理完在途请求即退出，无需"等清场"。

为什么这么做

为什么游戏要强状态 + 单线程 Tick？
游戏的核心是一个所有人共享、每帧演进的世界。世界状态之间高度耦合、读写频繁且有实时性要求（帧预算固定），把状态外置到 DB 会让每帧几十次 DB 往返直接爆延迟；多线程加锁则会因锁竞争把帧率打崩。所以状态留内存、单线程串行推进 Tick，是被实时性和状态耦合度逼出来的最优解。

为什么互联网要无状态 + 水平扩？
互联网服务面对的是海量、独立、无实时耦合的短请求，瓶颈在 I/O 和吞吐而非单请求的帧级实时。把状态外置、进程做成无状态，就能用"加副本"这个最简单的手段线性扩容、故障自愈、随意发布。这是被规模和弹性需求塑造的形态。

为什么别的选择不行

为什么两套技术栈难以直接复用？ 因为它们的第一性约束相反：

• 把互联网的"无状态水平扩"套到游戏战斗区——世界状态没法拆到 DB，也没法把一局的实时演进打散到多副本，加机器加不动单区容量；
• 把游戏的"单进程有状态 + checkpoint"套到互联网下单——无谓地引入单点、放弃了副本自愈和弹性伸缩，纯属自缚手脚；
• 把游戏的"单线程 Tick"套到 I/O 密集服务——CPU 大量空转等 I/O，单线程反而成了吞吐瓶颈；
• 把互联网的"多线程共享 + 加锁"套到游戏世界演进——锁竞争把帧率打崩，实时性完全崩坏。

所以不是谁比谁先进，而是不同的约束逼出不同的最优形态。硬搬只会把对方的优势变成自己的负债。

沉淀结论

• 游戏后台是强状态 · 长连接 · 单线程 Tick · 计算密集 · 按区切分 · checkpoint 恢复；互联网后台是无状态 · 短请求 · 多协程 · I/O 密集 · 水平弹性 · 副本自愈。
• 差异的根源是第一性约束不同：游戏被"共享世界 + 帧级实时"逼成有状态单线程；互联网被"海量独立请求 + 规模弹性"塑成无状态水平扩。
• 架构选型的指导意义：先判断你的服务是"有世界状态的实时循环"还是"无状态的请求处理"，再选状态模型、并发模型、扩缩容与发布策略，不要跨界硬搬银弹。
• 两者并非全无交集——游戏的大厅 / 商城 / 支付 / 活动这类外围业务，本质就是互联网式无状态服务，可以且应该用互联网那套（无状态、水平扩、DB 为准）；真正特殊的是对局/战斗这条实时有状态的核心链路。

记忆口诀

• 游戏后台：强状态 / 长连接 / 单线程 Tick / 计算密集 / 按区切分 / checkpoint 恢复
• 互联网后台：无状态 / 短请求 / 多协程 / I/O 密集 / 水平弹性 / 副本自愈
• 差异根源：第一性约束相反 / 共享世界+帧级实时 逼出有状态单线程 / 海量独立请求+规模弹性 塑成无状态水平扩
• 选型第一问：是「有世界状态的实时循环」还是「无状态的请求处理」/ 先判范式 / 再选状态·并发·扩缩·发布 / 别跨界搬银弹

内容来源

综合整理自游戏后台与互联网后台架构范式的对比实践；混合架构与外围业务水平扩部分呼应本站 intro 与本域《业务代理 · 支付 · 商城》实战笔记中商业化服务的无状态水平扩经验。

自测：合上资料能说清楚吗？

1. 为什么游戏战斗区不能靠"加机器"扩容，而互联网下单服务可以？

2. 游戏为什么用单线程 Tick，而不用多线程加锁？

3. 对比游戏与互联网后台的容错方式，各自单点故障的影响范围有何不同？

4. 为什么游戏 DS 发布不能"硬杀"，互联网副本却可随时替换？

5. 一款现代游戏的"大厅/商城/支付"应该按哪套范式做？为什么？

相关专题：局内（引擎侧）的端存在性与服务器权威模型见 UE Gameplay Framework——本篇讲局外后台与游戏后台的范式差异，UE 域讲一局之内 Actor 状态如何跨端同步。