网关（Gateway）：游戏服务器的海关、翻译官和前台

版本更新日凌晨 3 点。公告写着停机维护 5 分钟。运维敲下重启命令的那一秒在线人数 128,400 → 0 2 秒内 登录 QPS 800 → 47,000 30 秒后 登录服 CPU 100%全线超时 实际恢复 ★ 41 分钟5 分钟的维护变成了 41 分钟的事故。复盘会上架构图被投到大屏上——客户端的连线直接连到了 6 个后端服务。一个资深工程师看了三秒说了一句“你们的玩家是直接站在后厨里点菜的。”第一幕先分清三个网关中文里网关这个词被严重超载了。三个完全不同的东西用了同一个名字。名字在哪一层干什么本文讲哪个默认网关Default Gateway网络层你家路由器的 IP192.168.1.1帮你把包送出局域网❌API 网关API Gateway应用层HTTP 请求的统一入口鉴权、限流、路由✅ 部分游戏网关服Gate Server / 接入层应用层长连接的统一入口游戏服务器架构的核心组件✅主角后两个才是我们要说的。它们的角色可以用三个身份概括 海关 —— 检查你的证件决定放不放行 翻译官 —— 把外面的语言翻译成里面的语言 前台 —— 记住你是谁帮你转接到正确的部门第二幕海关——它挡住了什么没有网关你的后厨对全世界开放❌ 直连架构 客户端 ──┬──→ 登录服 公网端口 8001 ├──→ 大厅服 公网端口 8002 ├──→ 战斗服 公网端口 8003 ├──→ 聊天服 公网端口 8004 ├──→ 商城服 公网端口 8005 └──→ 好友服 公网端口 8006这张图有六个致命问题问题后果6 个公网暴露点攻击面 ×6每个都要独立做防护6 套鉴权逻辑一处写错就是漏洞改一次要改 6 遍6 条长连接手机要维持 6 条 TCP6 份心跳电池哭了后端 IP 写死在客户端想换机器等发版任何一个服重启玩家立刻掉线 ←序幕的事故内网协议暴露在公网逆向一下你的内部结构全公开加上网关之后✅ 网关架构 ┌───────────────────────────┐ 客户端 ──→ LB ──→ │ 网关集群唯一暴露点 │ 1 条连接 │ 鉴权 · 限流 · 路由 · 翻译 │ └────────────┬──────────────┘ 内网不暴露公网 ┌──────────┬───────┼───────┬──────────┐ 登录服 大厅服 战斗服 聊天服 商城服海关具体查什么① 身份证 —— Token 校验JWT 验签 / Redis 查会话 ② 违禁品 —— 包长度上限、字段范围、非法 opcode ③ 走私 —— 签名校验、时间戳窗口、nonce 去重防重放 ④ 人流控制 —— 单 IP 限流、单账号限流、单接口限流 ⑤ 黑名单 —— 封号、封 IP、风控规则海关最大的价值在这一句一次检查后端全信任。网关校验通过后给消息打上可信的playerId标记后端服务直接相信它不再重复校验。内网消息头 [playerId][sessionId][gatewayId][payload] ↑ 这个 playerId 是网关盖的章后端不再怀疑⚠️ 前提是内网必须真的是内网。一旦有人能直连后端端口这套信任体系就全面崩塌。所以后端服务绝不能监听0.0.0.0必须绑内网 IP 安全组限制。第三幕翻译官——它翻译了什么翻译一外网协议 → 内网协议外面的世界很乱客户端用什么为什么PC 端TCP 自研二进制网络稳定简单可靠手机端KCP / 可靠 UDP弱网下延迟低 30~40%H5 / 小游戏WebSocket浏览器只给这个主机端平台 SDK 的专有通道平台要求里面的世界很整齐统一的内网 RPCgRPC / 自研 TCP / 消息队列网关站在中间把四种方言翻译成一种官话。┌── 外网乱 ──┐ ┌── 网关 ──┐ ┌─ 内网齐─┐ TCP 二进制 ─────→ ─────→ KCP 二进制 ─────→ 解密 ─────→ 统一 WebSocket ─────→ 解包 ─────→ gRPC 平台通道 ─────→ 转换格式 ─────→这带来一个巨大的解耦收益后端逻辑服完全不知道玩家是从哪种客户端来的。明年要上 H5 版本只在网关加一个 WebSocket 接入器后端一行不改。翻译二版本兼容玩家不会同时更新。灰度期间线上永远有新旧两个版本的客户端。// 网关做版本适配后端只认最新协议switch(conn.ProtoVersion){case3:msgUpgradeV3ToV4(msg);break;// 老客户端补字段case4:break;// 最新直接过default:returnReject(版本过低请更新);}不这么做的后果每个后端服务都要写一遍if (version 4)散落在几十个文件里没人敢删。翻译三TLS 终结客户端 ──[ TLS 加密 ]──→ 网关 ──[ 明文/轻量加密 ]──→ 后端 ↑ ★ 加解密的 CPU 开销集中在这一层 ★ 证书只需要在网关更新 ★ 后端服务完全不用懂 TLS证书到期是运维事故的高发区。集中在网关只需要换一个地方。第四幕前台——它记住了什么连接与会话必须分开这是网关设计里最核心的一个概念。连接Connection一个 TCP socket / 一个 UDP 会话 ★ 脆弱会断绑在某台网关上 会话Session playerId、当前在哪个房间、权限、状态 ★ 持久存在 Redis 里和连接解绑// 网关本地只管连接classConnection{Socketsocket;stringsessionId;// ★ 只存一个 IDlonglastRecvTime;}// Redis存真正的会话// session:{sessionId} { playerId, roomId, gatewayId, loginTime, ... }为什么必须分开玩家从 WiFi 切到 5G → 连接断了 ❌ → ★ 会话还在 ✅ → 重连时带上 sessionId0.3 秒恢复游戏世界毫无感知如果会话存在网关内存里网关一重启所有人的状态就没了——这就是序幕事故的根因之一。路由表前台的通讯录玩家的一条消息进来 → 网关看 opcode → 决定转给谁 opcode 0x1001 (移动) → 该玩家所在的【房间服 #17】 opcode 0x2001 (聊天) → 聊天服任意一台无状态 opcode 0x3001 (买东西) → 商城服任意一台 opcode 0x4001 (组队邀请) → 好友服两类路由处理方式完全不同类型例子怎么路由无状态服务聊天、商城、邮件随便挑一台轮询/最少连接有状态服务房间服战斗必须固定到那一台房间在谁那儿就发给谁扇出Fan-out网关最被低估的能力这是一个能省掉 90% 内网带宽的设计。❌ 逻辑服直接广播 房间服 ──→ 玩家1 ──→ 玩家2 ... ──→ 玩家100 ★ 发 100 份一模一样的数据 ✅ 网关扇出 房间服 ──→ 网关A这份发给你这边的 25 人 ──→ 网关B25 人 ──→ 网关C25 人 ──→ 网关D25 人 ★ 只发 4 份 ↓ 网关本地复制 25 份发出去算一笔账100 人房间30Hz快照 400 字节房间服出口带宽直接广播100 × 30 × 400 B 1.2 MB/s / 房间网关扇出4 个网关4 × 30 × 400 B 48 KB/s / 房间一台房间服跑 30 个房间288 Mbps → 11.5 Mbps。降到 1/25。这个优化的精妙之处复制数据这件事越靠近出口做越便宜。在房间服做要过一次内网在网关做直接就出去了。第五幕射击游戏里的六个战场战场一后端热更新玩家不掉线序幕结案目标逻辑服发版玩家无感知。关键在于断开的是网关↔后端不是玩家↔网关。① 大厅服要更新 ↓ ② 网关检测到大厅服下线 → ★ 不断开玩家连接 ↓ ③ 玩家发来的大厅请求 → 网关暂存到队列最多 3 秒 ↓ ④ 新版本大厅服起来注册到服务发现 ↓ ⑤ 网关把队列里的请求重放过去 ↓ ★ 玩家只感觉卡了一下没掉线但战斗房间不能这么玩。房间服带着完整对局状态不能中途重启。房间服的发版策略① 新版本房间服上线开始接收【新房间】 ② 老版本房间服停止接收新房间★ 把手上的局打完 ③ 最后一局结束最多 15 分钟→ 下线这叫生命周期对齐发版——利用对局本身是短生命周期的特点等它自然结束而不是打断它。结果同样的更新在线人数曲线上看不出任何凹陷。战场二开服洪峰网关当闸门现象新赛季 0 点12 万人同时涌入。没有网关时所有人直接冲向登录服和大厅服 → 数据库连接池耗尽 → 雪崩。网关的四道闸门① 连接层限流 单 IP 每秒最多 5 个新连接防单机脚本刷 全局新连接速率上限 3000/s超过的直接排队 ② 排队系统 超过承载量 → 不拒绝发号 返回 { queuePos: 8420, eta: 62s } ★ 玩家能接受排队不能接受未知错误 ③ 舱壁隔离 登录路由 / 大厅路由 / 商城路由 各有独立的后端连接池 ★ 登录打满时商城照常卖 ④ 熔断降级 大厅服超时率 50% → 熔断返回明确的服务繁忙 ★ 不让客户端盲目重试火上浇油特别注意第①条里的一个细节// ❌ 只按 IP 限流网吧/公司出口一个 IP全被误杀// ✅ IP 限流 账号限流 设备指纹多维度if(!ipLimiter.TryAcquire(ip)!IsKnownGateway(ip))Reject();战场三背压——网关自己别被压垮现象网关内存持续上涨最后 OOM 重启带走 3 万玩家。根因某个玩家的网络极慢2G 网络网关往他的 socket 写数据写不出去发送队列无限堆积。房间服 30Hz 推快照 → 网关往慢速客户端写 → 写不出去塞进队列 → 队列越来越长 → ★ 一个玩家吃掉几百 MB 内存三层防御// ① 队列上限 丢弃策略if(conn.sendQueue.CountMAX_QUEUE){// ★ 状态快照是【可丢弃】的——丢旧的保留最新的conn.sendQueue.DropOldestUnreliable();metrics.BackpressureDrops;}// ② 区分可靠 / 不可靠// 位置快照队列满了随便丢下一帧就来了// 结算消息绝不能丢宁可断开这个连接// ③ 超限踢人if(conn.sendQueue.CountHARD_LIMIT){conn.Close(网络状况过差);// 保护整个网关}一条重要原则网关必须假设有些客户端就是很慢并且保证它拖不垮其他人。这叫故障隔离——一个玩家的问题不应该变成一万个玩家的问题。战场四大厅到战斗的重定向匹配成功了玩家要从大厅转到战斗房间。方案 A换一条连接不推荐网关告诉客户端去连 battle-server-17.game.com:9017 ↓ ★ 战斗服暴露公网 → 攻击面扩大 ★ 重新建连 TLS 握手 → 1~2 秒空白 ★ NAT/防火墙可能连不上那个端口方案 B连接不变只换路由推荐客户端连接保持不变 ↓ 网关收到匹配结果该玩家分配到【房间服 #17 的 room_8891】 ↓ ★ 网关更新这条连接的路由表战斗类消息 → 房间服 #17 ↓ 玩家毫无感知连接从头到尾就一条收益方案 A方案 B进战斗耗时1.5~3 s 100 ms公网暴露点多 N 个仍然只有网关弱网成功率87%99.6%战场五网关也是最好的观测点所有流量都经过网关 → 它天然是最完整的数据源。每条消息都能打点 playerId · opcode · 处理耗时 · 后端服务 · 成功/失败 · traceId → 按 opcode 统计 P99 延迟哪个接口慢了一眼看出 → 按后端服务统计错误率哪台机器有问题 → 链路追踪一个玩家的投诉能还原他完整的请求路径一个实战用法玩家报卡5 分钟定位查 traceId → 发现 opcode 0x1001移动的网关→房间服 RTT 是 180ms → 而正常是 2ms → 该房间服跑在一台跨机房的机器上调度失误 → 迁移问题解决没有网关时你得分别去 6 个服务翻日志而且它们的日志格式还都不一样。战场六DDoS 防护——收敛攻击面网关是唯一的公网入口意味着它也是唯一的攻击目标。分层防护┌ 云厂商清洗流量型攻击SYN Flood、UDP Flood │ ★ 这一层必须靠云厂商自己扛不住 T 级流量 ├ LB 层四层连接数限制、SYN Cookie ├ 网关层七层 │ · 握手前不分配大对象防资源耗尽 │ · ★ 未认证连接给极短超时3 秒内不完成握手就踢 │ · ★ 未认证连接的资源配额单独隔离 │ · 包长度硬上限解析前先检查 └ 业务层账号级风控、行为异常检测未认证连接单独隔离这一条很关键// ❌ 未认证连接和正常玩家共用一个连接池// → 攻击者建 10 万个空连接正常玩家连不进来// ✅ 分池constintMAX_PENDING5000;// 未认证连接上限constintAUTH_TIMEOUT_MS3000;// 3 秒内必须完成认证第六幕有状态网关的三个难题网关保存着连接所以它天然有状态。这带来三个必须解决的问题。难题一优雅下线Draining网关要重启怎么让玩家少受影响① 从负载均衡摘除不再接新连接 ↓ ② ★ 已有连接继续正常服务 ↓ ③ 向客户端推送建议重连信号 客户端在【合适的时机】重连比如一局结束后、在大厅时 ↓ ④ 等待 N 分钟或等连接数降到阈值以下 ↓ ⑤ 强制关闭剩余连接客户端自动重连到别的网关 ↓ ⑥ 进程退出⚠️第③步是关键主动告诉客户端该换个地方了而不是粗暴踢掉。一个正在战斗中的玩家被踢 vs 一个在大厅挂机的玩家被踢——体验天差地别。难题二重连要回到同一个网关吗答案不需要而且最好不要。只要会话存在 Redis 里重连到【任意一台网关】都能恢复 ↓ ★ 网关本身变成了准无状态 ★ 可以随意扩缩容但有一个例外如果玩家在战斗中房间服正在往旧网关推数据。解法会话里记着gatewayId重连后// 新网关接管后通知房间服更新路由awaitroomService.UpdatePlayerGateway(playerId,myGatewayId);// 房间服后续的推送改发到新网关难题三网关挂了怎么办单台网关承载 5 万连接 → 挂了就是 5 万人同时重连 ↓ ★ 必须防惊群客户端侧// 指数退避 随机抖动intdelayMath.Min(500*(1retry),15000);delayRandom.Range(0,delay);// ★ 抖动是关键服务端侧① 单台网关不要承载太多建议 3~5 万而非 20 万 ② 网关数量冗余N2 ③ 会话在 Redis重连成本低 ④ 限流闸门保护后端Checklist架构⭐公网只暴露网关后端服务绑内网 IP连接与会话分离会话存 Redis不存网关内存无状态服务随机路由有状态服务房间固定路由大厅→战斗用路由切换不是重新建连海关安全Token 校验集中在网关后端信任内网标记包长度硬上限解析前检查签名 时间戳 nonce 防重放未认证连接独立配额 短超时多维度限流IP 账号 设备注意网吧共享 IP翻译官协议多端协议TCP/KCP/WebSocket在网关统一版本适配集中在网关后端只认最新协议TLS 在网关终结证书集中管理性能⭐广播用网关扇出逻辑服只发一份背压保护发送队列上限 丢弃不可靠数据 超限踢人小包合并心跳搭车零拷贝转发能不反序列化就不反序列化运维优雅下线摘 LB → 推送重连建议 → 等待 → 强制关闭后端发版不断玩家连接房间服按对局生命周期发版单网关连接数控制在 3~5 万客户端重连指数退避 随机抖动网关埋点opcode 级延迟、后端错误率、traceId 全链路收尾回到那句话——“你们的玩家是直接站在后厨里点菜的。”没有网关的架构本质上是让每一个后端服务都去面对整个互联网各自做鉴权、各自扛攻击、各自处理协议兼容、各自暴露一个端口。而其中任何一个重启玩家就掉线。网关做的事说白了就是在混乱的外面和整齐的里面之间立一道墙再开一扇门。门口站着海关查证件、查违禁品、控制人流。门内站着翻译官把四种方言翻译成一种官话。翻译官旁边是前台记着你是谁帮你转接到正确的部门。于是后端的每一个服务都可以安心地假设“能走到我面前的都是自己人说的都是我听得懂的话。”这份安心就是网关全部的价值。它不产生任何游戏逻辑不计算一次伤害不渲染一个像素。但它决定了——你发一次版是 5 分钟还是 41 分钟。