为什么规模决策需要可验证的形式
容量、地域与成本这三类问题有一个共同点：结论很容易被说得很像对的。
“这套架构能扛五十万在线”“我们把服务器放到玩家附近了”“改成异步之后成本降了三成”——这些话在评审会上听起来合理，但经不起追问：五十万在线的口径是什么？放到附近之后跨区读写怎么办？三成是哪个成本项、相比哪个基线？
卷三的写作约束因此比前两卷更强调“可算”。每一节至少要把结论落成一种可检查的形式：容量模型、状态机、路由规则、评分矩阵或对账表。文字解释判断依据，产物负责让判断可以被别人复算一遍。
技术基线
卷三继续以 Go 1.26.0 与标准库为可运行代码的基线。理由与前两卷相同：单包可编译、无框架依赖、代码可以直接嵌进文章。
| 组件 | 版本口径 | 用途 |
|---|---|---|
| Go | 1.26.0 | 全部可运行代码 |
| Docker | 29.5.2 | 本地容器能力（本机已确认） |
| PostgreSQL | 17-alpine（Docker） | 讨论分片、迁移时的参考依赖 |
| Hugo | 0.163.3+extended | 站点构建，与读者无关 |
卷三不依赖 Kubernetes。本机没有安装 K8s，书中涉及调度、暖池、混部的内容一律用状态机与约束模型表达，不声称在 K8s 上实跑。涉及真实机房的延迟、故障切换与全球压测，只写设计推演与验收口径。
案例的侧重点
卷一比较三种品类的拓扑，卷二把核心系统逐个拆开，卷三则让三款产品进入“规模阶段”：
| 产品 | 规模化阶段的主要压力 | 卷三观察的决策 |
|---|---|---|
| 《裂隙战场》 | 赛区变多、低峰利用率下降、跨区匹配 | 赛区划分、延迟预算、暖池与排空 |
| 《群岛纪元》 | 全球单世界、联盟跨时区、状态归属 | 分片键、跨区读写、迁移与合服 |
| 《泡泡工坊》 | 买量波动、轻量出海、成本敏感 | 弹性、单位经济、区域收敛 |
同一组原则在三款产品上得出不同答案，这个差异本身就是卷三最重要的内容。书中不会给出“最佳实践”，只会给出“在这个约束下，为什么选它，代价是什么”。
代码怎么组织
卷三的所有片段继续放在 gsarch-lab 验证工程中，代码块带三类标记：
// file: internal/account/model.go
// tier: L1
// verify: go test ./internal/account/
package account
file：代码在验证工程中的路径；tier：可运行级别；verify：作者实际执行过的验证命令。
文章与工程中的同一段代码保持逐字节一致。卷三新增的包按章划分：
| 章 | 主题 | 验证包 |
|---|---|---|
| 1 | 容量与压测 | internal/capacitymetrics、internal/botloadgen、internal/capacitymodel |
| 2 | 弹性与调度 | internal/dedicatedsched、internal/warmpool、internal/scalein |
| 3 | 多地域与全球同服 | internal/latencybudget、internal/dataregion、internal/globalstate |
| 4 | 数据分片与再均衡 | internal/shardkey、internal/consistenthash、internal/rebalance |
| 5 | 缓存与读写分离 | internal/multicache、internal/hotkeyguard、internal/rwvisibility |
| 6 | 消息与异步 | internal/queuecontract、internal/backlogorder、internal/reconjobs |
| 7 | 跨服与跨区 | internal/crossmatch、internal/crosssettle、internal/mergemigration |
| 8 | 容灾与多活 | internal/backupdrill、internal/failoverplan、internal/statedr |
| 9 | 成本架构 | internal/costattribution、internal/resourcequota、internal/costexperience |
| 10 | 合规与数据治理 | internal/compliancerules、internal/privacydeletion、internal/auditretention |
| 11 | 发布与灰度 | internal/statefulrelease、internal/compatwindow、internal/rollbackcanary |
| 12 | 全球化案例 | internal/riftregion、internal/archglobal、internal/bubbleglobal |
| 13 | 卷三收口 | internal/capacitytable、internal/globalmatrix、internal/volfourhandoff |
这些包是决策夹具：把容量公式、迁移状态、灰度判据固定成可测试的代码。真实系统还需要真实的监控数据、压测环境和运维流程，那些不在本书的承诺范围内。
可运行性分级
卷三继续使用四级标注：
| 级别 | 判定 | 验收方式 | 能证明什么 |
|---|---|---|---|
| L1 | 纯逻辑或单包，不依赖外部进程 | gofmt -l 无输出、go vet、go test | 容量公式、状态机、评分规则正确 |
| L2 | 进程内端到端，内存适配器或本地端口 | 脚本完成主流程并断言结果 | 跨模块的扩容/迁移流程能跑通 |
| L3 | 真实依赖，Docker Compose 启动 | 固定场景脚本 + 日志/指标 | 分片迁移、对账在真实存储下成立 |
| L4 | 多节点、网络分区、故障注入 | 独立实验环境 | 切换、脑裂、跨区假设在故障下成立 |
卷三承诺到 L1；涉及数据库迁移、跨区同步与故障切换的场景，会写清 L3/L4 应该验证什么、验收标准是什么，但不声称已经跑过。凡是写“本机实测”的地方，必须附命令、退出码与输出文件。
数字的口径
卷三沿用前两卷的三分法，并额外强调一点：
- 示例值：用于说明数量级或取舍关系，例如“单赛区峰值 3 万房间”“暖池水位 10%”。
- 设计目标：团队承诺的预算，例如“扩容到可用状态不超过 90 秒”。
- 本机实测：有命令、环境和输出，只对当时的软硬件成立。
规模类数字尤其容易被误读。书中所有容量、成本、延迟数字如果没有标注，默认都是示例值；读者必须用自己产品的监控数据替换。云厂商报价、渠道费率、法定留存期限这类外部参数，书中只给结构与量级，不给“行业标准值”。
按角色阅读
服务端工程师：按第 1–13 章顺序读，重点跑第 1、4、5、6 章的代码，理解容量、迁移、缓存与异步的边界。
技术负责人/架构师：先读第 1、3、9、13 章，再读附录 A 与附录 C。重点检查团队是否真的能回答“容量多少、余量在哪、成本怎么算”。
平台团队：重点读第 2、7、11 章与附录 C。调度、跨服、发布这些能力最终会收敛到平台。
产品/运营：读第 9、12 章即可，理解成本结构与区域选择的约束，避免把“加一个玩法”当成纯功能需求。
如何复现书中的验证
# 进入验证工程
cd gsarch-lab
# 格式、静态检查与全部测试
gofmt -l .
go vet ./...
go test ./...
# 只跑某一章对应的包
go test ./internal/capacitymodel/ ./internal/warmpool/
如果你的 Go 版本高于 1.26.0，绝大多数 L1 代码应当照常工作；出现差异时以本机错误信息为准。
本书不做什么
- 不提供云厂商选型与报价，不评价具体厂商；
- 不解读法律法规，合规内容只谈工程落点；
- 不声称做过全球压测、真实机房切换或大规模故障注入；
- 不把设计推演写成实测结论；
- 不重复《MMO 服务器开发》的实现细节。
阅读入口：《游戏服务端架构·规模化、全球化与成本》目录与学习路径 。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。