一份契约在规模面前会失效
卷二结束时，北辰工作室的三款产品各自拥有了一份看起来完整的系统契约：账号只有一个写入者，结算先落单再发奖，支付状态与发货状态分开，平台能力按租户隔离。
这些约定在小规模下成立。可当《裂隙战场》同时在线从两万涨到二十万，当《群岛纪元》的玩家分布从三个时区扩展到全球，当《泡泡工坊》的买量成本突然翻倍，同一批契约开始出现新的裂缝：
- 结算服务没有变，但每天要处理的结算单多了一个数量级，数据库连接池先撑不住了；
- 账号服务没有变，但欧洲玩家登录要跨一次大洋，延迟从 30 毫秒变成 220 毫秒；
- 平台能力没有变，但三个产品同时要资源，配额给谁、超了怎么办，没人说得清。
契约本身没有写错，是契约背后的假设变了。卷三讨论的就是这些假设：容量、地域、成本。
为什么单独成卷
规模不是一个可以“最后再优化”的维度。它会在很早的时候决定架构的形状：
| 问题 | 小规模时的答案 | 规模化后的答案 |
|---|---|---|
| 数据放哪 | 一台数据库 | 分片、读写分离、区域驻留 |
| 服务部署在哪 | 一个机房 | 多地域、多可用区、赛区 |
| 扩容怎么做 | 加机器 | 暖池、调度、排空、成本约束 |
| 合规谁负责 | 没人想过 | 实名、防沉迷、数据出境、删除权 |
| 发布怎么发 | 停服更新 | 混版本、灰度、回滚窗口 |
这些问题彼此纠缠。为了降低延迟把数据搬到玩家附近，可能违反数据驻留要求；为了省钱合并赛区，可能把跨区延迟推到不可接受；为了合规把日志留久一点，存储成本又会上一个台阶。
所以卷三不按“性能优化”“高可用”“安全”这样的技术主题组织，而按规模化过程中必然遇到的三组矛盾组织：容量与弹性、地域与状态、成本与合规。
卷三要回答的四个问题
第一个问题：这套系统到底能承载多少
“能承载多少”不是一句在线人数。它至少包括：同时房间数、每秒消息数、登录与匹配的峰值速率、单房间的 tick 预算、世界扫描的耗时。卷一给过质量属性，卷二给过系统契约，卷三要把它们换算成容量表和扩容触发线。
第 1 章会给出承载指标的拆法、压测的真实度分级，以及容量模型与余量的算法。这里的核心立场是：没有余量结构的容量数字没有意义，因为故障一定会发生在你最没有余量的那一刻。
第二个问题：玩家在全球时，状态放在哪里
第 3 章讨论延迟预算、数据驻留与全球同服的状态归属；第 4 章讨论分片键与再均衡；第 7 章讨论跨服与合服。三章合起来回答一个问题：当玩家、数据和服务分散在不同地域时，谁拥有写权限、允许旧多久、迁移时怎么不断服。
这个问题没有通用答案。《裂隙战场》可以把一局比赛整体放到一个赛区；《群岛纪元》的全球单世界必须接受跨区读写和更长的可见性窗口；《泡泡工坊》则可能根本不需要多地域。卷三给的是判据和代价，不是统一方案。
第三个问题：怎么在成本约束下守住体验
第 9 章把成本拆成可归因的单位经济，讨论配额、混部与超卖；第 12 章用三款产品演示不同的成本底线。这里的核心立场是：成本不是财务问题，是架构问题。tick 频率、日志采样率、回放保留期、区域数量，每一个都是架构决策，都会在账单上体现。
第四个问题：监管要求落在哪一层
第 10 章讨论版号、实名、防沉迷、数据出境、删除权与日志留存。这些要求不能靠“合规团队最后检查”解决，必须落到登录、支付、数据模型和删除链路上。卷三只谈工程落点，不提供法律意见；具体期限与适用范围必须由法务确认。
与《MMO 服务器开发》的分工
《MMO 服务器开发》回答“怎么把一套 MMO 服务端做出来”：网络库、AOI、战斗、技能、副本、任务。卷三回答“当它要服务更多玩家、更多地区、更紧的预算时，架构该怎么调整”。
因此卷三不会重写 AOI 的实现，也不会教你怎么写消息队列。涉及实现细节时，用链接指向《MMO 服务器开发》的相应章节；卷三只讨论选择、边界与失败模式。
三款产品在规模化阶段暴露的矛盾
| 产品 | 规模化阶段的主要矛盾 | 卷三的重点章节 |
|---|---|---|
| 《裂隙战场》 | 赛区数量与低峰利用率、跨区匹配的公平性 | 第 3、7、12 章 |
| 《群岛纪元》 | 全球单世界的状态归属、联盟跨时区协作 | 第 3、4、12 章 |
| 《泡泡工坊》 | 买量波动带来的弹性、轻量出海的成本底线 | 第 2、9、12 章 |
同一个决策在三款产品上的答案不同。比如“要不要多地域部署”：竞技产品为了延迟必须多赛区，SLG 为了全球同服必须接受跨区，休闲产品在没有足够用户密度时多地域只会推高固定成本。
本书的组织方式
卷三仍然是 13 章、39 节正文，加序、前言、目录和三个附录。每节的结构与卷二一致：场景与约束、备选方案、选定方案、契约或状态机、失败模式、可运行片段、小结与常见错误。
可运行片段继续放在 gsarch-lab 验证工程中，使用 Go 1.26.0 与标准库。卷三新增的包偏向“规模决策的夹具”：容量估算、暖池水位、分片迁移、灰度判定。它们不是生产代码，而是把决策写成可检查的形式。
附录 A 是容量估算表，附录 B 是合规检查表，附录 C 是全球化部署清单。三份表都可以直接拿去改，改成自己产品的参数。
阅读建议
- 服务端工程师：按顺序读，重点跑第 1、4、5、6 章的代码，理解容量、迁移和异步的真实边界。
- 技术负责人：先读第 1、3、9、13 章，再读附录 A 与 C；重点判断团队的容量表、成本表和合规表是否真的存在。
- 平台团队：读第 2、7、11 章，关注调度、跨服与发布边界；这些能力最终会沉淀到平台。
- 产品与运营：读第 9、12 章即可，理解成本与体验的取舍，以及为什么某些“加个功能”会让账单跳一级。
本书不做什么
- 不提供云厂商选型建议与报价；
- 不解读具体法律法规，不替代法务意见；
- 不声称做过真实的跨机房切换或全球压测；
- 不把设计推演说成本机验证。
在这些边界之内，卷三会把规模化过程中的取舍讲透：哪些数字必须自己测，哪些余量必须留，哪些成本必须提前算，哪些合规要求必须写进架构而不是写在文档里。
规模不是把系统放大，而是让系统在更大的不确定性下仍然可解释。这是卷三想交给读者的东西。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。