posts

游戏服务器端专题导航:从 300 篇架构笔记到 Skynet、Pitaya 与工程实战

这是 content/posts/game/server 这棵树的入口导航。它本身不放文章,而是把 300 篇后代内容按三条主线重新编排:170 篇实战工程笔记、20 篇 Skynet 与 Pitaya 框架笔记,以及 2021 年 2 月到 12 月共 110 篇月度架构笔记。每一节都给出子专题 section 入口、覆盖主题与适用场景,帮助后端同学按「框架选型、工程落地、单点问题」三种路径快速定位,而不是在时间线里逐篇翻。

这个目录是「在线游戏服务端」这一主题的总入口。它自己不存放文章,而是作为容器,把 300 篇后代内容按三条主线归拢:一是 170 篇实战工程笔记,覆盖从登录鉴权、房间调度、战斗结算到运维排障的完整链路;二是 20 篇框架笔记,聚焦 Skynet 与 Pitaya 两个 Lua 系服务端框架;三是 2021 年 2 月到 12 月共 110 篇月度架构笔记,每篇都从「一个看似边缘的功能为什么会触到核心状态」讲起。它适合正在做游戏后端的技术负责人、准备从单体服走向分布式的中级工程师,以及需要给团队定架构规范的主程。

使用方式:先看下面的速览确定自己处在哪个阶段,再按「工程实践、框架、月度笔记」三条入口跳转。工程实践适合边做边查,框架适合选型期通读,月度笔记适合按时间顺序补齐对某一类系统(奖励、匹配、背包、活动、同步)的完整认知。所有子专题都在同一棵树内,不涉及跨站跳转。

专题速览

项目内容
本目录直接文章0 篇,纯容器目录
后代文章合计300 篇
子专题数14 个(3 个工程与框架专题 + 11 个月度专题)
时间跨度2021-02 至 2021-12,覆盖长线手游服务端从立项到稳定运营的完整周期
内容形态问题驱动型架构笔记,先讲清一个真实事故或边界,再给数据模型、状态机与取舍
覆盖方向登录与网关、匹配与排队、房间与副本、战斗结算、背包与交易、活动与运营、跨服与合区、观测与排障
适用读者游戏后端工程师、服务端主程、技术负责人,以及从 Web 后端转入游戏行业的同学
阅读方式工程实践按需查,框架专题选型期通读,月度笔记按主题串读
关联技术栈Lua 系框架(Skynet、Pitaya)为主,工程实践部分也覆盖通用分布式与数据层议题
维护方式新增文章只补对应子专题,本页仅维护子专题入口与月度关键词,不逐篇罗列
与其他专题的关系上游是游戏专题总览,下游是 14 个子专题;跨领域的客户端与设计问题请走各自专题
使用提示本页不收录文章正文,若发现链接失效,应回到对应子专题核对 slug 是否变更

工程实践与框架

这一组是「怎么把服务端做出来」的三块地基。实战工程专题体量最大,回答的是真实项目里反复出现的工程问题;Skynet 与 Pitaya 两个专题则分别对应「轻量 Actor 框架」和「面向全球服的分布式框架」两条技术路线,适合在选型或迁移时对照阅读。

子专题规模一句话核心内容
游戏服务器实战工程170 篇从登录、网关、匹配、房间到背包、活动、运维的全链路工程笔记,是这棵树里最厚的一层
Skynet 服务端框架17 篇围绕 Actor 模型、消息调度、服务编排与热更,讲清 Skynet 在长线项目里的用法与边界
Pitaya 分布式框架3 篇面向多区服与全球同服的分布式框架笔记,覆盖路由、会话与集群扩展的基本形态

2021 年月度架构笔记

这 11 个月度专题是同一写作计划的连续产物,每月 10 篇,合计 110 篇。它们不按系统分类,而是按时间推进,读起来像一份「服务端架构问题年表」:从 2 月的奖励与匹配,到 12 月的货币托管与 RPC 预算,几乎每个月都对应一类线上争议的收敛过程。想补齐某个系统的完整视角,可以按月读;想快速定位,用下面的关键词列。

月份专题篇数主题关键词
2021 年 2 月10 篇首胜奖励、伤害统计、表情广播、宠物成长、家园拜访、PVP 隐藏分、职业配额匹配、传送门、UGC 地图、分线切换
2021 年 3 月10 篇拍卖冻结、战斗观测快照、命令回执、跨服排队令牌、活动脚本预算、道具堆叠、改名索引、剧情触发、组队重连、资源刷新调度
2021 年 4 月10 篇防沉迷时长、外观组合、结算校验流水线、人机隔离、跨场景聊天、公会权限、掉落表版本、地图标记订阅、体力时钟、新手检查点
2021 年 5 月10 篇战斗观测采样、跨服报名、坐骑同步、NPC 对话状态、语音令牌、玩家设置同步、奖励预览契约、场景门禁、赛季补发、临时属性快照
2021 年 6 月10 篇权威随机抽取、玩法日历、公会贡献账本、实例暖池、道具绑定、匹配准备共识、在线状态对账、称号读模型、任务事件背压、投降投票
2021 年 7 月10 篇战斗旁路计算、补丁门控、GM 双人审批、库存预占、活动状态审计、队伍跨场景跟随、命令日志压缩、热对象拆分、会话票据续期、对象租约
2021 年 8 月10 篇技能效果流水线、批量领奖、副本进度恢复、好友邀请一致性、通知优先级、排行榜写缓冲、实时指令整形、分片缓存协同、空间事件索引、分区交接
2021 年 9 月10 篇账号变更串行化、回放确定性、输入仲裁、配置灰度护栏、实例调度约束、维护排水、消息乱序缓冲、运营熔断、房间快照归档、状态校验和对账
2021 年 10 月10 篇成就触发聚合、Boss 仇恨表、协作解谜状态机、外观装配校验、网关连接排空、战争迷雾可见性、匹配处罚、制作流水线、配装锁定、世界天气控制面
2021 年 11 月10 篇战场目标计分、客户端能力协商、伙伴指令归属、跨模式成长归一、调试命令沙箱、转服预检、私密房邀请令牌、PVE AI 导演、场景物件持久化、社交隐私
2021 年 12 月10 篇跨分片邮件路由、货币预占托管、实体兴趣订阅、公会战报名锁定、NPC 刷新租约、举报证据流水线、副本锁定存档、RPC 超时预算、赛季商店库存、技能打断

如何选择入口

推荐阅读路径

路径一 技术负责人:先定架构分层与选型

先读工程实践专题里的网关、会话与分布式调度相关篇目,明确长连接、房间进程与数据层各自的责任边界;再对照 Skynet 与 Pitaya 两个框架专题,判断团队应该自研轻量 Actor 框架还是直接采用分布式框架;最后用 2021 年 9 月的实例调度约束、维护排水与运营熔断三篇,把「上线之后怎么安全变更」这件事在设计期就留出接口。

路径二 业务后端:按系统补齐完整视角

如果你正在做奖励、背包或交易,先读 2 月首胜奖励、3 月拍卖冻结、6 月道具绑定与 7 月库存预占,再补 12 月货币预占托管,可以拿到一条从「单次发奖」到「跨系统资产一致」的完整链路;如果你在做匹配与对局,从 2 月职业配额匹配、6 月准备确认、10 月匹配处罚读到 12 月公会战报名锁定,基本覆盖竞技系统的全部争议点。

路径三 排障与运维:从观测到止血

先读 3 月战斗观测快照、9 月房间快照归档与状态校验和对账,理解「事后能不能解释一局」需要哪些事实层;再读 9 月运营熔断开关与 10 月网关连接排空,掌握出事时的止血顺序;最后用 12 月的 RPC 超时预算把跨服务调用的治理口径固定下来。

相关专题

全部文章 Game Golang Saas Rust 游戏开发 客户端开发 GameDev Products Lua 写作

游戏服务器地图战争迷雾可见性架构设计

游戏服务器端架构设计最难的地方,不是把主流程写通,而是让系统在玩家重复操作、弱网、运营干预、版本切换和服务重启时仍然能解释。有战争迷雾的游戏里,玩家不应该知道视野外敌人的位置、血量和动作。若服务器把全量状态发给客户端,只靠客户端隐藏,外挂就能读内存开图。若服务器每帧精确计算所有单位视野,CPU 又很高。

8 分钟阅读

游戏服务器协作解谜状态机架构设计

游戏服务器端架构设计最难的地方,不是把主流程写通,而是让系统在玩家重复操作、弱网、运营干预、版本切换和服务重启时仍然能解释。多人副本常见协作解谜:三人同时踩地板,按顺序拉机关,两个队友分别守住能量柱,或一人观察图案一人输入。若每个机关脚本自己维护状态,玩家断线、重复点击、机关重置、房间重启时很容易卡死。

8 分钟阅读

游戏服务器世界天气控制面架构设计

游戏服务器端架构设计最难的地方,不是把主流程写通,而是让系统在玩家重复操作、弱网、运营干预、版本切换和服务重启时仍然能解释。开放世界里的天气不只是画面效果。暴雨可能影响视野,沙尘暴影响移动速度,月食触发怪物刷新,雪天改变采集产出。若天气只由客户端本地随机,玩法无法信任;若每个场景服自己随机,跨区体验又不一致。

8 分钟阅读

游戏运营熔断开关架构:线上出事时先止血再追因

背景:问题通常不是突然出现的 凌晨活动上线后,某个奖励配置导致玩家可以无限领取。最理想的情况不是研发十分钟内发修复包,而是值班同学一分钟内关闭该领取入口、冻结相关奖励发放、保留证据,然后再慢慢查根因。运营熔断开关不是普通功能开关,它是事故现场的刹车系统,设计目标是少数授权人员在高压下能做出明确、可回滚、可审计的止...

8 分钟阅读

状态校验和对账架构:服务端如何发现客户端悄悄跑偏

背景:问题通常不是突然出现的 很多同步问题不会立刻爆炸。客户端某一帧少收到一个 Buff,之后伤害数字略有差异;某个怪物位置本地预测偏了半米,五秒后碰撞判定不同;背包红点本地状态没刷新,玩家以为奖励丢了。状态校验和对账架构的目的,是让服务端和客户端定期确认“我们看到的关键世界是否仍然一致”,并在偏差刚出现时定位和修复。

8 分钟阅读

游戏服务器战果校验架构设计

不是所有游戏都能把战斗完全放在服务器权威模拟里。移动网络、成本、玩法类型和历史包袱都会让一些战斗采用客户端表现、服务端校验的模式。问题在于,客户端说“我赢了”并不等于服务器应该发奖。战果校验架构的目标,是在不把所有战斗重跑成重型服务器模拟的前提下,尽量判断结果是否可信,并把高风险结算挡在奖励闸门前。

9 分钟阅读

维护模式排水架构:不停服世界如何温柔地关门

背景:问题通常不是突然出现的 游戏维护并不是简单地把服务器关掉。玩家可能正在排位赛最后一局,公会战正在结算,商城订单刚回调,世界服还有几百个队伍在副本里。粗暴关服会制造补偿、投诉和数据修复。维护模式排水架构要做的是让系统逐层进入只出不进状态:新玩家不再进入风险区域,已在进行的玩法尽量自然结束,不能结束的状态被明确...

8 分钟阅读

游戏配置灰度护栏架构:把热更风险关进笼子里

背景:问题通常不是突然出现的 游戏项目里很多线上事故并不是代码发布造成的,而是一张配置表改错了。掉落概率多写一个 0、活动时间少配一个时区、技能公式引用了不存在的字段,都可能在几分钟内影响大量玩家。配置灰度护栏的价值,是让策划和运营仍然能高频调整内容,但服务端不会把每一次配置变更都当成无条件可信的真理。

8 分钟阅读

战斗输入仲裁架构:服务端如何在预测、延迟和公平之间取舍

背景:问题通常不是突然出现的 实时战斗服务端最难的地方,不是收到输入后执行技能,而是判断这个输入在当时是否应该成立。玩家本地看到自己在 320ms 前按下格挡,对手看到的是已经命中,服务端收到两个输入时又晚了几十毫秒。若完全相信客户端时间戳,外挂可以伪造过去;若完全相信服务端到达时间,高延迟玩家几乎没法玩。

8 分钟阅读