《游戏服务端架构·品类、状态与拓扑》附录 C 游戏服务端架构评审清单

这份清单怎么用

评审清单的价值不在于“打勾”，而在于提前暴露没有证据的判断。如果一份架构方案在评审会上第一次被问到某个问题，说明准备阶段已经漏了东西。

这份清单按评审的自然顺序排列：先看输入，再看决策，最后看闭环。每一项给出合格判据、常见不合格表现和建议证据。评审主持人可以按顺序推进，也可以只挑与本次决策相关的部分。

使用规则只有三条：

1. 每项必须能指向具体材料，不能只回答“有考虑”；
2. 不要求全部满分，但每个“不合格”必须变成风险台账里的条目；
3. 评审结论必须包含退出条件，否则不算通过。

一、输入：产品事实与约束

1.1 产品事实是否可测量

1.2 团队与运维约束是否摆上桌

• 后端人数、值班能力、是否有多地域运维经验；
• 现有中间件与云资源，哪些可以复用、哪些明确不引入；
• 上线时间与人力预算，哪些能力必须首期具备、哪些可以后补。

不合格信号：方案假设团队有 7×24 值班、成熟服务网格或多地多活能力，但组织现状并不支持。

1.3 合规与数据驻留是否确认

• 账号、支付、日志、行为数据是否允许跨境；
• 是否需要本地化存储、单独删除流程或留存期限；
• 未成年人保护、实名与防沉迷是否有额外落点。

二、质量属性与取舍

2.1 质量属性是否写成场景

每个质量属性至少写成“刺激—环境—响应—度量”四段。例如：

当单房间 tick 延迟升高（刺激），在晚高峰 20 万在线（环境）时，系统应在 500ms 内将该房间迁出或降级（响应），且影响玩家不超过 10 人（度量）。

2.2 冲突是否被显式记录

低延迟与强一致、成本与冗余、上线速度与边界清晰，通常会冲突。合格的做法不是“全都要”，而是：

• 列出冲突的两项；
• 说明当前优先级与理由；
• 写明在什么条件下优先级会反转。

三、拓扑与状态归属

3.1 拓扑选择是否有判据

3.2 状态是否有唯一权威

逐类状态回答四个问题：

1. 权威副本在哪里？
2. 谁有权写入？
3. 丢失窗口多大，能否接受？
4. 迁移或重启时，如何拒绝旧写入？

3.3 一致性边界是否明确

• 哪些操作必须同库事务；
• 哪些允许异步，补偿窗口多长；
• 跨分片/跨服操作如何保证不重复扣发；
• 对账与人工兜底的触发条件。

四、连接、会话与权威

4.1 连接模型是否匹配品类

4.2 权威模型是否分级

• 客户端能预测什么、不能写什么；
• 服务端裁决哪些状态（生命、伤害、命中、结果、资产）；
• 高延迟/弱网时的降级策略；
• 回放与观战是否依赖同一套权威日志。

不合格信号：所有品类都用同一句“服务器权威”，没有说明客户端预测范围和回滚策略。

五、部署单元与故障域

5.1 部署单元是否按变化与故障切

5.2 故障域与爆炸半径是否量化

• 故障域层级：进程、节点、机架、可用区、地域；
• 单点清单：哪些组件失效会影响全部玩家；
• 爆炸半径：单房间、单分片、单服务、单地域分别影响多少人；
• 隔离手段：舱壁、配额、独立连接池、去相关部署；
• 降级顺序：先保什么、后保什么、什么可以牺牲。

不合格信号：只画了“高可用”架构图，没有回答“一个房间进程崩了会影响谁”。

5.3 容量与余量是否有基线

• 单实例在目标 P99 下的容量；
• 失去一个故障域后的剩余余量；
• 扩容速度与暖池规模；
• 压测口径：流量模型、数据分布、持续时间。

卷一不要求给出最终容量数字，但要求明确“怎么测、测什么、什么算通过”。

六、演进与退出条件

6.1 决策是否有退出条件

每项关键决策至少回答：

• 什么条件下这个决定开始失效？
• 失效时先改什么、后改什么？
• 谁负责触发复审？

6.2 风险是否进入台账

风险台账至少包含六个字段：编号、描述、概率、影响、可探测性、缓解动作与负责人。评分不是目的，排序和跟踪才是。

不合格信号：风险只写在评审 PPT 的“风险”页，没有负责人、没有复审日期、没有关联决策。

6.3 未决项是否被明确交接

评审结束时，每个未决项应归入三类之一：

• 卷一内必须解决：阻塞基线，不能带条件通过；
• 带条件进入下一阶段：明确条件、验证方式和截止时间；
• 明确不做：写清理由和重新评估的触发条件。

七、评审会本身

7.1 会前

• 材料提前至少 48 小时发出；
• 方案包含产品事实、备选方案、代价、风险与退出条件；
• 评审人提前标注最关心的三个问题。

7.2 会中

建议按固定顺序推进，避免被细节带偏：

1. 产品事实与约束（10 分钟）；
2. 质量属性与冲突（10 分钟）；
3. 拓扑与状态归属（20 分钟）；
4. 连接、权威、部署与故障域（20 分钟）；
5. 风险、退出条件与未决项（20 分钟）。

每条结论记录为：接受 / 带条件接受 / 不接受。不接受必须给出可执行的修改方向，不能只写“再想想”。

7.3 会后

• 24 小时内发出结论与行动项；
• 行动项必须有负责人和截止时间；
• 风险台账更新并纳入下次复审；
• 决策写入 ADR，包含备选方案与被否决理由。

八、快速判定：什么时候应该暂停评审

出现以下任一情况，建议暂停并补充材料，而不是在会上硬判：

• 关键产品事实缺失或互相矛盾；
• 状态存在两个写入者，且没有 fencing 机制；
• 有状态服务没有重启/迁移方案；
• 故障域无法回答“影响多少玩家”；
• 关键决策没有退出条件；
• 方案依赖团队并不具备的运维能力；
• 成本没有口径，或明显超过产品生命周期收入。

暂停不是否定方案，而是避免在证据不足时做出不可逆的决定。

九、常见反模式

十、一页纸结论模板

评审结束前，用下面这段模板收口：

结论：接受 / 带条件接受 / 不接受
基线：拓扑 = ____；状态权威 = ____；连接 = ____；权威模型 = ____
关键取舍：____（放弃了什么，换取了什么）
已知风险：R-__（负责人，复审日期）
退出条件：当 ____ 时，重新评估 ____
未决项：____（类型：卷一内解决 / 带条件进入下一阶段 / 明确不做）
下一步：____（负责人，截止时间）

模板很短，但它强迫评审回答三个最难的问题：我们选了什么、放弃了什么、什么时候会改。

清单到这里结束。真正的评审质量，不取决于打勾的数量，而取决于每个“接受”背后是否有证据、每个“风险”背后是否有负责人、每个“决定”背后是否有退出条件。