《游戏服务端架构·品类、状态与拓扑》5.3 会话、重连、顶号与连接迁移
顶号、地铁断网和跨网关迁移看起来是三件事，底层却是同一条会话状态机。本节用 epoch 作为 fencing token，定义 CONNECTED 到 CLOSED 的合法迁移、重连窗口与幂等恢复，并给出顶号踢旧连接、迁移后拒绝旧连接写入、重复 resume 不重复提升 epoch 的可运行实现。
tag
架构设计
共 278 篇文章。
《游戏服务端架构·品类、状态与拓扑》5.1 长连接、短连接、WebSocket 与 QUIC 的取舍
《裂隙战场》《群岛纪元》《泡泡工坊》对延迟、推送与运维的要求完全不同。本节把短连接、长轮询、WebSocket 与 QUIC 放进同一张选型矩阵，给出硬约束筛选、加权打分、握手与重连预算，并说明团队只有两人或延迟要求宽松时，为什么不该自建长连接。
《游戏服务端架构·品类、状态与拓扑》4.3 离线推进与时间旅行：SLG 的补算
以《群岛纪元》离线收益与建筑完成为例，说明补算为什么必须有上限、按天重置并与在线结算对账；给出按小时产出、每日封顶且按时区分日的 Go Accrue 实现，覆盖正常补算、封顶、时钟回拨与跨天重置四类测试，并给出离线补算与在线结算的幂等对账流程。
《游戏服务端架构·品类、状态与拓扑》4.2 tick、帧预算与世界时钟
从《裂隙战场》一次 500ms 停顿后技能连放讲起，说明固定步长 tick 为什么不能直接跟着墙上时间跑；给出带 CatchUp 上限、丢弃计数、漂移余量和时钟回拨保护的 Go Loop 实现，覆盖正常推进、大延迟补帧、超限丢弃与回拨四类测试，并与第 1 章 33ms/16ms 的帧预算口径对齐。
《游戏服务端架构·品类、状态与拓扑》4.1 内存态、持久态与快照
从《群岛纪元》一次重启后世界倒退两小时讲起，分清内存态、持久态与快照各自的权威边界，说明快照为什么只是恢复加速器而不是备份；给出带 schema 版本号与 CRC32 校验和的 Go 编解码与恢复实现，覆盖正常恢复、版本不兼容、校验损坏与空快照，并用频率成本表说明多久快照一次才划算。
《游戏服务端架构·品类、状态与拓扑》3.3 分区、分服与全球同服
《群岛纪元》出海后，欧洲玩家的一支舰队跨到亚洲赛区，280ms 延迟让联盟战结果失去说服力；合规审计又要求欧洲玩家数据不得离开本地。本节对比分区、分服与全球同服三种形态，用按赛区与地图范围路由的 Go 实现和再均衡计划，说明拓扑为什么会被数据驻留反向约束。
《游戏服务端架构·品类、状态与拓扑》3.2 大厅、房间与战斗：竞技品类的标准形态
《裂隙战场》的一次网络重试让同一名玩家占了两间房，崩溃客户端又留下 1400 间无人释放的幽灵房间。本节把竞技品类拆成无状态大厅、有状态房间与分配器三层，用带暖池、容量上限、租约过期和重复分配防护的 Go 实现，说明分配器能防住哪些幽灵，哪些必须由房间心跳兜底。
《游戏服务端架构·品类、状态与拓扑》3.1 单体、分层与模块化单体
《泡泡工坊》三个人的团队把登录、房间、经济和结算写进一个 main 包，第十八个月的一次促销结算拖垮了全部在线。本节把模块化单体拆成 auth、room、economy、settlement、ops 五个模块，用允许依赖表、依赖校验与三色环检测把边界变成 CI 门禁，并给出五条可量化的拆分触发条件。
《游戏服务端架构·品类、状态与拓扑》2.3 一次真实的架构评审与风险台账
《群岛纪元》全球同服方案评审只给了团队四十八小时。本节还原评审桌上的三个争议，建立包含概率、影响、分值、负责人、触发信号与缓解动作的风险台账，区分“接受的风险”和“被卡住的决策”，并用 Go 代码实现评分、排序与 Top N，引用 ADR-005、ADR-006、ADR-007 说明每个风险对应的架构决定。
《游戏服务端架构·品类、状态与拓扑》2.2 ADR：把决策、备选与后果写下来
一次关于《群岛纪元》匹配状态归属的评审吵了四十分钟没有结论，因为没人写下备选与后果。本节给出 ADR 的最小结构：背景、备选、决定、后果、退出条件与状态；用 ADR-005 匹配状态归属、ADR-006 结算幂等、ADR-007 全球同服时间模型三份真实记录示范被否决的备选和退出条件，并用 Go 校验器拒绝缺少退出条件的 ADR。
《游戏服务端架构·品类、状态与拓扑》2.1 质量属性与无法回避的取舍
北辰工作室把“低延迟、强一致、低成本、快迭代”全写成 P0，评审直接卡住。本节用来源、刺激、制品、环境、响应、度量六要素，为《裂隙战场》《群岛纪元》《泡泡工坊》各写四条可测质量属性场景，做一张延迟、一致性、成本与可修改性的取舍矩阵，并用 Go 代码校验场景完整性、统计覆盖缺口，最后说明为什么没有架构能同时满足全部属性。
《游戏服务端架构·品类、状态与拓扑》1.3 品类如何决定拓扑：北辰三款产品
用北辰工作室三款产品对照五种服务端拓扑：模块化单体、大厅加房间、分区世界、全球同服与专用服池；把并发、会话时长、实时性、共享世界、匹配制与地域敏感六个产品事实写成可执行的选型函数，说明为什么拓扑只是第一版决策，并给出三份 ADR 的退出条件。
《游戏服务端架构·品类、状态与拓扑》1.2 三类延迟预算：帧、操作、结算
把“低延迟”拆成帧预算、操作预算与结算预算三类互不等价的时间尺度，给出从端到端目标反推排队、处理、持久化与网络分段的预算表，并用 Go 代码把预算检查、分位数统计与超限报告变成可执行约束，最后对比北辰三款产品的预算矩阵，强调长尾而不是平均值。
《游戏服务端架构·品类、状态与拓扑》1.1 游戏服务端到底在为谁做架构
从北辰工作室三款产品在一次周五晚高峰同时出问题讲起，拆开游戏服务端真正服务的三类对象：玩家、运营与团队；说明有状态、强实时、长会话、玩法耦合四个特殊性如何把普通后端经验推到边界之外，再用房间状态机与状态所有权表落下第一组可验证约束，并给出第一份 ADR。
《游戏服务端架构·品类、状态与拓扑》目录与学习路径
《游戏服务端架构》卷一《品类、状态与拓扑》全 45 篇的阅读入口：说明本卷要解决的四个问题、十三章结构、北辰三款产品的贯穿案例、序/前言/附录与三条阅读路径，并给出 L1/L2/L3 可运行性口径和 39 篇正文的完整目录。
《游戏服务端架构·品类、状态与拓扑》前言：技术选型、案例与可运行性口径
本篇交代卷一的技术基线、案例构造方式、代码组织与 L1/L2/L3 可运行性口径，说明哪些数字是示例值、哪些是本机实测，以及三款虚构产品为什么要这样设计；同时给出按角色阅读的路径和代码复现方法，便于读者判断每一条结论的证据强度。
《游戏服务端架构·品类、状态与拓扑》序：为什么还要写一套游戏服务端架构书
站内已经有一套从零实现 MMO 服务端的书，为什么还要再写一套架构书？这篇序说明两者的分工：前者回答怎么实现，后者回答为什么这样选、代价是什么；并交代本书的品类视角、北辰三款产品的贯穿案例、四卷结构与对代码和数字的诚实承诺。
《游戏服务端架构·品类、状态与拓扑》 · 全书目录与章节索引（45 篇）
《游戏服务端架构》卷一全 45 篇：以品类、状态、时间、连接、权威五个变量为主线，对照北辰工作室三款产品，从拓扑选择写到部署单元与架构基线；含序、前言、目录、附录 A–C、四条阅读路径与可运行性口径，每节附可检查的 Go 夹具或决策表，便于评审时直接对照。
《Go 语言编程入门》18.1 需求梳理与架构设计
对 TaskAPI 做一次完整复盘：从用户故事与非功能需求出发，梳理分层架构、包边界与 HTTP 契约，回顾从第 1 章到第 17 章的演进轨迹，并逐条复盘关键架构取舍——接口抽象的判据、内存到数据库的平滑迁移、错误分层与并发安全，最后列出收口清单。
韧性工程与错误预算：从 SLO 到故障演练
韧性工程（Resilience Engineering）的落地方法：SLI/SLO/SLA 的关系与错误预算计算、多窗口多燃烧率告警、发布门禁与预算冻结策略、预算消耗归因、混沌工程与游戏日演练流程、超时/重试/熔断/隔离舱等韧性模式与降级兜底设计，以及度量与组织配套。