长周期成长型架构

Category

design / problem-domains 子树。节点定位：长周期成长型问题域的横向速查——状态沉淀、异步结算、滚服合服、经济治理、长线数据迁移。

Definition

这一页从问题域角度归纳长周期成长型项目，是问题域附录的横向速查版。它不重复推导资产模型和运营链路为什么长成这样，而是把这类项目区别于其他类型的关键判断集中在一页：状态怎么沉淀、异步怎么结算、服务器怎么滚怎么合、经济怎么治理、数据怎么活过三年。

一句话画像：账号是状态的承载单位，会话只是访问窗口，价值以月和年为单位沉淀，运营节奏比玩法迭代更频繁地触碰数据。放置挂机、卡牌养成、SLG 养成线、MMO 成长线、模拟经营都落在这个画像里。

Problem

成长型项目的判断集中在数据的时间尺度上：状态怎么沉淀、异步怎么结算、服务器怎么滚怎么合、经济怎么治理、数据怎么活过三年。这五件事都随运营时间放大，事后补课的代价是账务事故。

这个问题域的特征

• 状态生命周期以账号为单位，以月年计，任何一次写坏都要面对“回滚到三个月前”的难题。
• 交互大量异步，离线收益、邮件发放、挂机结算、定时奖励，计算发生的时刻与玩家感知的时刻是分离的。
• 数值本身就是玩法，成长曲线、货币产出与回收、活动叠加直接决定留存和收入。
• 运营强度主导系统形态，活动、版本、补偿、回档比新玩法更常改动核心数据。
• 数据一旦沉淀就难以重建，删除和修改都带审计与合规代价。

前三条特征让这类项目把复杂度压在数据生命周期上，后两条让它把复杂度压在运营链路上，这两条主线构成它区别于房间型和世界型的基本面貌。

与相邻类型的边界

• 和单局房间型相比，它的局内过程通常很轻，真正需要长线治理的是局外的资产、进度与关系，两者恰好互为镜像。
• 和持续在线世界型相比，它常驻的是账号而不是世界，难点不在空间与并发交互，而在数据版本、迁移与审计。
• 和经济平台型相比，它的经济是设计出来的产出回收曲线，货币主要在玩家与系统之间流动，而不是在玩家之间自发定价流转。

判断一个项目属于哪类，常见做法是看主导矛盾：如果口碑主要取决于“数值对不对、发没发错东西、停服了数据还在不在”，它就是成长型主导，哪怕同时挂着战斗和社交系统。

特征推导出的架构约束

长周期状态约束了数据模型：对象结构要能带着版本演进，快照与流水通常并存，回档和审计能力往往在第一年就要建，而不是出了事故再补。

异步交互约束了写路径：入账通常收口到统一的资产变更接口，每笔变更有幂等标识、有流水、可重试且不重复发放。

数值即玩法约束了配置链路：成长曲线、货币规则、活动编排通常全部配置化，配置变更往往需要灰度、校验和回滚，其风险量级不亚于一次代码发布。

运营强度约束了审计与补偿：发奖入口通常收敛为少数几个，每个入口可追踪、可对账，补偿走的链路与正常发放相同，避免出现绕过审计的第二条路。

异步交互与离线结算

异步是这类项目最日常也最容易出错的部分，因为它把“算出来”和“发下去”拆成了两个时刻。

• 离线收益通常在登录时或定时任务里计算，常见做法是设置时长上限与收益封顶，避免一次回归结算打穿数值曲线。
• 邮件往往承担通用异步发放通道的角色，带附件、带有效期、带领取状态，附件领取本身也要幂等。
• 定时结算与玩家操作可能并发触达同一份资产，常见的保护手段是版本号或条件写，而不是先读后写。
• 跨天、跨时区的结算边界要在系统里只有一处定义，多处各自判断“今天”往往是重复发奖的源头。

结算链路的取舍核心是宁可慢发、不可错发：发晚了玩家投诉，发错了玩家失去信任，两者的恢复成本差一个量级。

滚服与合服

滚服是这类产品最常见的容量与商业化形态：每个服是一个独立数据域，容量按开服节奏横向铺开，单服规模可控，故障影响面也按服隔离。

• 滚服的代价沉淀在生命周期末端：合服时名字冲突、角色 ID 冲突、排行重建、社交关系合并、交易记录归属，全都要处理。
• 合服本质是一次长线数据迁移，多年沉淀的僵尸账号、脏数据和跨服资产会在这一次集中暴露。
• 常见做法是开服第一天就为合服预留全局唯一 ID 和命名空间，把合服从“数据拼接”降级成“命名空间归并”。
• 排行与跨服玩法通常在合服时重建或迁移到跨服集群，本服只保留基础资产。
• 滚服产品往往同时存在多个数据结构版本，老服与新服有代差，合服时的跨版本迁移是迁移课题里最难的一档。

只按单服峰值做容量规划、从未演练合服的项目，往往在产品中期被迫停服合并，而那正是流水最不能停的时刻。

经济沉淀与通胀治理

长线运营的货币总量通常只增不减，通胀往往不在第一个月出现，而在一年后以物价和流失率的形式显现。

• 产出口与回收口要成对设计，回收口通常是修理、消耗、合成、抽取这类持续消耗玩法，而不是一次性大额回收。
• 货币常见做法是分类管理，绑定货币与流通货币分账，能进流通的口子越少越好治理。
• 治理通胀依赖流水级数据：只有看到每一笔产出去向，才能判断漏洞在哪个玩法、哪个活动、哪个渠道。
• 常见治理手段是新回收玩法加定向回收，直接回档或削资产往往引发舆情，代价远高于日常治理。

不少项目的第一轮通胀来自发奖配置错误而不是设计失误，这说明治理的第一步往往是把发奖入口和校验收紧，而不是调曲线。

经济数据的口径问题在这一页特别值得强调：产出、回收、沉淀三个口径对不齐的项目，运营和研发往往各说各话，等达成共识时通胀已经成型。

长线数据迁移

这类项目的表结构和存储形态三年后往往与第一年完全不同，迁移因此是一项常态工程而不是一次性任务。

• schema 演进通常靠版本化字段和兼容读实现，老数据在读取时补齐默认值，写入时升级到新版本。
• 冷热分层是常见形态，活跃账号保持热数据，长眠账号下沉到低成本存储，登录时再唤醒。
• 回档能力由快照加流水共同决定：快照决定能回到哪个时刻，流水决定回到那个时刻之后还能补算什么。
• 迁移脚本要能跨多个版本接力，只能从最新版本迁移一步的项目，在多年老服面前往往无从下手。

迁移与回档能力很少出现在需求列表里，却往往决定事故的止损上限，常见做法是把恢复演练排进常规节奏，而不是等事故检验。

常见方案形态

典型形态是以账号域为核心的服务群：角色、背包、邮件、任务、商城按域拆分，以统一的资产变更接口收口，外围由配置中心、活动编排和结算任务驱动。

• 资产服务维护余额与流水，玩法服务不直接改资产，只提交带幂等键的变更请求。
• 活动系统通常配置驱动，一个活动的上下架、奖励内容、参与条件都不需要发版。
• 定时任务与离线结算器独立部署，按玩家或按分区批量推进，失败可重试。
• 数据侧常见双轨：快照供查询与回档，流水供对账与审计。

这套形态的弹性主要来自滚服与异步，单服内部通常不追求高并发，追求的是数据正确性与可恢复性。

该类型特有的坑

发奖入口失控：每个活动一个发奖函数，各自写资产，幂等与审计随之失效，出了重复发放说不清从哪个口漏的。

离线结算拍脑袋：收益没有上限，回归玩家一次结算几十天，数值曲线被打穿，后面所有活动都在为这一次买单。

合服当成拼接任务：只做数据合并，不处理 ID 与命名冲突，合完出现两个“自己”，社交关系和交易记录张冠李戴。

经济数据只看总量：没有流水级明细，通胀来了不知道从哪个玩法漏的，治理只能全局一刀切，误伤正常玩家。

回档从未演练：快照一直在备，恢复链路从未走过，真出事时才发现快照不完整，或恢复耗时远超预期。

常见误区

• 把这类项目当成“没有实时要求所以后端很简单”，实际上实时要求低了，长期状态与运营复杂度会顶上来。
• 用玩法功能的开发速度衡量架构质量，忽略资产模型、对账与回滚能力才是这类项目真正的底盘。
• 把横向速查结论当成完整推导，看到“成长型”三个字就套方案，没有先确认主导矛盾确实是数据生命周期与运营链路。

这类项目的架构方向通常可以概括为：账号常驻会话短，异步入账幂等收口，滚服开局合服留路，经济治理靠流水，回档能力靠演练。

Used By

成长型项目评审速查；滚服/合服预案；长线数据规划。

Related

关系链：特征 → 边界 → 约束 → 异步结算 → 滚服合服 → 经济治理 → 数据迁移。上游：industry/models/05。下游：database 树、numerical 树、economy 树（规划迁入）。

Reference

本页为工程经验归纳。