为什么单独写一篇前言
卷二讨论的是系统之间的约定：谁拥有数据、谁可以写、失败时谁兜底、重复执行会怎样。这些内容很容易写成一段看起来正确的文字，却很难被验证。
所以卷二在写作上做了一个约束：每一个系统契约，至少要落成一种可检查的产物——状态机、表驱动测试、权限矩阵、对账规则或 SLA 计算。文字负责解释，产物负责让约定有牙齿。
本篇交代这些产物是怎么组织的、验证到哪一级、数字是什么口径。读者可以据此判断：哪一条结论可以直接搬进评审材料，哪一条必须先替换成自己产品的参数。
技术基线
卷二的可运行代码继续以 Go 1.26.0 为基线。选择它的理由与卷一相同：标准库足够表达状态机、并发和超时；单包即可编译测试；代码可以直接嵌进文章而不依赖框架。
| 组件 | 版本口径 | 用途 |
|---|---|---|
| Go | 1.26.0 | 全部可运行代码 |
| PostgreSQL | 17-alpine（Docker） | L3 账本、唯一约束验证 |
| Redis | 7.x（Docker，可选） | 会话、榜单、限流场景 |
| Hugo | 0.163.3+extended | 站点构建，与读者无关 |
卷二不接真实支付渠道，也不依赖 Kubernetes。涉及渠道、实名、防沉迷的内容，一律用接口桩和规则表表示；涉及多地域、故障注入的内容，只写设计推演，不声称本机跑过。
案例的侧重点
卷一让三款产品各自承载一种主要矛盾：竞技承载实时与公平，SLG 承载持久与大世界，休闲承载速度与成本。卷二沿用同一组产品，但把镜头拉近到系统层：
| 产品 | 卷二重点观察的系统 |
|---|---|
| 《裂隙战场》 | 登录重连、匹配、房间生命周期、战斗结算、赛季榜单 |
| 《群岛纪元》 | 渠道账号、跨区分片、异步战报、资源账本、联盟与王战 |
| 《泡泡工坊》 | 游客账号、轻量登录、快速开局、邮件补偿、小额支付 |
同一个系统在三款产品里的契约强度不同。比如结算：竞技要求实时、可回放、可改判；SLG 允许异步，但必须可补算、可对账；休闲可以简单，但不能阻塞登录。卷二不会给出一套“通用结算服务”，而是给出判断契约强度的依据。
代码怎么组织
卷二的所有片段继续放在 gsarch-lab 验证工程中，代码块带三类标记：
// file: internal/account/model.go
// tier: L1
// verify: go test ./internal/account/
package account
file：代码在验证工程中的路径；tier：可运行级别；verify：作者实际执行过的验证命令。
文章与工程中的同一段代码保持逐字节一致。卷二新增的包按章划分：
| 章 | 主题 | 验证包 |
|---|---|---|
| 1 | 账号与身份 | internal/account、internal/identitylink、internal/accountrisk |
| 2 | 登录与网关 | internal/loginticket、internal/gwroute、internal/loginqueue |
| 3 | 匹配与房间 | internal/matchmaking、internal/roomlifecycle、internal/instancepool |
| 4 | 场景与世界 | internal/aoiindex、internal/worldline、internal/globalevent |
| 5 | 战斗与结算 | internal/battlemodels、internal/settlecontract、internal/battleaudit |
| 6 | 经济与交易 | internal/currencyledger、internal/tradeescrow、internal/economyrisk |
| 7 | 成长与任务 | internal/growthfsm、internal/questprogress、internal/dailyreset |
| 8 | 社交与公会 | internal/relationships、internal/guildvault、internal/chatmod |
| 9 | 排行榜与赛季 | internal/rankmodel、internal/rankbuffer、internal/rankread |
| 10 | 邮件与奖励 | internal/maildelivery、internal/mailattachment、internal/mailclaim |
| 11 | 支付与合规 | internal/paydelivery、internal/refundrecon、internal/compliance |
| 12 | 平台服务化 | internal/platformcore、internal/tenantisolation、internal/platformsla |
| 13 | 卷二收口 | internal/contractmatrix、internal/ownershipmap、internal/releaseready |
这些包不是可直接上线的服务，而是契约夹具：用尽量少的代码把“谁可以写”“重复执行会怎样”“越权时拒绝什么”固定下来。产品代码还需要协议、持久化、监控和压测，那些不在本书的承诺范围内。
可运行性分级
卷二仍然使用四级标注，但 L1 的比重更高，因为系统契约大多是纯逻辑：
| 级别 | 判定 | 验收方式 | 能证明什么 |
|---|---|---|---|
| L1 | 纯逻辑或单包，不依赖外部进程 | gofmt -l 无输出、go vet、go test | 状态机、幂等键、权限与配额逻辑正确 |
| L2 | 进程内端到端，内存适配器或本地端口 | 脚本完成主流程并断言结果 | 跨模块契约能跑通 |
| L3 | 真实依赖，Docker Compose 启动 | 固定场景脚本 + 日志/指标 | 唯一约束、事务、并发在真实依赖下成立 |
| L4 | 多节点、网络分区、故障注入 | 独立实验环境 | 分布式假设在故障下成立 |
卷二承诺到 L1；涉及账本唯一约束、支付回调等场景，会在 L3 口径下讨论应该验证什么，但不声称已经跑过。凡是写“本机实测”的地方，必须附命令、退出码和输出文件。
数字的口径
卷二延续卷一的分类：
- 示例值：说明数量级或取舍关系，例如“单区峰值登录 5 万/分钟”“渠道回调重试间隔 30 秒”。
- 设计目标：团队承诺的预算，例如“发奖接口 P99 小于 200ms”。
- 本机实测：有命令、环境和输出，只对当时的软硬件成立。
支付费率、渠道超时、合规时长这类外部参数，书中只给量级和结构，不给“行业标准值”。真实项目必须以渠道文档和法务意见为准。
按角色阅读
服务端工程师：按第 1–13 章顺序读，重点关注每节的状态机、幂等键和失败模式表；代码可以直接在 gsarch-lab 里改参数、跑测试。
技术负责人/架构师：先读第 1、5、6、11、12、13 章，再读附录 B 的系统契约模板和附录 C 的故障模式清单。重点检查团队是否写清了数据所有权和失败责任。
平台团队：重点读第 2、11、12 章与附录 A。平台能力收放的判据、租户隔离和 SLA 契约集中在这里。
产品/运营：读第 5、6、9、10、11 章的“约束与代价”部分即可，不必看代码。补偿、退款、赛季结算这些承诺，在服务端都有对应的状态机和时限。
如何复现书中的验证
# 进入验证工程
cd gsarch-lab
# 格式、静态检查与全部测试
gofmt -l .
go vet ./...
go test ./...
# 只跑某一章对应的包
go test ./internal/settlecontract/ ./internal/currencyledger/
如果你的 Go 版本高于 1.26.0，绝大多数 L1 代码应当照常工作；出现差异时以本机错误信息为准，不要为了迁就书中的写法而降级。
本书不做什么
- 不教 Go 语法、SQL、消息队列或 Kubernetes 的基础；
- 不提供可直接上线的账号、支付、结算服务；
- 不评价具体渠道、云厂商或开源中间件的优劣；
- 不接真实支付渠道，不写真实商户号、密钥和证书；
- 不把设计推演说成本机验证。
在这些边界之内，卷二会尽量把每个系统的约定讲透：谁拥有数据、失败怎么表现、重复执行会怎样、什么时候应该重新划分边界。
阅读入口：《游戏服务端架构·核心系统与契约》目录与学习路径 。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。