第 49 章让系统「知道自己病了」，本章让系统「自己把病治好」。游戏服务端与普通无状态服务最大的区别在于：进程里握着玩家会话和世界状态，重启不是免费的。因此自愈的关键不只是「能不能重启」，而是「重启之后玩家能不能无感地继续玩」。这一章验证的正是这条从探针到状态恢复的完整链路。
本章定位
- 难度层级：第 5 层（概念原型层），是第 5 层的收尾篇。
- 前置章节：第 49 章 AI 运维检测。检测侧输出结构化异常事件，本章消费这些事件并执行修复动作。
- 本章要跨的门槛：把「有状态服务」的故障恢复做成可编排、可观测、可回滚的标准流程，而不是依赖运维手工介入。
核心验证目标
本章 PRD 明确要求验证 Health Probe、Operator 重启，建议拆解为：
- Health Probe 设计：区分存活探针与就绪探针，定义「卡死但进程未退出」这类软故障的判定标准。
- Operator 控制器：用声明式控制器监听自定义资源，把「期望副本数 / 期望版本」收敛为实际状态。
- 实例驱逐与重调度：节点故障或实例不健康时，安全地把实例迁移到新节点，并保证同一房间/分片不会双主。
- 状态快照与恢复：重启前落盘或转移会话状态，重启后由客户端自动重连并续上进度。
- 滚动升级与灰度：版本更新时按批次替换实例，配合探针保证升级期间可用性不下降。
技术栈建议
PRD 基线为 Go / Rust / Python，网络层用 WebSocket over HTTPS 或 gRPC。自愈场景的补充建议：
| 层 | 建议 | 说明 |
|---|---|---|
| 编排底座 | Kubernetes | 探针、驱逐、滚动升级均为平台原生能力 |
| 控制器 | Go + Operator SDK | 声明式收敛循环，与 K8s 生态契合 |
| 状态存储 | Redis / 内存网格 + 快照 | 会话状态外置，实例无状态化或半无状态化 |
| 事件源 | 事件总线 | 接收第 49 章的异常事件，触发修复动作 |
| 观测 | 事件时间线 + 审计日志 | 每次自愈都要可追溯，便于复盘与回滚 |
本章文章
| 文章 | 类型 | 核心内容 |
|---|---|---|
| 在线联机原型全集：第 50 章 自愈游戏服务器（Self-healing Game Server） | 动态修复型 | 用 Health Probe 判定实例健康、用 Operator 执行重启与重调度，并保住玩家状态 |
该 PRD 处于「概念设计阶段」，正文给出系统组成、状态机、事件生命周期与接口定义，适合作为服务端自愈能力的立项蓝图。
与相邻章节的关系
- 上一章：第 49 章 AI 运维检测 —— 「检测」与「修复」是本原型的一体两面，建议连读。
- 下一章：第 51 章 AI 玩家文明 —— 从这里开始进入第 6 层，原型从「服务自身」转向「世界与智能体自治」。
相关专题
- 产品原型开发专题 —— 60 个原型的总入口与路线图。
- Kubernetes 专题 —— 探针、控制器与滚动升级的技术底座。
- 可观测性专题 —— 自愈的前提是可靠的监控与告警。
- 游戏服务端实战 —— 有状态服务端运维的实践经验。