阿里云 API 网关 x OKG：游戏连接治理的「最后一公里」

阿里云云原生

于 2025-07-28 10:15:56 发布

阅读量610

点赞数 19

CC 4.0 BY-SA版权

文章标签：阿里云游戏云计算

本文链接：https://blog.youkuaiyun.com/alisystemsoftware/article/details/149709389

游戏连接治理的最后一公里

游戏有状态的属性决定了玩家的连接需要精细化处理。在传统端游场景，游戏往往通过业务网关维护四层协议连接，或者为低延迟游戏提供独立访问地址以实现客户端直连。

随着小程序与 H5 游戏的普及，基于七层协议的网络游戏面临双重挑战：一方面需要控制开发运维成本，另一方面必须满足创意验证对快速版本迭代的要求。这种矛盾催生了对高效弹性架构的迫切需求——通过云原生转型实现资源利用效率优化与游戏发布流程革新。

在七层网络场景下，玩家状态管理与连接治理形成深度耦合。玩家连接/退出事件与服务实例的动态伸缩之间存在精密平衡关系，特别是在自动化运维场景下（如服务实例下线、版本灰度发布等），如何保障玩家会话连续性成为云原生游戏连接治理的关键挑战。这不仅涉及连接状态的实时感知与迁移，更需要构建从基础设施到业务层的全栈治理能力，这正是实现云原生游戏连接治理的"最后一公里"。

基于业务状态的流量管理

为拉近这最后一公里的路途，OKG（OpenKruiseGame）【1】与 API 网关【2】结合各自优势（细粒度的状态感知与精细化流量治理），致力于打造新一代游戏网关，在不侵入业务架构的同时实现游戏服优雅下线、配置无感变更等能力。

优雅下线

游戏服务的强状态特性决定了其对优雅下线的迫切需求。传统下线操作往往无法满足游戏服务对特定条件的严格要求，可能导致玩家体验中断或数据丢失。为应对这一挑战，OpenKruiseGame 引入了自定义生命周期钩子的功能，突破了 Kubernetes 原生 PreStop 钩子机制的局限性，为游戏服务提供了精确到毫秒级的生命周期控制能力。

云原生 API 网关与 OKG 深度融合，构建了一套完整的游戏服务优雅下线解决方案。当 OKG 服务进入 PreDelete 状态时，云原生 API 网关会及时从注册中心剔除该实例，确保新的请求不再路由至即将下线的服务。与此同时，已建立连接的玩家会话则被智能保留，直至 OKG 服务完成自定义的生命周期管理流程^【3】，实现了新老请求的分流处理，最大程度地保障了玩家体验的连续性，具体如下图所示：

为了直观展示这一过程，我们将以云原生 API 网关为例，通过监控活跃长连接数这一关键指标来模拟玩家数量变化，详细阐述 OKG 服务在云原生 API 网关上的优雅下线全流程。这不仅体现了云原生技术在游戏场景下的精细化应用，更彰显了现代游戏服务治理对状态感知与流量调度的高度融合。

接下来视频将直观的演示 OKG 服务在云原生 API 网关环境中的优雅下线过程。

如演示所示，具体部署步骤如下：

前置步骤：

开通 ACK 托管集群，安装 ack-kruise-game 和 ack-kruise 组件. 开通 API 云原生网关【2】。

OKG 服务部署：

为了模拟真实的游戏环境，我们选择了开源游戏 Posio 作为我们的 demo 游戏服。通过以下 yaml 文件，可以快速构建一个多实例的游戏服务集群。

apiVersion: game.kruise.io/v1alpha1
kind: GameServerSet
metadata:
  name: postio
  namespace: default
spec:
  lifecycle:
    preDelete:
      labelsHandler:
        gs-sync/delete-block: "true"
  replicas: 3
  updateStrategy:
    rollingUpdate:
      podUpdatePolicy: InPlaceIfPossible
  network:
    networkType: Kubernetes-Ingress
    networkConf:
    - name: IngressClassName
      value: "higress"
    - name: Port
      value: "5000"
    - name: Path
      value: /
    - name: PathType
      value: Prefix
    - name: Host
      value: game<id>.postio.example.com
  gameServerTemplate:
    metadata:
      labels:
        gs-sync/delete-block: "true"
    spec:
      containers:
        - image: registry.cn-beijing.aliyuncs.com/chrisliu95/posio:8-24
          name: postio
      volumes:
        - name: gsinfo
          downwardAPI:
            items:
              - path: "state"
                fieldRef:
                  fieldPath: metadata.labels['game.kruise.io/gs-state']
  serviceQualities:
    - name: healthy
      containerName: minecraft
      permanent: false
      exec:
        command: ["bash", "./probe.sh"]
      serviceQualityAction:
        - state: true
          result: done
          labels:
            gs-sync/delete-block: "false"
        - state: false
          opsState: None

在这个示例中，我们通过 GameServerSet 创建了多个游戏服实例，每个实例都有其唯一的访问域名。具体而言：

游戏服0：game0.postio.example.com

游戏服1：game1.postio.example.com

游戏服2：game2.postio.example.com

这种域名设计不仅便于客户端精确访问不同的游戏服，也为后续的负载均衡和流量调度奠定了基础。通过这样的部署结构，我们可以模拟复杂的游戏服务环境，为优雅下线的实验提供真实可靠的测试平台。

在云原生游戏服务的优雅下线过程中，精确的状态感知和玩家会话管理至关重要。我们通过 YAML 脚本来实现这一复杂的过程，该脚本融合了状态检测、玩家活跃度监控和优雅退出机制。

状态感知脚本首先从/etc/gsinfo/state文件中获取当前游戏服务（GS）的状态。这一步骤体现了对服务生命周期的实时监控能力，是实现精确控制的基础。
下线触发判断当检测到 GS 状态为 “PreDelete” 时，脚本识别出服务已进入下线阶段。这种精确的状态判断确保了下线操作仅在适当的时机启动，最大限度地减少对玩家体验的影响。
玩家活跃度评估进入下线流程后，脚本会持续监控与该游戏服务相关的活跃连接数。这里，我们巧妙地利用 API 云原生网关提供的连接数指标作为玩家在线状态的代理指标。这种方法不仅简化了实现，还提供了一个可靠的玩家活跃度衡量标准。
优雅退出机制脚本会循环检查活跃连接数，直到该数值降为零。只有在确认所有玩家都已安全断开连接后，脚本才会输出 “done” 并以退出码 0 结束执行。这种机制确保了每一个玩家会话都得到了妥善处理，真正实现了"优雅"下线。

#!/bin/bash

file_path="/etc/gsinfo/state"

if [[ ! -f "$file_path" ]]; then
    exit 1
fi
data="query=sum(envoy_cluster_upstream_cx_active{cluster_name=~\"outbound_5000__${HOSTNAME}.default.svc.cluster.local\"})"

state_content=$(cat "$file_path")

if [[ "$state_content" == "PreDelete" ]]; then
     json=$(curl -s -G --data-urlencode $data http://prometheus.com/api/v1/query)
     value=$(echo "$json" | grep -o '"value":\[[^]]*\]' | sed 's/.*"\([^"]*\)"]/\1/')
     if [[ -z "$value" || "$value" == "0" ]]; then
       echo "done"
       exit 0
     fi
     exit 1
fi
exit 1