游戏后端设计的核心取舍
Category
industry / methodology 子树。节点定位：五组拉扯——权威 vs 响应、单体 vs 分布式、实时 vs 后台、一致性 vs 可恢复、通用 vs 特化；设计能力是知道哪边必须赢。
Definition
游戏后端设计里最难的部分，不是把服务跑起来，而是接受很多目标不能同时极致成立。权威性、实时性、扩展性、开发效率、运维成本、版本兼容、反作弊能力，彼此之间一直在拉扯。所谓设计能力，往往就是知道哪一边必须赢，哪一边可以退。
Problem
权威性、实时性、扩展性、开发效率、运维成本、版本兼容、反作弊不能同时极致成立。不预先声明取舍，团队会在每个需求上重新吵一遍；取舍写清楚，方案才可评审、事后才可复盘。
权威性与响应速度
谁说了算，是后端设计的第一道分水岭。
- 服务器强权威更安全，也更适合裁决资产和战斗结果，但开发与网络成本更高。
- 客户端承担更多逻辑，响应会更直接，开发期也更灵活，但作弊、分叉和一致性风险更大。
大多数线上项目最后都不是纯粹二选一，而是分层处理：核心资产和关键战斗结果保持服务端权威，表现细节、预测反馈和部分弱一致内容留给客户端兜体验。
单体效率与分布式复杂度
拆分服务可以降低耦合、提高独立扩缩能力，但也会引入注册发现、链路追踪、超时重试、幂等处理、数据一致性和跨服务排障成本。对于很多中小规模项目，过早拆分的收益远低于复杂度开销。
相反，完全不拆也有明显代价：
- 一个模块出问题会拖累整进程。
- 不同链路的容量模型混在一起，扩容粒度太粗。
- 不同团队并行开发和发布会互相牵制。
关键不在于“单体还是微服务”哪个更先进，而在于主链路的执行单元和发布单元是否清晰。
实时链路与后台链路
游戏后端里最值得明确分开的，是实时交互链路和后台处理链路。前者追求稳定延迟和可预测执行时间，后者更强调吞吐、补偿、批处理和可审计性。把二者混在一起时，常见后果是：
- 局内逻辑被慢 SQL、远程依赖或批量任务拖慢。
- 活动结算和奖励补发无法完整审计。
- 排障时看不出问题发生在实时执行层还是异步数据层。
因此很多系统最终都会形成“实时执行核心 + 异步外围系统”的结构，不一定复杂，但边界必须稳。
一致性与可恢复性
游戏后端很少能追求所有场景下的强一致。更现实的做法是区分：
- 哪些状态必须强一致，比如付费到账、资产扣增、结算裁决。
- 哪些状态允许短暂滞后，比如排行榜展示、推荐结果、运营看板。
- 哪些状态只需要最终一致，比如日志归档、埋点清洗、通知投递。
一致性等级不同，恢复手段也不同。强一致链路重点是事务、幂等和审计；最终一致链路重点是消息重放、补偿任务和对账工具。
通用能力与项目特化
后端团队总会想做通用底座，但游戏项目又高度依赖具体玩法。底座过少，重复建设严重；底座过多，又会出现“所有业务都得绕着平台设计”的反效果。比较健康的方式通常是：
- 把账号、角色、支付、日志、监控、配置、审计这类稳定能力平台化。
- 把战斗规则、房间规则、活动编排、经济细则留在项目域内。
如果把变化最快的玩法逻辑也强行平台化，平台本身会变成新的耦合中心。
常见错误
- 为了“安全”把所有逻辑都堆到服务端，结果开发效率和成本失控。
- 为了“快”把裁决权过度下放给客户端，后期再补反作弊和审计。
- 把实时战斗链路和后台批处理链路混在一套执行模型里。
- 用互联网微服务模板直接套游戏项目，没有先识别局内执行和房间状态的特殊性。
后端设计的核心不是追求一种正确答案，而是先分清哪些成本必须付，哪些风险必须压，哪些复杂度只是自我感动。
Used By
架构决策记录的取舍框架；方案评审的对齐语言。
Related
关系链：权威 vs 响应 → 单体 vs 分布式 → 实时 vs 后台 → 一致 vs 可恢复 → 通用 vs 特化。上游：methodology/03（五步分析）。下游：production/retro/02（模式的对照展开）。
Reference
本页为工程经验归纳。