冠赢互娱基于 OpenKrusieGame 实现游戏云原生架构升级

作者：力铭

关于冠赢互娱

冠赢互娱是一家集手游、网游、VR 游戏等研发、发行于一体的游戏公司，旗下官方正版授权的传奇类手游——《仙境传奇》系列深受广大玩家们的喜爱。基于多年 MMORPG 类型游戏的自研与运营经验，冠赢互娱正式推出了 2D MMO 游戏开发引擎 Thousand，并成功应用至近期上线的《仙境传奇-梦回零三》手游。其背后采用的云原生架构大幅度提升了游戏开服、更新等运维效率，同时降低了服务器的资源成本，并为后续开发更优秀的产品、加快游戏生态成型提供扎实基奠。

MMORPG 手游《仙境传奇-梦回零三》

启用云原生架构的初衷

在 Thousand 引擎立项之初，研发团队基于传统区服类游戏的特点，决定采用云原生架构。主要的考虑如下：

区服之间具有强隔离属性，应尽量避免资源抢占。过往运营游戏时会出现同台宿主机上不同区之间相互资源干扰的情况，加大了受影响的玩家数量。而利用容器技术可以实现精细化的资源控制，避免区服之间相互干扰，能够有效降低故障影响面。
通过声明式的方式进行游戏服管理带来了效率优势。从过去运维机器、执行一系列脚本演化为以服务为对象、批量且自动化管理的方式，不仅可大幅度提升开服效率，同时也能降低游戏维护时的出错概率。
需要更加精细化的故障定位、及业务快速恢复的能力。区服共享计算节点，当故障发生时，无法及时定位故障根因源自区服 A、区服 B、还是宿主机，且当机器故障时，业务迁移效率十分低下。通过云原生架构，基础设施资源与业务一定程度的解耦带来了业务故障快速定位的能力，并且容器轻量且环境一致性的特点带来了高效的业务恢复能力，问题定位及恢复的效率大幅度提升。
云原生生态日益茁壮，通过云原生技术不仅可高度集成计算、网络、存储等基础设施资源、而且可以非常轻便地利用上可观测、调度、应用交付等能力。

游戏服落地 Kubernetes 的挑战

然而，云原生化绕不开的容器编排标准 Kubernetes 对游戏的支持力度十分有限，冠赢传奇类游戏在落地 Kubernetes 的过程中也遇到了众多挑战：

众多区服，如何在 Kubernetes 上进行管理

每个区服需要单独暴露公网地址，玩家选择服务器后可直连对应区服。额外进行接入层网络管理无疑增加了区服批量管理时的运维成本；同时如果选择单个区服 pod 绑定 EIP 的模式又会消耗大量的 EIP 资源，造成经济成本浪费。
单个区服是由多个服务共同组成，容器化后以一种“富容器”的形态存在。原生 Kubernetes 对业务状态管理停留在容器层面，无法精细化感知容器中特定进程状态，造成故障或异常难以定位处理；而将服务拆分，单独部署增加了架构复杂性、改造难度将急剧上升。
一个完整的游戏服由引擎侧与脚本侧组成，游戏服引擎支持热更脚本，避免频繁停服造成玩家流失。研发团队设计了多种游戏服落地 Kubernetes 后的热更方案，包括从公共服务器拉取最新热更文件、或通过云储存动态挂载热更文件。但无论哪种方式，都会遇到各式问题，包括：

1）不支持版本化管理热更文件，更新频繁后实际存在的众多版本无法与文件形成对应关系，造成更新失败后回滚复杂；

2）更新状态难以定位。即使对容器中的文件进行了更新替换，但执行重载命令时难以确定当前热更文件是否已经挂载完毕，这种更新成功与否的状态维护需要交给运维者额外管理，也一定程度上提高了运维复杂度；

3）在容器异常时，pod 重建拉起旧版本的镜像，热更文件并未能持续化保留；

4）更新速度始终不尽人意。

OpenKruiseGame 助力游戏服云原生化落地

冠赢利用社区的开源项目 OpenKruiseGame 解决了上述问题，实现了 2D MMO 游戏开发引擎 Thousand 在 Kubernetes 的平滑落地。 OpenKruiseGame（简称 OKG），是 CNCF 孵化项目 OpenKruise 在游戏领域的子项目，其专门为游戏打造，协助游戏开发者实现更敏捷的游戏弹性架构、统一标准的运维动作、多云一致性交付、建立游戏自运维平台等能力。

面对以上挑战，冠赢使用了 OKG 以下能力：

OKG 提供了接入层网络自动化管理的能力，用户无需手动为每个区服构建/析构网络，并且针对不同场景支持了不同的网络模型。冠赢根据自身业务特点使用了 NATGW 模型，区服开服时自动生成 dnat entry，区服被合并（删除）时自动删除 dnat entry，多个区服将共享 EIP，可充分利用 EIP 的带宽资源。
OKG 认为游戏服的服务质量应由用户定义，用户可根据业务针对性地设置游戏服所处的状态，并精细化地进行相应处理。冠赢面对“富容器”的游戏场景，通过 OKG 的”自定义服务质量“探测到具体进程异常状态，并将其透出至 Kubernetes 侧，再利用 kube-event 等事件通知组件将异常告警至运维群中，帮助运维工程师快速发现问题，实现秒级故障定位，分钟级的故障处理。
OKG 提供了基于容器镜像的原地热更方案，热更脚本作为 sidecar 容器与 main 容器一同部署在同一个游戏服，二者通过 emptyDir 共享热更文件，更新时只需更新 sidecar 容器即可。这样一来游戏服的热更将以云原生的方式进行：

1）sidecar 容器镜像具有版本属性，解决了版本管理问题；

2）Kubernetes 容器更新成功后处于 Ready 状态，能够感知 sidecar 脚本更新是否成功；

3）即使容器异常发生重启，热更文件随着镜像的固化而持续化保留了下来；

4）通过镜像预热机制能够快速完成热更过程。

云原生化成果

Thousand 引擎整体云原生架构图如下所示。冠赢实现了基于 OKG 的平台化工程：

游戏工程师上传新脚本，触发 CI 流程，自动打包镜像后自动部署新的 GameServer 到 Kubernetes 集群；通过编辑旧脚本，同样可以触发 CICD，并基于 OKG 的原地升级更新对应 GameServer 的 sidecar 镜像，实现游戏服热更。整个过程无需游戏运维工程师参与，通过云原生技术将游戏服部署更新的能力交予游戏开发者，提高了游戏生产效率。
自动生成的 GameServer 基于 OKG 的网络功能具备独立的公网访问地址（EIP:端口唯一），Thousand 引擎平台提供服务发现机制使玩家直连对应区服进行游戏。
当游戏服偶发异常时，通过 OKG 提供的自定义服务质量功能，Thousand 引擎平台将感知到具体异常信息并将其通知于运维工程师，运维工程师可快速定位并响应问题，最大程度保证玩家的游戏质量。

Thousand 引擎的诞生标志着冠赢互娱实现了游戏云原生架构升级。经过生产验证，云原生架构带来了以下优势：

在开服效率方面： 传统开服时需要进行手动进行各个全服之间的 IP 端口配置关联，由于是手动配置，故障率也比较高，导致新区开服时间比较长。而在容器化之后，一切参数都标准化、可视化，面对流量高峰可以快速开服保证容器开服的速度和配置的完整性。开新区的时间效率从 30 分钟优化为 15 秒；开新服的时间效率从 2 分钟优化为 10 秒，极大提高了开服效率。
在更新效率方面： 传统更新流程会将各个目录文件的可执行文件进行覆盖更新，更新速度慢且出错率高；而在容器化后，引擎与脚本拆分为两个容器，二者可分别定向被更新，更新的粒度更加细致可控，降低了更新错误率，同时通过镜像预热的方式带来了秒级的更新体验，更新效率提高了 5 倍。
在成本节约方面： 传统开服时会通过预估人数采购好对应的游戏服服务器配置做资源预留，同时服务需要的资源无法准确隔离，导致服务资源存在较大冗余且资源配置无法及时调整，造成了大量资源浪费；而在容器化后，游戏服相互之间资源隔离，结合精细化调度可以充分利用宿主机资源，资源成本至少节约 10%。
在问题定位方面： 传统手动部署的环境中，经常出现区服崩溃无法及时发现的问题；而容器化后可以直接透出区服具体报错进程，快速定位服务问题并解决，问题响应效率提升 5 倍。

云原生游戏展望

尽管游戏云原生化后硕果累累，但冠赢的云原生化进程仍未结束。冠赢云平台技术负责人盛浩表示：“云原生技术蓬勃发展，未来冠赢将更加全面地拥抱云原生，与 OKG 社区携手并进，计划引入混沌工程并建立故障自愈体系，进一步加强平台自动化运维能力；通过垂直伸缩动态调配，在保证区服玩家可玩性的同时进一步节约资源成本”。

其实未来并不遥远，OKG 已经开放了自定义故障定义功能、并支持自动向特定状态容器执行运维脚本的功能；而 K8s 1.27 版本也引入了原地自动垂直伸缩的能力，对区服类游戏的资源调配意义重大。也许，属于游戏的云原生时代就在我们眼前。

相关链接：