游戏卡顿白皮书 › L13 服务器架构与运维
经由网关/代理 Gateway / proxy hop
原因 ID in-gateway · 主责 研发团队·服务器开发 · 配合 运维团队·系统运维, 研发团队·客户端开发
在含图示和实验的完整版中打开此卡片 →
在客户端和游戏服务器之间加一层中间服务器，每经过一次就多一段处理时间，这台服务器也会成为单点故障。
起因 客户端 ↔ 网关 ↔ 游戏服务器的结构 → 结果 中间服务器增加处理和排队时间，过载时所有人都受影响 → 画面表现 所有人 ping 上升，网关故障时经过它的玩家全部掉线
- 症状
- 操作延迟, 掉线
- 因素
- 延迟, 停顿
- 谁会遇到
- 全服
- 何时出现
- 人多的时候, 一直
- 负责方
- 主责 研发团队·服务器开发 · 配合 运维团队·系统运维, 研发团队·客户端开发
- 研发团队要做的事
- 服务器：网关可以扩到多台的结构；某台网关挂掉后重新连到其他网关，角色状态能直接接上的结构（会话重连）。客户端：网关断开时自动重连。
- 运维团队要做的事
- 网关水平扩容（增加台数），按网关监控 CPU、连接数、处理延迟。
- 数值参考
- 因为在同一数据中心内，平时每经过一次不到 1 ms。网关过载时会增加到几十到几百 ms。
- 监控图上
- 随人数/负载上升 · 网关处理延迟，网关 CPU、连接数
- 查看位置
- 网关的 CPU、连接数，网关 socket 的 Recv-Q（ss、netstat），以及经过网关前后的延迟差。经过服务网格的 HTTP、gRPC 调用，把 Istio 标准指标 istio_request_duration_milliseconds 按发送方（reporter=source）和接收方（reporter=destination）分开对比
- 确认依据
- 游戏服务器的处理时间不变，只有网关这一段的延迟增加，且此时网关 CPU 打满或 Recv-Q 堆积
- 排除依据
- 不经过网关的路径（直连、其他网关）同样慢，则是线路或游戏服务器侧
- 确认手段
- 运维工具即可确认（无需游戏代码）
- 深入了解
- 使用服务网格（如 Istio）时，每台服务器旁边挂着的 sidecar 代理（Envoy）也会多出一跳。服务之间的请求要依次经过发送方的 sidecar 和接收方的 sidecar，代理上加的日志、指标采集等功能越多，处理时间和等待时间就越长。
- 真实案例
- Riot Games 2020: League of Legends 欧洲、巴西服务器的边缘主机过载
出处
- The Unique Architecture behind Amazon Games’ Seamless MMO New World AWS
New World 的客户端连接到 4 台拥有公网地址的入口服务器（REP）之一，再与其后的模拟服务器（Hub）通信 - Designs, Lessons and Advice from Building Large Distributed Systems Google
LADIS 2009 主题演讲（Jeff Dean）。同一数据中心内往返约 0.5 ms - Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
过载导致队列变长时，等待时间会增至处理时间的数倍（处理 100 ms、队列长度为线程数的 10 倍时为 1.1 秒） - Performance and Scalability Istio
sidecar 模式下，请求依次经过发送方和接收方的 sidecar 代理；功能加得越多，代理内部的处理路径越长，遥测采集还会增加下一个请求的等待时间 - What is Envoy Envoy
Envoy 是在每台应用服务器旁边单独运行的进程，应用通过 localhost 上的 Envoy 收发数据 - Istio Standard Metrics Istio
istio_request_duration_milliseconds（HTTP、gRPC 请求处理时间的分布），用 reporter 标签区分发送方（source）和接收方（destination）的代理 - netstat(8) — Linux manual page net-tools
Recv-Q：已连接 socket 中用户程序尚未取走的字节数
相关原因
同一层：L13 服务器架构与运维
其他层中同样导致“操作延迟”的原因
查看含图示和实验的原卡片