这份附录解决什么问题
卷一用三款产品反复做同一个练习：先把产品事实摆出来，再看哪些拓扑落在可行域内，最后把选择和代价写成基线。
正文按主题分散展开，评审时却需要一张能快速对照的表。这份附录把散落在第 1、3、5、6、7、8、9、11、13 章的结论收拢到一起，给出：
- 三款产品的产品事实与五特征向量；
- 五个特征在四种强度下的判定口径；
- 25 个“特征 × 拓扑”格子的结论摘要；
- 三张架构基线卡；
- 矩阵的使用方法、平局规则与失效条件。
表中没有新的数字。所有参数都来自对应章节；如果与正文冲突，以正文的推导为准。
一、产品事实
先看输入，不看结论。
| 事实 | 《裂隙战场》 | 《群岛纪元》 | 《泡泡工坊》 |
|---|---|---|---|
| 品类 | 5v5 竞技 | SLG | 休闲小游戏 |
| 同时在线 | 20 万（示例值） | 8 万（示例值） | 3 万（示例值） |
| 单局时长 | 约 10 分钟 | 无固定对局，赛季制 | 约 8 分钟 |
| 是否共享世界 | 否，每局独立 | 是，4096×4096 大地图 | 否，房间内共享 |
| 实时要求 | 帧级，tick 33ms | 秒级，操作 p99 20ms | 100–200ms 可接受 |
| 状态规模 | 单房小，房间总量大 | 单地图大，需分片 | 单房小，总量中等 |
| 跨区需求 | 赛区间匹配与对战 | 跨区行军、联盟、王战 | 基本无 |
| 团队规模 | 8 名后端 | 6 名后端 | 2–3 名后端 |
| 上线节奏 | 赛季更新，玩法稳定 | 周更活动，赛季制 | 两周一个新玩法 |
这张表里没有“应该用什么架构”。它只有可以被追问、被测量的产品约束。任何一条写不出来，后面的矩阵就只能是猜测。
二、五特征向量
internal/matrix 使用五个特征，每个特征取 0–3 四档。
| 特征 | 要回答的问题 | 0 | 1 | 2 | 3 |
|---|---|---|---|---|---|
| 实时性 | 玩家是否感知帧或操作延迟 | 无连续操作 | 秒级反馈可接受 | 100–300ms | 帧级，50ms 以内 |
| 共享世界 | 玩家是否共享持久世界 | 每局独立 | 单局内共享 | 小型持久世界 | 全球大地图 |
| 房间制 | 玩法是否以离散对局为单位 | 无对局 | 弱对局边界 | 部分玩法分房 | 一局即一个故障域 |
| 状态规模 | 每 tick 需要裁决多少状态 | 很小 | 单进程可容纳 | 需要分片 | 全球多分片 |
| 跨区需求 | 跨地域交互是否影响公平或体验 | 无 | 弱社交 | 有跨区玩法 | 强对抗或强协作 |
三款产品回填后的向量：
| 产品 | 实时性 | 共享世界 | 房间制 | 状态规模 | 跨区需求 |
|---|---|---|---|---|---|
| 《裂隙战场》 | 3 | 0 | 3 | 2 | 2 |
| 《群岛纪元》 | 0 | 3 | 0 | 3 | 3 |
| 《泡泡工坊》 | 0 | 0 | 3 | 0 | 0 |
向量必须附证据：并发、会话时长、操作预算、峰值 tick 成本、跨区 RTT。没有证据的档位只能当假设，不能当结论。
三、25 个格子的结论摘要
完整矩阵见 13.2 品类与拓扑决策矩阵 。这里给出便于速查的摘要。
| 特征 \ 拓扑 | 模块化单体 | 大厅 + 房间 | 分区世界 | 全球同服 | 专用服池 |
|---|---|---|---|---|---|
| 实时性 | 可选 | 推荐 | 可选 | 不推荐 | 推荐 |
| 共享世界 | 可选 | 不推荐 | 推荐 | 推荐 | 不推荐 |
| 房间制 | 推荐 | 推荐 | 可选 | 不推荐 | 推荐 |
| 状态规模 | 不推荐 | 可选 | 推荐 | 推荐 | 可选 |
| 跨区需求 | 不推荐 | 可选 | 可选 | 推荐 | 可选 |
读这张表时要注意三件事。
第一，“推荐”不等于“必须”。它是“值得进入下一轮评审”的意思。最终选择还要过组织、成本、合规三道关。
第二，“不推荐”不等于“不能做”。它是“除非有外部约束，否则不应作为首选”。如果团队已有成熟能力，或产品阶段特殊，可以选，但必须在 ADR 里写清楚为什么。
第三，格子之间会冲突。一个产品同时要求帧级实时和全球共享大地图时，矩阵会给不出高分方案。正确做法往往是拆成两套子系统：竞技战场按房间就近部署，世界地图按地域分片，中间用事件同步。
四、三张基线卡
《裂隙战场》
| 字段 | 当前基线 |
|---|---|
| 拓扑 | 大厅 + 房间，按赛区部署 |
| 状态归属 | 对局状态在 room 内存；会话与房间绑定在 allocator；账号、支付、结算在平台 |
| 连接模型 | QUIC 流承载关键帧，数据报承载可丢状态；断线按对局 ID 重连 |
| 权威模型 | 预测-回滚-重放；服务端唯一写入生命、伤害、命中与比赛结果 |
| 部署单元 | lobby（无状态）、allocator（租约存储）、room（有状态、按赛区） |
| 关键 SLA | 帧预算 p99 33ms；操作反馈 p99 150ms；暖池开房 p99 3s（示例值） |
| 已接受取舍 | 房间崩溃只影响一局；赛区隔离优先于全球匹配速度 |
| 已知风险 | 跨赛区匹配 p99 超 800ms；幽灵房间数高于基线 |
| 复审触发 | 单赛区房间数超过调度器上限；跨赛区匹配成为主玩法；tick p99 连续一周超过 33ms |
《群岛纪元》
| 字段 | 当前基线 |
|---|---|
| 拓扑 | 全球同服 + 地域分片；按矩形范围切地图 |
| 状态归属 | 地图格与舰队在 world-shard；主城资源在 economy；联盟外交在 alliance；全球事件只存事件；账号支付在赛区 |
| 连接模型 | WebSocket 长连接，CDN 前置静态与事件；跨区只同步脱敏事件 |
| 权威模型 | 纯状态同步；服务端裁决移动、战斗与归属，客户端不做权威预测 |
| 部署单元 | gateway、world-shard（有状态）、economy、alliance、global-event |
| 关键 SLA | 同分片操作 p99 20ms；同赛区跨分片 p99 60ms；跨赛区异步事件 p99 300ms（示例值） |
| 已接受取舍 | 跨区不同步个人状态；热区分片按矩形拆分，不搬玩家 |
| 已知风险 | 跨地域匹配 p99 超 800ms；同一 battle_id 重复发奖；王战写入放大 3 倍 |
| 复审触发 | 跨地域延迟导致战争结果不可接受；合规要求数据本地化；单分片峰值 tick 成本超预算 |
《泡泡工坊》
| 字段 | 当前基线 |
|---|---|
| 拓扑 | 模块化单体；房间是内部模块，不是独立服务 |
| 状态归属 | API 无状态；账号、背包、活动进度在 Postgres；会话与排行榜在 Redis；分享图与回放在对象存储 |
| 连接模型 | 托管 WebSocket 或长轮询；断线重连后重新拉取房间快照 |
| 权威模型 | 服务端权威；客户端只做表现层预测，不写权威状态 |
| 部署单元 | api（无状态、至少 2 副本）、postgres（有状态）、redis、object-store |
| 关键 SLA | 登录 p99 200ms；房间操作 p99 200ms（示例值） |
| 已接受取舍 | 单服务换上线速度；房间不独立部署；成本上限优先于功能完整 |
| 已知风险 | 对象存储出流量打穿日预算；配置写死导致故障时无法回滚 |
| 复审触发 | 每周因发布冲突回滚两次以上；单接口 CPU 占用超过一半；房间模块需要独立扩容 |
五、三张卡放在一起
| 维度 | 《裂隙战场》 | 《群岛纪元》 | 《泡泡工坊》 |
|---|---|---|---|
| 拓扑 | 大厅 + 房间 | 全球同服 + 地域分片 | 模块化单体 |
| 状态权威 | 房间内存 | 地图分片 | Postgres |
| 连接 | QUIC 流 + 数据报 | WebSocket + CDN | 托管 WebSocket / 长轮询 |
| 权威模型 | 预测-回滚 | 状态同步 | 服务端权威 |
| 故障域 | 单房间 | 单矩形分片 | 单服务 |
| 首要 SLA | 33ms tick | 20ms 同片操作 | 200ms 操作 |
| 复审触发 | 调度器上限 | 合规与跨区延迟 | 发布冲突与扩容 |
这张表最重要的用途不是“照着选”，而是检查自己的产品落在哪一列，以及有没有同时要求两列的能力。
六、矩阵怎么用
步骤一：填事实，不填愿望
先把同时在线、单局时长、实时要求、世界共享、跨区需求写成可测量的值。不要写“我们想做成全球同服”，要写“跨区行军是否必须在秒级内可见”。
步骤二：给每个特征附证据
实时性填 3，就要给出操作预算和 tick 实测；状态规模填 3，就要给出峰值活跃实体数与单分片成本。没有证据的档位，评审时应降一档处理。
步骤三：跑矩阵，看前三名
矩阵只负责排序。前三名都值得进入方案设计；分差小于两分时，不要用“分高”当理由，要看代价列和组织约束。
步骤四：把选择和代价写进 ADR
至少写清：为什么不选第二名、选择在什么条件下失效、需要补哪些能力（例如分配器、暖池、跨区事件总线）。见 2.2 ADR 决策记录 。
步骤五：设置复审触发
触发条件要可观测：房间数、tick p99、跨区 RTT、合规变化、团队规模。没有触发条件的基线，会在环境变化后变成隐性债务。
七、平局规则
矩阵的原始输出是分数。同分时按下面的顺序裁决：
- 运维成本低的优先：同等分数下，少一个部署单元、少一套中间件，通常意味着更少的故障面。
- 团队已有能力的优先：已经有成熟专用服池的团队，不必为了两分改走大厅 + 房间。
- 可逆性高的优先：能通过增加模块、后置拆分演进的方案，优先于一开始就锁死边界的方案。
平局规则必须显式写进评审记录，不能藏在排序函数或会议主持人的偏好里。
八、失效条件
矩阵在以下情况下不能直接使用：
- 组织约束缺失：团队只有两三个人，矩阵仍可能推荐多个部署单元；这时要用成本与上线速度否决。
- 合规约束缺失：数据必须本地化时，“全球同服”在物理上只能退化为地域分片加事件同步。
- 特征是拍脑袋的：没有证据的向量，输出只是偏好的排序。
- 产品阶段变化：立项期的休闲产品后来加入实时对战，向量会整体变化，旧结论必须重跑。
- 同时存在两个强特征：实时加全球大地图、强对抗加强合规，矩阵通常给不出单一答案，需要拆系统而不是选拓扑。
九、给评审主持人的三个问题
如果时间只够问三个问题，问这三个：
- 这份向量里，哪一档没有证据？ 没有证据的档位决定了结论的可信度。
- 第一名和第二名的分差，主要来自哪个特征？ 如果只差一两分，说明选择对特征判断很敏感，需要更谨慎。
- 如果明年产品事实变了，哪个触发条件会让我们重开这个决策？ 答不出来，说明基线还没有真正建立。
矩阵是工具，不是答案。它能做的是把争论从“我觉得”挪到“哪一档、什么证据、什么代价”。这三件事说清楚，评审就已经成功了一半。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。