《游戏服务端架构·平台化与架构治理》序：平台化是架构的第二次长大

一套能跑的系统，不等于一套能被别人用的系统

前三卷结束时，北辰工作室已经拥有了一套能解释清楚的架构：按品类选了拓扑，按系统定了契约，按规模与地域做了取舍。三款产品各自跑得起来，事故也能处理，容量表、成本表与合规表都填得出来。

但工作室开始同时运营三款产品、四个团队之后，新的问题出现了：

• 账号、支付、匹配三套能力，三个团队各写了一份，字段口径还不一样；
• 每次开活动，运营要找服务端改配置、发版、盯到凌晨，热更流程只存在于某个人的笔记里；
• GM 发错奖励，客服只能等程序回滚数据库，没有人能说清上一次是谁、为什么、改了哪条记录；
• 出事故时，三个团队各自看自己的指标，没有人能回答“玩家现在到底能不能登录”。

这些问题不是容量问题，也不是契约问题。它们是协作问题：当同一个能力要被多个产品复用、同一套系统要被多个团队维护、同一次变更要经过多个角色审批时，架构必须再长一次。

这一卷讨论的就是这次长大。

平台化不是把代码抽成公共库

很多团队理解的平台化，是把重复代码抽到一个仓库、发一个 SDK、建一个“中台”。结果往往是：

• 公共库版本一升级，所有产品一起炸；
• 平台团队变成需求池，产品团队排队等排期；
• 平台接口没有 SLA、没有配额、没有退出机制，调用方只能忍；
• 平台自己出故障时，没有人为它定 SLO，也没有人能替换它。

卷四给平台化下的定义更窄，也更硬：

平台化是把一项能力变成有契约、有版本、有配额、有责任人、可观测、可退出的服务，而不是把代码搬到一起。

这句话里的每一个词，都会在后面的章节里落成具体工件：契约表、版本矩阵、配额模型、值班表、SLO、弃用时间线。

治理也不是流程负担

另一个常见误解，是把架构治理等同于“加审批”。审批当然要有，但审批只是治理最表面的一层。真正起作用的治理，是让正确的做法成为默认路径：

• 新建服务时，模板已经带好了日志字段、健康检查、配额申请和发布流水线；
• 改数据模型时，适应度函数会在 CI 里拦住跨服务直连；
• 复盘之后，改进项会变成一条自动检查，而不是躺在文档里；
• 事故分级、发布门禁、GM 审批，都有明确的判定规则和留痕。

治理的目标不是让人不敢改，而是让改动可解释、可回滚、可追责。一个团队如果每次发布都要开三次会，那不是治理得好，是治理成本太高。

四卷的分工

把四卷放在一起看，它们回答的是四个层层递进的问题：

前三卷的读者主要是架构师和技术负责人；卷四的读者还要加上平台团队、SRE、运营与客服的负责人。因为这一卷讨论的很多决策，不是服务端一个团队能单独做出的。

三款产品在卷四的处境

《裂隙战场》要开跨服赛事，运营每周都要配活动，GM 每天要处理举报与补偿；《群岛纪元》进入长线运营，客服与风控团队独立成组；《泡泡工坊》轻量出海，平台能力直接复用了前两款产品沉淀下来的账号与支付。

同一套平台，要同时满足三种节奏：

• 竞技产品要快：活动当天改配置，十分钟内生效；
• MMO 要稳：一次热更不能把在线玩家踢下线；
• 轻量产品要省：没有专职 SRE，平台必须自带可观测与告警。

卷四不会给出一套“什么都能满足”的平台设计。它给出的是判断：哪些能力必须平台化，哪些应该留在产品内，哪些可以先用约定代替系统。

怎么读这一卷

• 如果你正在建平台团队，从第 1 章和第 9 章开始；
• 如果你被 LiveOps 的配置与热更折磨，从第 2 章开始；
• 如果你负责 GM、客服或风控，从第 3、4 章开始；
• 如果你在补可观测性与 SLO，从第 5、6、7 章开始；
• 如果你要做架构治理与演进，从第 8、10、12 章开始；
• 如果你只想知道全书结论，直接读第 13 章，再回到关心的章节。

每一章仍然按“问题—选项—判据—代价—可运行夹具”的顺序展开。代码不是装饰，而是把决策写成可以测试的东西：配额校验、状态机、幂等账本、告警去重、评分模型。

写作边界

这一卷不写：

• 通用微服务与服务网格教程；
• 具体 APM、工单、客服系统的产品选型；
• 组织管理与绩效；
• AI 模型训练与提示词工程。

它写的是游戏服务端语境下的平台与治理：当能力要被复用、当变更要经过多人、当事故要可复盘时，架构上到底要增加什么、放弃什么。

架构是取舍，不是清单。这句话在卷一出现过，在卷四会再出现一次，因为平台化最容易滑向“什么都想要”。读完这一卷，希望你至少能对下面这个问题给出自己的答案：

在你的团队里，哪三项能力值得平台化，哪三项应该继续留在产品内，理由是什么？