架构模式与选型对照

Category

production / retro 子树。节点定位：模式是对问题域的回答——单服全量、房间进程、大世界分区、模块化单体、服务化、Actor 各自匹配什么问题，按问题维度对照而不是按名词。

Definition

架构模式的争论经常吵不出结果，原因往往是拿不同问题域的答案在互相比。单体分服是长线成长品类的成熟答案，房间进程是单局闭合品类的成熟答案，大世界分区是持续在线品类的答案，它们本来就不在同一个赛道上。对照架构模式之前，更有用的一步是先确认自己项目的主导问题域是什么，否则对照表做得再细，也只是把别人的答案误配到自己的问题上。

Problem

拿名词对名词的架构对照（「我们用 Actor，他们用微服务」）不收敛也不成立：模式脱离问题域就没有对错——单服全量在千万 DAU 下是灾难、在十万 DAU 下是效率之王。对照的价值在于把每个模式的适用边界和代价说清，组合使用才是常态。

模式不是风格，而是对问题域的回答

每一种常见架构模式，都在回答一组特定的问题：

• 单体全量：所有逻辑在一个进程里，适合状态简单、规模可控、团队很小的阶段。
• 分服结构：按区服切分状态和玩家，适合资产强绑定、社交在服内闭合的长线品类。
• 房间进程：以一局为状态生灭单位，适合对局闭合、局外只留结果的品类。
• 大世界分区：把持续在线的世界切成可管理的区域，适合世界状态长期存在且玩家自由移动的品类。
• 无状态接入加有状态逻辑：把连接层和逻辑层分开，适合连接规模大、逻辑状态集中的场景。

这些模式没有高低之分，只有是否匹配当前问题域的区别。讨论时常见的第一句话“我们该用什么架构”其实问反了，更有效的问法是“我们的状态以什么为单位生灭、权威放在哪里、什么负载会先到顶”。

对照要用问题维度而不是名词

把模式放在一起比较时，真正可比的不是名字，而是几个稳定的维度：

• 状态归属：状态在哪个单元里存活，谁来承载权威。
• 生命周期：状态随什么创建和销毁，一局、一个区服还是整个世界。
• 扩缩容单位：流量涨了，是加机器、加进程还是迁移区域。
• 故障半径：一个单元出问题，影响多少人、多久能恢复。
• 运维复杂度：日常发布、扩容、排障需要多少人力和流程支撑。
• 发布节奏：模块能不能独立发布，一次变更的影响面有多大。
• 团队认知负担：新人多久能理解全局，出问题多少人能定位。

两个模式在维度上互有胜负很正常。对照的目的不是选出全能冠军，而是找出与自己最优先的维度匹配、且最差维度尚可容忍的那一个。

单服全量与分服结构的对照

这组对照的实质，是状态要不要横向切开。分服把玩家资产和社交关系锁定在一个服内，好处是状态简单、故障半径小、合服还能当运营手段用；代价是跨服玩法全部要额外的链路，排行榜、匹配、跨服战都会变成独立问题。单体全量省掉了这些跨服链路，但状态规模、发布风险和单点故障会随在线增长持续恶化。

常见的判断依据是资产和社交的闭合程度：玩家投入主要沉淀在服内关系和资产上，分服通常更省力；玩家更在乎实时对抗和全服生态，切分就要谨慎，因为切下去之后再想合回来的成本极高。还有一个常被忽略的变量是运营策略：如果把开新服、合服当作商业化节奏的一部分，分服结构本身就是运营工具，这个用途在全量结构里并不存在。

房间进程与大世界分区的对照

这组对照的实质，是状态的生灭粒度。房间进程以一局为单位，开局创建、结算销毁，状态天然有界，故障影响一局，扩容就是多开进程。大世界分区的状态长期存活，迁移一个区域要搬走玩家的全部上下文，扩容和故障处理都复杂得多。

容易误判的地方在于混合品类：一个持续在线世界里的部分玩法被房间化实例承载，或者一个房间制产品的匹配、社交和资产又是长线系统。这时两种模式往往同时存在，真正要设计的是它们之间的边界，而不是争哪个模式更先进。

模块化单体与服务化拆分的对照

服务化拆分在游戏后端经常被过早引入。拆分带来的独立发布、独立扩容和故障隔离是有价值的，但代价同样真实：进程间通信、部署编排、链路排障、数据一致性，每一项都会长期消耗团队精力。

更常见的健康路径是从模块化单体起步，保持模块边界清晰，等某个模块的负载曲线、发布节奏或团队归属真的分化了，再把那一个模块拆出去。按“哪里痛拆哪里”推进，往往好过按“业界都拆了”一次性铺开。反过来，已经拆开的系统想合并回去同样困难，所以拆分决策值得按不可逆决策的标准来论证。

Actor 与共享内存加锁的对照

这组对照发生在进程内部。Actor 类模型把状态圈在独立单元里，消息串行驱动，好处是没有锁竞争、故障定位相对清晰；代价是跨单元操作变成异步消息，事务性操作写起来绕。共享内存加锁思路直接、表达直观，但锁的粒度设计和死锁排查会持续考验团队。

常见的收敛方式是按状态的热度和交互模式分层：强交互、高频更新的核心状态用单线程串行驱动，弱交互的外围系统用并发框架处理。多数线上事故的根源不是选了哪一边，而是两条路径混在同一个状态上没有边界。

判断时还有一个实用线索：团队此前主要写过哪类代码。从业务后端转来的团队往往更适应共享内存思路的表达，从网络框架转来的团队更适应消息驱动。延续熟悉模型的收益，通常大过追逐理论上的优雅。

组合使用才是常态

稍大一点的项目几乎都是模式的组合：接入层无状态、逻辑层房间进程、资产层分服或全局唯一、运营侧服务化。组合本身不是问题，问题通常出在边界模糊：

• 房间进程直接改写长期资产，局内状态泄漏到局外。
• 全局服务和区服逻辑互相等待，故障跨层传染。
• 同一份数据在两个模式里各有权威，对不上时不知道信谁。
• 边界接口没有版本意识，一侧升级就把另一侧拖进发布周期。

组合架构下值得守住的原则是：每种模式只在自己的问题域内拥有权威，跨域交互走明确的契约和接口，而不是共享内存和直接调用。

什么时候需要重新对照

架构对照不是立项时做完就归档的事。一些信号出现时，往往意味着值得重新对一遍：

• 不同模块的负载曲线明显分化，统一扩容开始浪费或不足。
• 跨模块故障传染频繁，隔离需求超过了当初的估计。
• 团队规模变化，认知负担模型已经和现实不符。
• 品类方向调整，主导问题域从一种换成了另一种。
• 立项时对负载形态的假设被产品调整推翻，原架构的前提不再成立。

重新对照时常见的错误是只在现有架构上打补丁，而不敢重新审视当初的维度假设。对照的意义正在于此：维度相对稳定，模式只是维度的解。

常见误区

• 把模式当流派站队，而不是当成对不同问题域的回答。
• 只比名词和口号，不比状态归属、扩缩容单位、故障半径这些实质维度。
• 用别家成功项目的架构反推自己，却看不到对方的问题域和团队条件不同。
• 服务化拆分不是因为痛，而是因为流行，拆完后通信和排障成本吃掉收益。
• 混合品类里两种模式都上了，却没有设计清楚边界和权威归属。
• 架构定型后不再对照，负载和团队都变了还按旧假设运转。
• 对照结论没有留下记录，下一次讨论从零开始。

架构对照的价值，不在给出一个标准答案，而在让团队用同一套维度说话。维度清楚了，分歧会变小；维度含糊，选什么模式都会在上线后重新吵一遍。

Used By

架构选型评审（按问题维度对照模式）；架构演进判断（什么时候需要重新对照）；跨团队架构讨论的公共语言。

Related

关系链：问题域 → 对照维度 → 五组对照 → 组合使用 → 重新对照的信号。上游：retro/01（选型方法）。下游：server 树（服务端模式的展开）、industry 树的问题模型（industry/models）。

Reference

本页为工程经验归纳。