系列最后一篇。前面七章讲的是”现在这套系统长什么样”（上一篇：工程规范与 AI 协作），这一篇讲它是怎么一步步长成这样的，以及下一步往哪走。

依然四段：业务背景 → 方案设计 → 关键取舍 → 真实经验。

一、业务背景

这套系统不是从零设计的

这一点必须先说清楚，因为很多技术方案分享会给人一个错觉：好像一开始就有一张完整蓝图，然后按图施工。

真实情况不是这样。起点是：游戏要上线，业务不能等。

所以第一版走的是最快的路——先用三方发行 SDK 把游戏接进来：

  • 账号、支付、渠道分发都由三方提供
  • 能上线、能收钱、能出包，业务先转起来
  • 平台侧只做必要的配置和对接

这是正确的选择：在业务还没验证之前，自研一套发行底座是高风险投入。

三方 SDK 的天花板

但业务量上来之后，三方的边界开始变成自己的边界：

问题 具体表现
能力边界 = 对方的产品边界 你要的功能它没有；你不要的限制它有
数据在对方手里 对账、口径、时效都受对方影响；想按自己的口径分析，只能靠猜
开关不可控 关注册、关支付、灰度这类运营动作要排队等对方
成本随量增长 按量付费，量越大越不划算
节奏受制于人 你的上线计划取决于对方的排期

核心矛盾

“立刻能上线”和”长期能掌控”是两条路，而且不能只选一条。

只选第一条，业务永远长不大（天花板是别人的）；只选第二条，可能等不到系统建好业务就凉了。

所以真正的问题是：怎么从第一条路走到第二条路，而且中途不能断。

二、方案设计

2.1 总原则：三段式

演进路线分三段，每段的目标和成功标准都不同：

flowchart LR
    S1["第一阶段：先能跑<br/>借三方快速上线<br/>成功标准：业务转起来"] --> S2["第二阶段：再能控<br/>自研接管核心链路<br/>成功标准：数据与开关回到自己手里"]
    S2 --> S3["第三阶段：能省 / 能开放<br/>成本优化 + 能力开放<br/>成功标准：单位成本下降、能力可复用"]

关键点：每一段都不追求”终局形态”。

  • 第一阶段的目标是”活下来”，不是”架构优雅”
  • 第二阶段的目标是”掌控”，不是”技术先进”
  • 第三阶段才谈”优化”和”开放”

跳段的代价很大：第一阶段就想做第二阶段的事（自研一切），会在业务验证之前烧掉全部资源；第二阶段还想留着第一阶段的做法（数据还在三方），第三阶段永远开始不了。

2.2 过渡期：三方与自研并行

从三方到自研，中间必须有一段并行期。这段并行期怎么做，决定了迁移的成败：

① 先做数据对齐，再做技术切换

这是最重要的顺序。并行期第一件事不是”把流量切过来”，而是把三方数据同步进来，和自己的数据放在一起看：

  • 拉对方的产品列表和每日报表
  • 按产品维度、渠道维度两种粒度对照
  • 差异就是问题线索：是注册口径不同？付费口径不同？还是归因归属不同？

为什么必须先对齐口径？ 因为技术上”切换”很容易（改个配置、换个 SDK 版本），但如果两边的口径本来就不一致，切换之后你会失去判断”切得好不好”的能力——数字变了，你分不清是”系统切换导致的”还是”口径本来就不一样”。

② 按游戏灰度，而不是一次全切

新游戏直接走自研，老游戏留在三方；或者按能力域逐步切换（账号先切、支付后切）。

灰度不是为了”稳”，是为了保留对照组：两边同时有数据，才能持续验证自研的正确性。

③ 主动兼容对方的 schema，是迁移的依据

过渡期做了一件看起来”不划算”的事：把自研的账号表结构向三方的规范对齐（字段命名、类型、索引都按对方规范调整）。

为什么？因为对齐之后：

  • 两边数据能直接比对（字段含义一致）
  • 迁移有明确的目标形态（不是”我觉得应该这样”，而是”对方是这样，我要兼容或有意地不兼容”）
  • 将来如果要双向同步，不需要再做一次字段映射

兼容对方的规范不是技术妥协，是把”迁移”从一件模糊的事变成一件有依据的事。

2.3 接管顺序：按业务闭环依赖排，不按技术难度排

自研接管不是一次做完，而是按域逐个来。顺序是：

账号 → 支付 → 归因 → 分包 → 数据 → 后台

flowchart LR
    A["账号<br/>（一切入口）"] --> P["支付<br/>（钱）"]
    P --> AT["归因<br/>（效果）"]
    AT --> PK["分包<br/>（投放交付物）"]
    PK --> D["数据<br/>（决策依据）"]
    D --> AD["后台<br/>（操作界面）"]

这个顺序不是按”哪个好做”，而是按业务闭环的依赖关系：

  • 账号必须最先：它是所有链路的入口，也是数据归属的根。账号不在自己手里，后面所有的”数据”都只是别人的报表
  • 支付第二：钱的事必须自己掌握——结算、退款、对账，一个都不能外包
  • 归因第三：账号 + 支付通了，才能把”用户从哪来、值多少钱”算清楚
  • 分包第四：归因确定后，投放需要的交付物（带身份标识的包）才有意义
  • 数据第五：它依赖前面所有域的数据源，前面接管完，数据才是”自己的数据”
  • 后台最后：它是操作界面，前面都通了，后台才有东西可操作

每个域接管的判据是三条：

  1. 自研能力达到或超过三方（功能对齐 + 数据对齐）
  2. 切换不中断业务（灰度 + 可回退）
  3. 有对账手段（切换后能验证正确性）

三条缺一条，就不要切。 尤其是第三条——没有对账手段的切换，等于把系统的正确性交给运气。

2.4 扩展性检验：新平台、新支付要用”加适配器”的方式进来

演进过程中会不断有新东西要接：

  • 新的游戏平台（小游戏类平台）
  • 新的支付方式（平台内购、新的第三方登录）

这些接入是架构的体检：

如果新增一个平台，需要改的是适配层，而不是业务层——说明分层做对了。反之，如果每接一个平台都要改核心逻辑，说明抽象是假的。

实际的做法是把差异收敛到几个明确的扩展点：

  • 登录方式：每种方式只负责”验证凭据 → 得到平台用户”，后续流程复用（第二章的统一抽象）
  • 支付渠道：按游戏配置路由和账号绑定，新渠道是”加一个 provider”（第二章的支付链路）
  • 平台类型：平台差异体现在配置和出包策略上，不是散落在业务代码里（第三章的分包）

判断标准很具体：新增一个平台的改动，应该集中在”配置 + 适配器”两个地方。 如果改动扩散到订单、报表、后台，那这次接入就是在还技术债。

2.5 下一步往哪走

按第三阶段的目标，往前走有四个方向，每个都有前置条件（不是”想做就能做”）：

方向 具体内容 前置条件
补齐指标 成本类指标（消耗、ROI）从”规划中”转正 成本数据来源稳定 + 口径验证通过
实时化扩大 更多报表改成直接查事实表 事实表查询性能与成本可控
能力开放 把平台能力开放给合作方（从内部系统变对外服务） 契约稳定 + 鉴权/限流/计量就绪
运维自动化 告警、自动扩缩容、故障自愈 可观测性数据足够（先有度量，再谈自动化）

这四个方向有一个共同的前置条件：先把当前阶段做扎实。

这也是为什么第四章里那些”规划中”的指标没有被强行上线——演进路线里最贵的错误，是在条件不成熟时把一个方向”做了一半”：一半的实时化比不做更糟（口径不一致），一半的开放比不开放更危险（没有鉴权的对外接口）。

三、关键取舍

决策 选择 放弃的方案 理由
起点 三方 SDK 快速上线 自研从零起步 业务验证之前，自研底座是高风险投入
过渡方式 三方与自研长期并行 一次性切换 并行期提供对照组，是验证正确性的唯一手段
对齐顺序 先口径对齐，后技术切换 先切流量再说 口径不一致时，切换后无法判断好坏
账号模型 主动兼容三方规范 完全自定义 兼容让数据可比、迁移有依据
接管顺序 按业务闭环依赖 按技术难度 / 按工作量 依赖顺序错了会返工（比如先做数据，数据源还没接管）
切换判据 能力达标 + 不中断 + 可对账 只要”能跑”就切 没有对账手段的切换无法验证正确性
新平台接入 加适配器 改核心逻辑 改动扩散范围是分层是否成功的检验标准
未成熟能力 明确标记”规划中” 先上一半 一半的实时化/开放比不做更糟
演进节奏 分域逐步推进 大版本一次性重构 业务不能停，且重构范围越大越难验证

四、真实经验

1. 过渡期最贵的不是迁移，是口径对齐

迁移的工程量是可估算的（改代码、迁数据、切流量），但口径对齐的工程量极难估算——因为它不是写代码，是两个团队（或自己和合作方）对”同一个词”的理解达成一致。

实际经历是：技术切换本身很快，但为了确认”两边的注册数、付费数、归因数为什么不一样”，花的精力远超预期。而这些差异里，只有一部分是”错的”，另一部分是”口径不同但都对”——必须逐个确认。

结论：口径对齐要当成一个独立的、需要排期的项目，而不是迁移的附带工作。

2. 兼容对方的 schema，让迁移从”拍脑袋”变成”有依据”

对齐账号表结构这件事，当时的直觉是”我们自己的系统为什么要按别人的规范改”。

但实际收益很快就显现了：迁移和比对不再需要讨论”字段应该叫什么、类型应该是什么”——要么对齐，要么有意识地不对齐并记录原因。

在迁移类项目里，”和目标形态一致”比”设计上更优雅”重要得多。

3. 切换必须留一条”回得去”的路

灰度 + 双跑 + 对账，这三样合起来提供的是回退能力。

有一次切换后数据出现异常波动，因为有对照组和对账手段，半小时内就定位到是”某类特殊订单在新链路上的处理差异”，修复后补数据即可——如果没有对照组，这个波动会被当成”业务正常波动”而错过。

“回得去”不是保守，是让切换可以被验证的前提。

4. 新平台接入的改动范围，就是架构的体检报告

每接入一个新平台（新的小游戏平台、新的登录方式、新的支付渠道），都会自然产生一个问题：这次改了哪些文件？

  • 如果改动集中在配置和适配器 → 分层是有效的
  • 如果改动扩散到订单、报表、后台 → 说明这次的差异没有被收敛到扩展点，应该先补抽象再接下一个

这个”体检”应该主动做，而不是等到第三次接入时才发现每次都很难。

5. 没成熟的能力不要”先上一半”

第四章说过”未验证的指标标记为规划中”，这一条在演进路线里同样成立。

半成品的危害不是”不好用”，而是”看起来能用”：

  • 一半的实时化 → 两个报表口径不一致，没人知道该信哪个
  • 一半的开放接口 → 没有鉴权和限流的对外接口，等于把系统暴露出去
  • 一半的成本指标 → 没人敢用，但又占着”已上线”的名额，没人再去推动它做完

在演进路线里，明确”这一步不做”比含糊地”做了一半”有价值。

6. 演进是常态，不是项目

最后一条件是对整个系列的收尾：

这套系统的每一块——账号、支付、分包、数据、后台、运维、规范——都是一个可以独立往前走的能力域。

所以”演进路线”不是一张一次性走完的图，而是一个长期的工作方式：

  • 每个能力域都有自己的当前阶段和下一步
  • 每次决策都要问”这个选择会不会挡住下一步”
  • 架构的价值不在于当前形态有多好，而在于它允许你继续改变

系列回顾

八篇写完，回头看这套方案的骨架：

章 回答的问题
（一）总体架构 系统由哪些部分组成，边界在哪
（二）SDK 接入层 玩家怎么进来、怎么付钱
（三）打包与分包 投放和渠道需要的包怎么生产
（四）数据体系 行为怎么变成决策依据
（五）发行后台 人怎么操作这套系统
（六）稳定性与运维 怎么在无人值守时保持可用
（七）工程规范与 AI 协作 怎么被持续改对（含 AI 协作）
（八）演进路线 怎么一步步长成现在这样，下一步往哪走

如果只读一篇，建议从（一）开始——它决定了后面所有章节的边界；如果要落地，建议从（八）的接管顺序开始——它决定了先做什么、后做什么。

本文基于实际项目整理，已脱敏。文中不含任何公司业务数据、配置或凭据。