辅助服务器故障 Auxiliary service outage

原因 ID in-subservice · 主责 研发团队·服务器开发 · 配合运维团队·系统运维

聊天、组队、拍卖行这类与游戏服务器分开运行的服务器出故障时，只有对应的功能不能用。

起因功能专用服务器变慢或挂掉 → 结果只有该功能的请求没有响应 → 画面表现 聊天发不出去，组队邀请没反应，交易行无限加载（战斗正常）

症状: 吞操作/回档, 连不上/无限加载
因素: 停顿, 丢包
谁会遇到: 仅特定功能
何时出现: 偶尔随机, 人多的时候
负责方: 主责 研发团队·服务器开发 · 配合运维团队·系统运维
研发团队要做的事: 设计成即使失败游戏也能继续，按功能显示状态，不要把多个功能集中到一台中心服务器上。
运维团队要做的事: 为每台辅助服务器配置健康检查和告警，做冗余和自动重启。
监控图上: 连接成批断开 · 各功能的请求成功率，辅助服务器的连接数、健康检查
查看位置: 聊天、组队、拍卖行等各辅助服务器的健康检查、进程状态和连接数，各功能的请求成功率、响应时间。在负载均衡器后面时，看目标组的 UnHealthyHostCount
确认依据: 只有负责被反馈功能的服务器出现健康检查失败或连接数骤降，游戏服务器的 tick 和战斗正常
排除依据: 多个功能同时停摆，则是统一中转这些功能的中心服务器，或级联故障
确认手段: 运维工具即可确认（无需游戏代码）
深入了解: 如果组队、公会、私聊、跨服务器移动全由一台中心服务器（世界服务器、管理服务器）中转，这台服务器一变慢，多个功能就会同时停摆。

出处

Bulkhead Pattern Microsoft Azure
把组件隔离到各自的资源池里，一个失败时其余部分照常工作，故障不会扩散
REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies AWS
AWS Well-Architected。设计上要保证依赖对象故障时，核心功能也能用稍旧的数据或替代数据继续运行
CloudWatch metrics for your Network Load Balancer AWS
UnHealthyHostCount：健康检查判定为异常的目标数