怎么用这份术语表
架构评审里最常见的无效争论，不是观点不同，而是同一个词指向不同的东西。有人说“我们要无状态”，他可能指“进程不保存玩家数据”，也可能指“任何请求都能打到任意实例”；有人说“全球同服”，他可能指“同一个数据库”，也可能指“同一套世界规则”。
这份术语表给出本书采用的口径。它不是行业标准，也不排斥其他用法；它的作用是让本书内部保持一致，并在评审时提供一个可以对齐的起点。每个词后面标注了主要讨论它的章节，需要展开时可以直接跳转。
一、品类与产品事实
品类（genre）
本书指一组相对稳定的产品事实组合：是否实时、是否共享世界、是否房间制、单局时长、同时在线量级、跨区需求、更新频率。品类不是题材标签，“二次元”不是架构意义上的品类，“5v5 房间制竞技”才是。见 1.3 品类如何决定拓扑
。
产品事实（product fact）
可以被测量或明确回答的产品约束，例如“一局 10 分钟”“同时在线 20 万”“玩家会在 WiFi 与 4G 之间切换”。产品事实是拓扑选择的输入，不能被“我们想做微服务”这类技术偏好替代。
拓扑（topology）
服务端进程、状态与流量的组织方式。卷一区分五类：模块化单体、分层单体、大厅 + 房间、分区/分片世界、专用服池。拓扑不等于部署单元数量，也不等于是否使用容器。见 3.1 模块化单体
、3.2 大厅与房间
、3.3 分区与全球同服
。
品类—拓扑决策矩阵
以产品事实为行、拓扑选项为列的对照表，每个格子给出推荐/可选/不推荐与理由。它是决策辅助，不是自动答案。见 13.2 品类与拓扑决策矩阵
与附录 B。
二、拓扑、部署与故障
模块化单体（modular monolith）
一个部署单元，内部按业务边界划分模块，模块之间通过显式接口和允许依赖表通信。它保留单体的部署简单性，同时为未来拆分留下接缝。见 3.1
。
大厅（lobby）
处理登录后、进入对局前的无状态或弱状态服务：匹配、组队、房间列表、开始游戏。大厅可以任意扩容，因为它不持有对局状态。见 3.2
、9.1
。
房间（room）
承载一局对局的有状态单元：玩家集合、世界状态、tick、结算。房间的归属必须明确，同一时刻只能有一个权威写入者。见 3.2
。
分配器（allocator）
负责把房间放到某个进程或节点上的组件。它要处理容量、暖池、租约、回收和重复分配。见 3.2
。
暖池（warm pool）
预先启动、随时可以承接新房间的进程或实例。暖池用资源换启动延迟，代价是空闲成本。见 3.2
。
分片（shard）
把世界或数据切成多个独立负责的范围，每个范围有明确的权威归属。分片可以是按地图格子、按玩家、按赛区或按功能。见 3.3
、8.1
。
全球同服（global server）
产品承诺层面的“同一个世界”，不等于所有数据放在同一个数据库。本书把它拆成“同一套规则、同一份世界事件、跨区可见的社交”三个可验证承诺。见 8.1
。
分区（region） / 分服（server）
按地域或运营单位切开的独立世界。分区解决延迟与合规，分服解决开服节奏与运营隔离。跨服玩法需要在分区之上再建一层路由。见 8.2 分区分服与合服
。
合服（server merge）
把两个或多个分服的玩家、公会、排行榜和资产合并到一个服。核心难点是 ID 重映射、重名消解和历史数据归属。见 8.2
。
部署单元（deployment unit）
可以独立构建、发布、伸缩和回滚的最小单位。切分依据是变更频率、伸缩特性、故障隔离、团队归属和数据边界，不是技术分层。见 11.1 部署单元怎么切
。
故障域（failure domain）
一组会一起失效的资源边界：进程、节点、机架、可用区、地域。故障域越小，爆炸半径越可控，但隔离成本越高。见 11.3 故障域与爆炸半径
。
爆炸半径（blast radius）
一次故障可能影响的最大范围：多少玩家、多少房间、多少功能、多长时间。它是可度量的架构指标，不是形容词。见 11.3
。
有状态服务（stateful service）
在内存或本地磁盘持有跨请求状态的进程。游戏服务端的房间、场景、会话天然有状态；问题不是消灭状态，而是明确状态归属、丢失窗口和迁移协议。见 11.2 有状态服务的边界
。
三、状态与时间
状态所有权（state ownership）
对某份状态拥有唯一写入权的服务或模块。所有权必须显式，不能靠“大家都可以写、最后以某个为准”。见 1.1
。
内存态 / 持久态（in-memory / persistent state）
内存态读取快、丢失风险高；持久态可恢复、写入成本高。本书要求区分“可丢失窗口”和“必须落盘”的状态。见 4.1 内存态、持久态与快照
。
快照（snapshot）
某一时刻世界状态的完整副本。快照不是备份：它用于恢复和迁移，必须带版本号、tick 与校验和。见 4.1
。
tick
服务端逻辑推进的固定时间步。tick 率决定模拟精度与 CPU 成本，不等于网络发送频率。见 4.2 tick、帧预算与世界时钟
。
世界时间（world clock）
所有逻辑判断使用的逻辑时间，通常由 tick 计数或单调时钟推导。它不等于墙钟时间，也不等于客户端时间。见 4.2
。
补帧 / 追帧（catch-up）
进程暂停或负载过高后，一次性推进多个逻辑帧以追上世界时间。补帧必须有上限，否则会引发雪崩。见 4.2
。
漂移（drift）
逻辑时间与真实时间之间的偏差。漂移需要被测量和校正，不能长期累积。见 4.2
。
离线补算（offline accrual）
玩家离线期间，按时间推进的产出、建造或体力恢复。补算不是简单的时间乘法，要处理封顶、时区、维护消耗和幂等。见 4.3 离线推进与补算
、8.3 异步结算
。
四、连接、会话与权威
长连接 / 短连接
长连接保持会话通道，适合推送与实时交互；短连接按请求建立，适合低频操作。选择依据是消息频率、延迟预算、弱网表现和运维能力。见 5.1 连接方式取舍
。
WebSocket / QUIC
WebSocket 在 TCP 之上提供双向消息，兼容性好；QUIC 基于 UDP，支持多路复用与连接迁移，但运维与中间件支持成本更高。本书不宣称某一种“全面更优”。见 5.1
。
网关（gateway）
连接终结、认证、路由、限流和协议转换的接入层。网关不应承担业务规则。见 5.2 网关的职责边界
。
会话（session）
玩家与某个服务实例之间的绑定关系，包含令牌、epoch、连接状态和可恢复上下文。会话不等于账号。见 5.3 会话、重连与迁移
。
顶号（kick / takeover）
同一账号在新设备登录时，旧连接被强制下线。必须用 epoch 或 fencing token 保证旧连接不能再写入。见 5.3
。
连接迁移（connection migration）
把会话从一台网关或房间服转移到另一台，常见于扩容、故障转移和玩家跨区。迁移必须定义“旧连接停止写入”的时点。见 5.3
。
客户端预测（client prediction）
客户端在等待服务器确认前，先按本地输入推进表现，以减少操作延迟。预测只影响表现层，不改变服务端权威状态。见 6.1 客户端预测与服务端裁决
。
服务端裁决（server authority）
最终状态由服务端决定。客户端可以提议输入，但不能直接写关键状态。权威强度按品类分级。见 6.1
。
回滚与重放（rollback / replay）
服务端确认输入后，客户端撤销预测并重放已确认输入；服务端也可能回滚世界状态到某个快照再重新推进。见 6.1
。
反作弊分层（anti-cheat layering）
把检测分布在客户端完整性、网关协议、战斗规则、经济审计和离线复核多层，而不是寄希望于单点方案。见 6.2 反作弊放在哪一层
。
服务端权威随机（server-authoritative randomness）
随机数由服务端生成并可审计。常见做法是种子提交—揭示（commit-reveal）加日志留存。见 6.3 经济与随机数的可信边界
。
账本（ledger）
记录资产变动的双分录流水。账本的价值在于可审计、可对账，而不只是“记一笔”。见 6.3
。
五、竞技、SLG 与休闲
帧同步（lockstep）
所有客户端按相同输入序列推进相同逻辑，服务端主要负责收集与广播输入。它要求强确定性，重连和观战成本高。见 7.1 MOBA 的房间、tick 与帧同步
。
状态同步（state sync）
服务端计算权威状态，按需同步给客户端。带宽和服务器成本更高，但确定性与反作弊压力更小。见 7.1
。
确定性（determinism）
相同输入在相同版本下产生相同结果。它是帧同步、回放和回合制结算的基础，需要固定随机数、遍历顺序和数值精度。见 7.1
、9.2
。
延迟补偿（lag compensation）
服务器按玩家当时的视角回滚世界状态进行命中判定，再恢复到当前时刻。回滚窗口越大，对高延迟玩家越友好，但被利用的风险也越高。见 7.2 FPS 的命中判定与延迟补偿
。
专用服（dedicated server）
为一局比赛独占启动的服务进程，常见于 FPS 与竞技。它提供稳定的 tick 与隔离，但需要池化和快速分配。见 7.2
。
观战延迟（spectator delay）
观战流相对实时状态的时间差，用于防作弊和防剧透。延迟越大，越安全，但观赛体验越差。见 7.3 观战、回放与赛事架构
。
回放（replay）
按事件日志或输入序列重建对局过程。回放的价值取决于确定性和版本可追溯性。见 7.3
。
AOI（area of interest）
只向玩家同步其关注范围内的实体。AOI 是大地图与开放世界的带宽与计算基础。见 8.1
、10.1
。
异步结算（asynchronous settlement）
把产出、战斗结果或赛季奖励从主循环中拆出，按事件或定时任务结算。它降低主路径延迟，但引入幂等与补偿问题。见 8.3
。
UGC（user-generated content）
玩家创作的地图、玩法或内容。服务端需要处理隔离、审核、版本不可变与发布回滚。见 10.2 UGC 地图的隔离、审核与发布
。
内容信任等级（content trust level）
按创作者身份与历史行为划分的能力与配额等级。等级决定审核强度、资源上限和可发布范围。见 10.3 玩家内容的信任模型
。
六、架构表达与治理
质量属性场景（quality attribute scenario）
把“低延迟”“高可用”写成可测量的场景：刺激、环境、响应、度量。没有度量的质量属性无法验收。见 2.1 质量属性与取舍
。
ADR（architecture decision record）
记录一项架构决策的背景、选项、决定、后果和退出条件。ADR 的价值在于留下“为什么”，而不只是“是什么”。见 2.2 ADR 决策记录
、12.3 决策的记录、评审与复盘
。
风险台账（risk register）
把架构风险按概率、影响、可探测性和缓解成本打分并排序的清单。它不是故障清单，而是“尚未发生但可能发生”的决策负债。见 2.3 架构评审与风险台账
。
C4 视图（context / container / component / deployment）
用四个层次表达系统：上下文、容器、组件、部署。每类视图服务不同读者，必须能对应到代码或配置中的锚点。见 12.1 C4、部署视图与数据流
。
契约表（contract table）
把接口的请求、响应、错误、幂等和超时写成表格，作为跨团队约定的最小单元。见 12.2 时序图、状态机与契约表
。
架构基线（architecture baseline）
某一时点被团队接受的架构取舍集合，包含已知风险与复审触发条件。基线不是“最终版”，而是“当前有意识的选择”。见 13.1 三款产品的架构基线
。
退出条件（exit condition）
一项决策在什么条件下应该被重新审视或推翻。没有退出条件的决策，会在环境变化后变成隐性债务。见 2.2
、12.3
。
常见混淆
最后列出几组最容易在评审里打架的词。
| 容易混淆 | 区别 |
|---|---|
| 拓扑 vs 部署单元 | 拓扑描述状态与流量怎么组织；部署单元描述代码怎么打包发布。一个模块化单体可以拆成多个部署单元，也可以是单个。 |
| 无状态 vs 不持久化 | 无状态指请求不依赖实例本地状态；不持久化指数据不落盘。两者不是一回事。 |
| 全球同服 vs 单库 | 全球同服是产品承诺；单库是实现选择。前者不要求后者。 |
| 帧同步 vs 状态同步 | 前者同步输入，后者同步状态；代价分别落在确定性与带宽/服务器上。 |
| 延迟 vs 卡顿 | 延迟是单次往返时间；卡顿是帧间隔不稳定。优化手段不同。 |
| 快照 vs 备份 | 快照用于快速恢复与迁移；备份用于灾难恢复与审计。保留策略和校验方式不同。 |
| 反作弊 vs 风控 | 反作弊针对作弊行为与协议异常；风控针对经济、交易与账号风险。两者需要共享证据，但策略不同。 |
术语只是起点。真正决定评审质量的，是每个词背后是否有可验证的定义、可比较的代价和明确的退出条件。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。