《游戏服务端架构·平台化与架构治理》前言：治理怎么写成可执行的动作

治理的最小可执行单位

“加强架构治理”是一句正确但无法执行的话。把它拆到可以执行，至少要回答五个问题：

1. 谁：哪个角色发起、哪个角色审批、哪个角色执行、哪个角色复核；
2. 什么状态：这件事在哪个状态机里流转，当前状态允许哪些动作；
3. 阈值：什么条件下允许、什么条件下阻断、什么条件下升级；
4. 证据：做完之后留下什么记录，事后凭什么判断它对不对；
5. 回滚：做错了怎么退回去，退回哪一步，谁来确认。

卷四的每一节，都尽量把这五项写全。写不全的地方，会明确说“这里只能靠约定，暂时没有系统强制”。

五个贯穿全卷的可运行夹具

和前几卷一样，卷四的代码不是示例片段，而是可以单独跑测试的小包。它们分布在 .local/checks/gsarch-lab 中，按章节组织：

每个包都只依赖 Go 标准库，测试用表驱动写法。书中的代码块与仓库源码逐字节一致，读者可以只复制一个包出来跑。

一条治理规则长什么样

以“跨服务不得直连他人数据库”为例，一条可执行的规则至少要写清四件事：

rule: no-cross-service-database-access
scope: internal/**
owner: platform-team
check: import-graph
severity: block
exceptions:
  - path: internal/legacy/report
    owner: data-team
    expires: 2027-03-31
evidence: ci-report.json

它和一句“禁止跨服务直连数据库”的区别在于：

• scope 明确了检查范围；
• check 明确了用什么手段检查；
• exceptions 让例外有 owner 和过期时间；
• evidence 说明违规时留下什么证据。

第 8.3 节会把这类规则做成一个小型规则引擎，第 10 章会讨论规则如何随架构演进调整。

平台化的基线

卷四假设前三卷的成果已经存在：

• 三款产品各有明确的拓扑与状态归属；
• 账号、支付、匹配、经济、社交的核心契约已经定下；
• 容量表、成本表与合规表已经能填；
• 有基本的日志、指标与告警，但未必有 SLO。

在这个基线上，卷四讨论的是“如何复用、如何协作、如何长期维护”。如果读者所在的项目还没有完成前三卷的工作，卷四的很多讨论会显得超前；建议先补拓扑与契约，再回到本卷。

三款产品的平台化起点

为了避免抽象讨论，卷四继续使用北辰工作室的三款产品：

同一个平台决策，在这三款产品上的答案可能不同。卷四会尽量把“为什么不同”写出来，而不是给一个看似通用的最佳实践。

阅读约定

• 章节编号从 1.1 到 13.3，序、前言、目录与附录不参与编号；
• 每节末尾的阅读导航只指向本卷相邻小节，最后一节指回目录；
• 正文中的站内链接一律使用 relref，不手写 URL；
• 代码块首行的 // file: 指向 .local/checks/gsarch-lab 中的真实文件；
• 附录 A 是可复制的治理模板，附录 B 是上线检查清单，附录 C 是全书案例索引。

一个提醒

平台与治理很容易变成“正确但无效”的工作：文档写得很全，评审开得很勤，事故还是照样发生。判断治理是否有效，不看文档数量，而看三个信号：

1. 新成员能否在不问人的情况下完成一次合规发布；
2. 事故复盘后的改进项，有多少变成了自动检查；
3. 平台变更能否在不通知所有产品的情况下安全上线。

如果这三个信号没有改善，说明治理还停留在流程层。卷四的目标，是把它往下推到系统层。