让游戏云原生化别再「左右为难」-Toy模板网

这篇具有很好参考价值的文章主要介绍了让游戏云原生化别再「左右为难」。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

作者：云原生游戏社区

当下，游戏行业正在经历云原生架构转型期，不少游戏厂商纷纷投入游戏服容器化改造。在此现象的背后，是云原生技术带来的先进生产力推动着行业向前发展：容器化提升了游戏交付的效率；声明一致性带来游戏开服效率、更新效率、以及可用性的提升；弹性伸缩使得资源可自动化地应对游戏高峰期与波谷期，在保证游戏服务质量的同时提高资源利用率。

2024 年 1 月 18 日，OpenKruiseGame (OKG) 社区与 KubeSphere 联合举办了议题为「用 OKG Dashboard 解锁云原生游戏运维之道」的技术直播。本文将与大家一起回顾分享内容。

OpenKruiseGame：游戏云原生化的理想路径

尽管云原生带来了众多优势，但作为容器编排管理事实标准的 Kubernetes，其原生工作负载并不能很好地支持游戏场景，因此 OpenKruiseGame 在此背景下诞生。

1）OpenKruiseGame 是 CNCF 顶级开源云原生负载 OpenKruise 在游戏领域下的最佳实践抽象，项目由多家一线游戏公司共同贡献维护；

2）内置多云/混合云场景的适配，推出了 Cloud Provider 的模型，便于开发者在多种不同云环境下实现游戏的一致性交付；

3）可以通过无侵入式的声明方式与云上能力，例如：透明无损网络、极致秒级弹性、低成本资源供给、全生命周期可观测性等能力无感打通；

4）将游戏场景下的版本热更新、网络 IP 端口固定、区服管理、自动伸缩等通用能力进行抽象，并通过语义化的配置进行透出，降低学习和二次开发的成本；

5）覆盖 PVP/PVE/H5类/MMORPG 等多种常见的游戏类型的差异化容器需求，白屏化支持复杂游戏架构的游戏服编排能力。

云原生游戏,游戏,云原生,OpenKruiseGame

下面来介绍不同类型的游戏如何通过 OpenKruiseGame 完成云原生改造。

PvP 游戏最佳实践

会话类（session based）游戏，是指在有限的时间内，将玩家汇聚到特定游戏场景下的游戏类型。在通常意义下，会话等同对局，一局结束后，玩家间的游戏关系也在此结束，该会话也同时结束。因此，在业界也会将会话类游戏通俗的理解为“开房间游戏”，一个房间承载了对应的游戏会话。这类游戏往往存在着以下特点：

1）游戏时间非连续，存在明显的起停时间节点。

2）会话中至少存在 2 个及以上的玩家，相互战斗、交互。

3）常见于 MOBA、FPS 类游戏，对时延要求较高。

4）业务波峰与波谷时，对局数量差距明显。因此，一个理想的 PvP 游戏的云原生架构应具有以下能力：

提供网络直连功能，为每个房间提供独立的公网访问地址，玩家客户端可直接访问。
提供游戏匹配功能，为玩家找到合适的队友与对手组成会话对局，并为其分配合适的游戏房间。
提供状态管理功能，自动化管理游戏房间的业务状态与生命周期。
提供弹性伸缩功能，根据业务波峰与波谷自动申请和释放基础设施资源，控制成本。
可高效地进行游戏交付及运维管理，自动化水平高。

有关 PvP 游戏最佳实践阅读 OpenKruiseGame 官方文档：

https://openkruise.io/zh/kruisegame/best-practices/session-based-game

PvE 游戏最佳实践

与 PvP 会话类游戏不同，PvE 游戏的特点如下：

单个区服运行时间较长，应尽量避免停服操作，利于玩家游戏体验。
开服时（或）存在配置差异。
单区服容器中（或）存在多进程，区服服务质量需由用户定义。
随着时间推移，各区服状态存在差异，需定向管理，如更改资源规格、镜像版本、定向合服等。

该类游戏在落地 Kubernetes 通常遇到左右为难的困境：

若使用 Kubernetes 原生 workload，则无法进行游戏服精细化管理，具体地：

- 若使用 Deployment 管理：
- 生成的 pod 没有类似序号的状态标识，导致：1）无法基于序号进行有状态的服务发现了；2）无法区别游戏服之间状态差异性；3）异常重启时状态丢失，配置/存储等无法自动重定向。
- 若使用 StatefulSet 管理：
- 生成的 pod 虽然有序号作为状态标识，但是：1）只能从序号大到小进行更新或删除，无法定向管理游戏服；2）无法感知游戏服之间的状态差异特性。

若不使用 Kubernetes 原生 workload，则无法利用上 K8s 的编排能力：

- 若使用脚本程序批量开服：
- 属于面向过程的方式，参数无法落盘，出错率高。
- 若使用 gitops 管理：
- 区服数量较多时需要维护大量有着相同字段的 yaml 文件，有时甚至超过文件长度限制；批量发布时也十分复杂。
- 若通过自建 PaaS 平台管理：
- 需要引入大量开发工作，且与业务属性耦合较重，导致后续迭代复杂

有关 PvE 游戏最佳实践阅读 OpenKruiseGame 官方文档：

https://openkruise.io/zh/kruisegame/best-practices/pve-game

云原生游戏交付与运维管理最佳实践

对于游戏应用来说，一个云原生的交付流程应该如此：

游戏开发者提交业务代码至代码仓库，自动触发 CI 流程打包容器镜像，通过 ArgoCD 自动化部署至测试环境中。游戏开发者可以快速测试业务逻辑是否符合预期，无需运维同事介入，保证与生产环境一致性的同时也提高了研发效率。
而在正式/灰度的环境下，运维工程师维护游戏应用部署仓库，提交编排的游戏服 Yaml，即可完成游戏服开服、更新等动作。部署后，可通过 KubeSphere OKG Dashboard 来可视化观察集群中所有游戏服的状态，并针对性地进行运维管理。

云原生游戏,游戏,云原生,OpenKruiseGame

游戏应用交付与运维管理最佳实践

KubeSphere OKG Dashboard 是 OpenKruiseGame 基于 KubeSphere 4.0 LuBan 架构提供了游戏服白屏化管理控制台，支持用户基于 KubeSphere 可视化地管理 OpenKruiseGame 涉及的对象，如 GameServerSet 与 GameServer。

当前通过 OKG Dashboard 可以查看当前集群中游戏服整体统计数据、所有游戏服部署集与游戏服的运行情况。此外，还可以定向对游戏服进行更改运维状态等操作。

云原生游戏,游戏,云原生,OpenKruiseGame