【阅读原文】戳：云上杂“弹” - 游戏服云上怎么弹
作者姓名：
力铭、莫源、郭赫曦
游戏行业云原生化的趋势
北京，2024年11月5日——国际数据公司（IDC）最新发布的《中国游戏云市场跟踪，2024上半年》报告显示，2024上半年中国游戏云市场规模达到9.1亿美元，同比增长5.9%。其中，解决方案市场同比完成双位数增长，高阶云服务、云原生产品与服务、实时互动服务等使用范围不断扩大，为市场持续、健康增长奠定基础。
2024年前三季度，游戏版号延续了2023年“常态化发放”趋势，市场信心不断恢复。作为当下监管态度最核心的 “风向标”之一，2024年1-10月，版署共审批发放国产游戏版号共计1072个，同比增加30%以上，进口版号发放同比增加50%以上，为项目持续迭代、市场稳步增长提供了良好环境。
经历了多年的尝试、试错与经验积累，以及高水平技术人员流动，将新游项目全面部署在公有云架构上已经逐步成为行业共识。作为游戏云服务的主要客户，游戏发行商正在充分利用公有云更先进的技术架构、更丰富的高阶产品、以及更便捷的服务调用方式，提高新游上线与版更速度，提升运维效率，并规有效避传统混合架构带来的管理问题。因此，在未发生重大舆情风险、现有监管政策及环境不发生重大变化、以及行业客户使用习惯不发生重大回退前提下，“下游需求将带动游戏云市场规模持续增长”这一结论预计将维持多个周期，2028年中国游戏云市场规模将达到24.4亿美元。
此外调研还显示，除新兴游戏公司全面使用公有云外，老牌发行商亦不断将游戏服、甚至是部分平台服迁移至公有云架构上，也推动云主机用量在过去三年（除2022H1单个周期外）均维持增长态势。
作为中国游戏云基础设施占据最大份额的阿里云，我们发现云原生化成为了当下游戏行业最火热的关键词。莉莉丝、鹰角、灵犀互娱等多家游戏游戏已经使用以Kubernetes为核心的云原生技术在生产环境中支撑了平台服、游戏服等不同业务场景和需求。
莉莉丝三年磨一剑的《剑与远征：启程》[1]于2024年8月8日开启全平台公测，当下热度持续占据各类新游榜单首位。《启程》倾注了开发者团队多年心血，也是莉莉丝游戏首次尝试将放置卡牌的玩法与世界地图结合。《启程》也是莉莉丝游戏采用云原生架构的核心项目，也标志着莉莉丝游戏步入全面云原生化的重要阶段。
Kubernetes作为云原生时代的实施标准，其强大的编排管理的能力，解耦资源与业务，大幅度降低运维人力成本；声明式的运维方式，可实现符合业务预期的重启与自愈，提升系统的稳定性；弹性可扩展特性使资源可以根据需求动态分配，有效地降低闲时的资源浪费。此外，容器的业务承载形态实现了研发环境与测试环境的有机统一，加速了游戏研发迭代的过程，并且在测试阶段就能尽早发现问题，加强了游戏线上的健壮性。资源利用率提高。
通过云原生化改造，莉莉丝将硬件资源利用率提高了40%-60%；发布周期缩短，应用发布时间从几小时缩短到分钟级；运维管理成本降低40%以上。
游戏服弹性应该怎么做
游戏类型与弹性策略
所谓弹性伸缩，即按照业务用量按需使用计算资源。在业务高峰期保证服务质量弹出更多资源，在业务低谷期回收未使用的资源，保障业务稳定的基础上最大程度进行资源优化。游戏服是有状态类服务，不能使用像传统web类型服务完全由基础设施用量决定的弹性策略，其弹性伸缩与游戏服自动化生命周期管理息息相关。从游戏服生命周期管理的角度来看，可以分为两种类型的游戏服：
1. 人为管理
人为控制开服、关服、合服的游戏服。该类游戏服多为区服类游戏，不需要自动化管理游戏服本身的生命周期。此时不需要水平弹性伸缩，一般通过垂直伸缩来解决资源利用率的问题。
2. 自动管理
按需自动化管理自身生命周期的游戏服。而这类游戏也可以细分成两类：
a. 存在对局概念，有明显启停时间节点。玩家与服务只会存在两种状态，如下图所示：1）玩家存在这个对局中；2）对局未开始或已结束，玩家已经不存在这个对局。这两种状态会在对局开始/结束时转化。
b. 不存在明显的对局概念，玩家可随时进入和退出游戏服务器。示意图如下，玩家数量可能会持续增多，游戏服务是否空闲没有确定的时间点。
对于生命周期可以自动化管理的游戏服，我们可以通过水平弹性伸缩来优化资源效率。
游戏服弹性伸缩策略
接下来，我们就从应用层、资源层自上而下来分析这两种场景下完整的弹性伸缩策略。
应用层弹性策略
如上文所述，游戏服是有状态服务，因此我们需要在业务层面对游戏服状态感知、及基于状态的自动处理的挑战。
• 首先，原生Kubernetes工作负载管理Pod支持基础设施状态差异性展示，比如有些Pod处于Ready状态而有些是UnReady的状态，但Kubernetes不支持业务状态差异性管理。这形成了游戏服弹性伸缩在Kubernetes落地的天生阻碍。
• 其次，Kubernetes应用层伸缩机制HPA，也无法根据Pod的状态进行定向缩容，缩容对象不确定将极大提升游戏对局业务受损概率。
这样一来，弹性伸缩作为云原生的重要红利无法充分释放到游戏业务，这也是很多游戏服未进行容器化落地的主要阻碍之一。
22年8月，OpenKruise开源社区面向游戏场景孵化了OpenKrusieGame(简称OKG)子项目，对应的新型Kubernetes工作负载GameServerSet为游戏服管理而设计，致力于解决游戏服Kubernetes落地痛点。
其提供了游戏服精细化状态管理的能力，以应用对上述弹性伸缩上的两个挑战：
• 首先，OKG支持业务状态探测机制。用户可以通过自定义脚本将业务状态灵活地暴露到Kubernetes，其记录在GameServer（Pod游戏服状态的记录者，与Pod一一对应）。
• 其次，OKG支持根据GameServer状态定向缩容，唯有opsState为WaitToBeDeleted的GameServer对应的Pod才会被回收。
这样一来，
• 在游戏服层面，每个游戏服可以上报自身状态，通过自定义服务质量或外部组件来暴露自身是否为WaitToBeDeleted状态。
• 在workload层面，GameServerSet可根据游戏服上报的业务状态来决定缩容的对象，如游戏服水平伸缩中[2]所述，WaitToBeDeleted的游戏服是删除优先级最高的游戏服，缩容时最优先删除。
• 在autoscaler层面，精准计算WaitToBeDeleted的游戏服个数，将其作为缩容数量，不会造成误删的情况。
对于上文中提到第一种【对局启停模式】的游戏服，其生命周期完全由业务决定，也就是说只要实现了由业务定义的状态管理，就可以完成对其的生命周期管理。
此时，业务需定义几种与生命周期有关的状态，联动匹配系统与伸缩系统。例如：
• None——游戏服创建后的初始状态，还没被分配。
• Allocated——游戏服已被分配，说明玩家即将或已经在其中进行游戏。
• WaitToBeDeleted——游戏服使命结束，准备被删除。
随着游戏对局状态的变化，游戏服的状态也随着有所迁移。
1. 当游戏服被创建，默认可用，状态为None，等待被匹配系统分配对局（玩家）
2. 玩家进入游戏服，游戏服状态为Allocated
3. 对局结束，玩家离开，游戏服状态为WaitToBeDeleted
当然，如果希望不频繁的起停Pod，在对局结束后也可以更改OpsState为None。整体状态转化模式如图所示：
1. 同上，房间服被拉起后的默认状态可用，此时OpsState为None
2. 同上，分配房间服后，匹配系统将其设置为Allocated
3. 当对局结束，将OpsState置为None
4. 通过协程判断房间服状态长期处于None状态时，将通过自定义服务质量[3]将OpsState置为WaitToBeDeleted。【可选步骤，即使不设置WaitToBeDeleted，也可以通过OKG提供对的MaxAvailable参数限制None的最大数量，进而实现动态缩容】
对于上文提到第二种【玩家随意进出模式】的游戏服，其生命周期大多数情况由业务决定，也存在一些情况由业务与基础设施共同决定。如果完全交由业务自身决定游戏服的生命周期，那么状态迁移的方式【对局启停模式】是类似的，不再赘述。
但考虑到【玩家随意进出模式】下游戏服生命周期往往较长，很多时候需要结合基础观测指标，配合导流机制来实现整体资源利用率的提升。
比如，在匹配系统或网关均衡分配玩家的情况下，所有游戏服的资源用量相差不大、每个Pod资源水位相对均衡。此时若整体水位较低，则说明存在着较大的资源浪费，需要优雅的缩容方式。OKG提供了上文提到的状态感知以及自定义Lifecycle Hook，通过结合二者可实现完整的游戏服优雅下线方案。如下图所示：
1. 当游戏服平均资源水位低于一定阈值，触发自动缩容逻辑（与HPA相同）。此时OKG会按照水平缩容顺序[4]选择某个(些)游戏服进行下线。
2. 被选中的游戏服并不会直接进入删除状态，而是进入PreDelete，其生命周期此时不会结束。游戏服通过DownwardAPI机制感知到State处于PreDelete，向Allocator发送请求，避免新玩家再次进入该服务。
3. 随着存量玩家的逐渐退出，被选中的游戏服最终处于空闲状态，解除PreDelete卡点，正式进入Delete状态，Pod被删除；而其他Ready的游戏服由于新玩家逐步涌入，资源水位得到提升，资源利用率整体升高。
可以看出，无论是哪种场景，基于业务状态感知、LifeCycleHook，与匹配系统和网关配合就可以实现游戏服应用层的弹性策略，自主且灵活。
资源层弹性策略
当然，游戏服Pod依然需要算力载体，目前弹性算力有两种提供方式：
• ECI Serverless算力
目前是通过ACS的方式进行交付，主要适合轻、小、短的休闲、卡牌等弱状态类型游戏。
• ECS节点算力
目前是通过ACK弹性节点池进行交付，主要适合开MMORPG、SLG、MOBA等重、大、长的强状态类型游戏。
对于强状态类型的游戏而言，对资源层有更高的稳定性、可运维的诉求，例如：
• 降低网络延迟，保证用户的弹性体验；采用Host网络模型的容器可以直接使用宿主机的IP地址与外界进行通信，容器内服务端口也可以使用宿主机的端口，无需额外进行NAT转换，而且由于容器通信时，不再需要通过Linux bridge等方式转发或者数据包的拆封，性能上有很大优势。因此为了获得更好的网路吞吐性能，常常会选择使用Host网络模型。
• 每个节点缩容前完成节点上日志的完整收集，以便后续定位问题。游戏场景下有很多游戏运行中的日志是记录在本地的，在缩容前，游戏用户往往希望游戏服务pod被排水后，可以完整收集游戏运行产生的日志，以便后续问题定位和异常分析。这个机制可以通过Daemonset来实现，在节点资源弹性时候支持了排水Daemonset Pod和等待 Daemonset Pod排水完成，来保证日志收集结束节点再进行缩容。
在阿里云容器服务的场景下，推荐开启即时弹性的节点池[5]来解决上述问题，即时弹性能够为游戏服的弹性提供如下三个保障：
• 高性能：冷启动45s万核规模端到端算力交付，轻松应对峰值冲击。
• 易用性：只需配置一次，无需应用额外适配，白屏化轻松管理。
• 确定性：泛化规格降低库存中断，库存校验减少失败，库存紧张提前预警。
通过即时弹性可实现高确定性的资源供给，结合合理的调度策略即可实现资源的高效利用。至此，一个全面的、从业务需求出发并联动资源层的游戏服弹性方案已然成型。
写在最后
游戏服的容器化是2025年势不可挡的大趋势，游戏服弹性是开发者应对流量冲击、降本增效的必然路径，结合OpenKruiseGame、即时弹性、ACS的能力，让更多的游戏服可以用上弹性、用好弹性，给玩家带来更丝滑的体验。
相关链接：
[1]《剑与远征：启程》
https://afkjourney.lilith.com/
[2] 游戏服水平伸缩
https://openkruise.io/zh/kruisegame/user-manuals/gameservers-scale/
[3] 自定义服务质量
https://openkruise.io/zh/kruisegame/user-manuals/service-qualities/
[4] 水平缩容顺序
[5] 即时弹性的节点池
我们是阿里巴巴云计算和大数据技术幕后的核心技术输出者。
获取关于我们的更多信息~
