让游戏云原生化别再「左右为难」
作者:云原生游戏社区
当下,游戏行业正在经历云原生架构转型期,不少游戏厂商纷纷投入游戏服容器化改造。在此现象的背后,是云原生技术带来的先进生产力推动着行业向前发展:容器化提升了游戏交付的效率;声明一致性带来游戏开服效率、更新效率、以及可用性的提升;弹性伸缩使得资源可自动化地应对游戏高峰期与波谷期,在保证游戏服务质量的同时提高资源利用率。
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 完成云原生改造。
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 来可视化观察集群中所有游戏服的状态,并针对性地进行运维管理。
游戏应用交付与运维管理最佳实践
KubeSphere OKG Dashboard 是 OpenKruiseGame 基于 KubeSphere 4.0 LuBan 架构提供了游戏服白屏化管理控制台,支持用户基于 KubeSphere 可视化地管理 OpenKruiseGame 涉及的对象,如 GameServerSet 与 GameServer。
当前通过 OKG Dashboard 可以查看当前集群中游戏服整体统计数据、所有游戏服部署集与游戏服的运行情况。此外,还可以定向对游戏服进行更改运维状态等操作。
查看当前集群中游戏服整体统计数据
查看所有游戏服部署集的运行情况
查看所有游戏服的运行情况
参考资料:
[1] OpenKruiseGame 的官方文档
https://openkruise.io/zh/kruisegame/introduction
[2] OpenKruiseGame GitHub 仓库
https://github.com/openkruise/kruise-game
[3] OKG Dashboard
https://kubesphere.com.cn/marketplace/extensions/kruise-game-dashboard/
对于云原生游戏感兴趣的同学可以加入云原生游戏交流群。(钉钉群号:44862615)
点击此处,访问 OpenKruiseGame 仓库。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
一种轻量分表方案-MyBatis 拦截器分表实践
背景 部门内有一些亿级别核心业务表增速非常快,增量日均100W,但线上业务只依赖近一周的数据。随着数据量的迅速增长,慢SQL频发,数据库性能下降,系统稳定性受到严重影响。本篇文章,将分享如何使用MyBatis拦截器低成本的提升数据库稳定性。 业界常见方案 针对冷数据多的大表,常用的策略有以2种: 1. 删除/归档旧数据。 2. 分表。 归档/删除旧数据 定期将冷数据移动到归档表或者冷存储中,或定期对表进行删除,以减少表的大小。此策略逻辑简单,只需要编写一个JOB定期执行SQL删除数据。我们开始也是用这种方案,但此方案也有一些副作用: 1. 数据删除会影响数据库性能,引发慢sql,多张表并行删除,数据库压力会更大。 2. 频繁删除数据,会产生数据库碎片,影响数据库性能,引发慢SQL。 综上,此方案有一定风险,为了规避这种风险,我们决定采用另一种方案:分表。 分表 我们决定按日期对表进行横向拆分,实现让系统每周生成一张周期表,表内只存近一周的数据,规避单表过大带来的风险。 分表方案选型 经调研,考虑2种分表方案:Sharding-JDBC、利用Mybatis自带的拦截器特性...
- 下一篇
文本检索性能提升 40 倍,Apache Doris 倒排索引深度解读
在 OLAP 领域,Apache Doris 已成为高性能、高并发以及高时效性的代名词。在面向海量数据的复杂查询需求时,除硬件配置、集群规模、网络带宽等因素外,提升性能的核心在于如何最大程度地降低 SQL 执行时的 CPU、内存和 IO 开销,而这其中数据库索引扮演着至关重要的角色。合理的索引结构设计可以跳过大量不必要的底层数据读取、快速检索定位到所需数据,并进一步提升后续计算的执行效率、降低查询 SQL 的运行时间和资源消耗。 Apache Doris 提供了丰富的索引以加速数据的读取和过滤,依据是否需要用户手工创建,索引类型大体可以分为智能内建索引和用户创建索引两类,其中智能内建索引是指在数据写入时自动生成的索引,无需用户干预,包括前缀索引和 ZoneMap 索引。用户创建索引需要用户根据业务特点手动创建,包括 Bloom Filter 索引和 2.0 版本新增的倒排索引与 NGram Bloom Filter 索引。 相较于用户比较熟悉的前缀索引、Bloom Filter 索引,2.0 版本所新增的倒排索引和 NGram Bloom Filter 在文本检索、模糊匹配以及非主键列...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS关闭SELinux安全模块
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,7,8上安装Nginx,支持https2.0的开启