在本文中，我们将介绍对所有多人游戏开发者都适用的关键洞察，内容涉及 Player Unknown's: Battlegrounds 从基于大厅到基于容器的游戏服务器编排架构迁移。

这场演讲于 2024 年由时任 KRAFTON DevOps 团队负责人 JinHun Kim 与 Minsuk Kim、Minwook Chun 共同发表。演讲重点介绍了他们历时多年的转型历程：将 PUBG: Battlegrounds' 基础设施从传统的基于 EC2 的服务器迁移到完全容器化的 Kubernetes 生态系统。

他们的经验为游戏开发者提供了宝贵见解，同时也揭示了自主管理这类复杂基础设施时常被忽视的复杂性与成本。

从传统架构到现代容器化

PUBG: Battlegrounds 在当时按同时在线玩家数位列 Steam 前三，采用了双组件架构。

大厅作为匹配、商店运营和自定义的入口。随后，会话服务器在全球分布式区域中承载核心的 100 人大逃杀玩法。

KRAFTON 的 DevOps 团队负责人 JungHun Kim 解释了他们最初的挑战：“QA 环境创建工作流”需要 20 分钟到 1 小时，DevOps 团队才能完成新测试环境的配置。这个瓶颈严重影响了开发速度和团队生产力。

现代化之旅始于 2018 年 11 月的会话服务器，随后是 2019 年 10 月的大厅服务器，并于 2023 年 6 月以采用基于 ARM 的处理器服务器告一段落。每个阶段都解决了特定痛点，同时也引入了新的复杂性。

KRAFTON 的首次突破来自于认识到传统的基于 EC2 的 QA 环境资源消耗大且难以共享。每个环境都需要大量 AWS 服务：EC2 实例、CodeDeploy、CloudFront、Elastic Load Balancing、DynamoDB、ElastiCache、OpenSearch、Kinesis、Data Firehose、SQS、VPC、Auto Scaling、Route 53、IAM 和 S3。

他们的解决方案是在 Amazon EKS 中将这些服务容器化，并创建共享与专用资源类别。这一架构转变将 QA 环境创建时间从 20-60 分钟缩短至 5 分钟以内。团队通过 Web UI 获得了自助能力，设计师、开发者、QA 工程师和产品经理都可访问。

生产迁移与服务网格复杂性

将生产工作负载迁移过去被证明比 QA 环境复杂得多。

生产系统需要零数据库清空、平滑迁移策略以及全面回滚方案。团队使用集群实现了复杂的服务发现机制，以同步 IP 地址、服务名称和位置信息。

然而，迁移期间出现了流量均衡问题。连接池导致服务间负载分布不均，迫使团队采用 Istio 服务网格来实现动态流量管理、增强安全性并提升可观测性。

会话服务器编排：Agones 及其局限性

与无状态大厅服务相比，会话服务器带来了独特挑战。每个会话服务器运行 Unreal Engine 专用服务器，在无持久化存储的情况下维护游戏状态。KRAFTON 需要扩展到数十万并发会话，同时保持一致的响应时间和成本效率。

他们评估了 Agones——一个构建于 Kubernetes 之上的开源多人游戏服务器编排平台。Agones 像 Kubernetes 部署一样管理游戏服务器，每个游戏实例对应一个 GameServer Pod。Fleet 管理 GameServer 组，而 FleetAutoscaler 负责容量管理。该架构通过共享 Kubernetes 集群实现了高级装箱（bin-packing）能力，并可借助命名空间让多个环境在同一集群中共存。

尽管 KRAFTON 取得了令人印象深刻的技术成果，但根据 JungHun Kim 的说法，Agones 面临一个重大挑战：15 分钟的服务器引导时间在扩容事件中成为瓶颈。拆解时间线后发现有多重延迟叠加：实例配置（1-3 分钟）、实例引导（2-3 分钟）和 Pod 配置（5-10 分钟）。在玩家需要服务器立即可用的高峰时段，这些延迟造成了扩容困难。

KRAFTON 的解决方案需要大量工程投入。他们采用 Karpenter 以减少 EC2 启动延迟，并通过 Harbor、S3 缓存和 CloudFront 分发实现了容器镜像仓库代理。这些优化将引导时间从 15 分钟以上降至 3-4 分钟，但也需要深厚的 Kubernetes 专业能力和持续维护。

自主管理的隐性成本

KRAFTON 的技术成就和成功显而易见。对于没有 KRAFTON 规模的工作室而言，成本与复杂性是必须考虑的问题。

将 Karpenter 作为开源方案进行管理需要专门能力，而很多工作室可能并不具备。KRAFTON 团队需要跨多个领域的专业知识：Kubernetes 网络、Istio 服务网格配置、游戏服务器管理、容器镜像仓库优化以及多架构构建系统。

这些优化需要深厚的 Kubernetes 专业能力和持续维护。KRAFTON 的专职 DevOps 团队证明了他们可以管理这种复杂性并取得成功，但较小工作室面临显著的资源限制。因此，小型工作室必须自问——他们是否能够在保持游戏开发重心的同时，投入足够资源掌握这些技术。

这段基础设施之旅消耗了多年专门工程投入。这是一项显著的机会成本，工作室应结合自身路线图优先级谨慎权衡。

更简单的前进路径？

与其复制 KRAFTON 复杂的基础设施演进历程，游戏开发者应考虑像 Edgegap 游戏服务器编排平台 这样的全托管方案。同时，得益于其高度优化的多租户共享方案，所有使用 Edgegap 平台的游戏都可将游戏服务器冷启动时间平均控制在 3 秒，据 Edgegap CTO Philip Cote 称，这消除了 KRAFTON 在其 Agones 实现中经历的 15 分钟延迟。

这意味着等待部署游戏服务器的玩家必须在队列中等待当前资源被回收。更具体地说，这意味着游戏服务器无法及时部署，排队玩家会感到沮丧并停止游玩你的多人游戏——其中 34% 会流失，依据 Online Latency 报告。

Edgegap 平台可在60 分钟内自动扩展到 1400 万并发用户，远超大多数游戏需求。更重要的是，它免去了由专门 DevOps 团队管理 Kubernetes、容器镜像仓库、服务网格和扩缩容算法的需求。

工作室可以将工程资源专注于游戏开发而非基础设施管理，同时仍能获得 KRAFTON 花费多年实现的高质量性能与规模收益。

PUBG 是否使用专用服务器？

是的，PUBG: Battlegrounds 的大厅和会话组件完全运行在专用服务器上。与点对点网络不同，专用服务器可提供权威游戏状态管理、反作弊能力，以及不受单个玩家连接质量影响的一致性能。

会话服务器运行 Unreal Engine 专用服务器实例，每个实例处理一场 100 人对局。这些有状态服务器管理所有游戏逻辑、物理计算和玩家交互，且不依赖对局间的持久化存储。大厅服务器使用无状态的 .NET 微服务并连接到托管存储后端，从而实现水平扩展与容错。

PUBG 服务器位于哪里？

PUBG 运营着全球分布式服务器基础设施，会话服务器部署在多个 AWS 区域。大厅服务集中在“us-east-1”，作为用户管理和匹配操作的中心枢纽。

会话服务器会根据玩家需求和地理分布动态部署。这种方式通过将游戏服务器放置在更靠近玩家群体的位置来降低延迟，从而提升这种分秒必争游戏中的竞技体验。该地理分布策略在保持大厅集中运营的同时，平衡了成本效率与性能要求。

AWS 的区域定价模型意味着开发者需要逐个购买地区以确保全球覆盖。

需要现代化解决方案的游戏开发者也可以使用 Edgegap 的编排平台，它接入了全球最大且首个无区域网络。这意味着你的多人游戏可以将服务器部署到全球 615+ 个地点，并以单一价格提供服务，这使 Edgegap 能够平均降低 58% 延迟，并为 78% 的玩家群体提供低于 50ms 的延迟。

结论

游戏开发者应认真评估，构建并管理复杂的基于 Kubernetes 的基础设施是否符合其核心能力与资源状况。

KRAFTON 取得了令人印象深刻的成果，但正如他们在演讲中强调的那样，这段多年历程消耗了大量工程投入。小型工作室是否能够承担偏离核心游戏开发的代价，是一个值得思考的问题。对某些团队而言这可能是可行选择，但有些工作室可能缺乏构建和维护复杂 Kubernetes 基础设施所需的大量资源与专职 DevOps 专业能力。

像 Edgegap 这样的全托管平台可提供同等性能收益（即时扩展、全球分发和低延迟），无需专门的基础设施团队或数年的实施工作。通过此类平台提供的精简集成，工作室可以获得 KRAFTON 级别的基础设施能力，同时让优秀开发者专注于打造卓越游戏体验，而不是管理容器编排系统。

---

本文基于并引用了 KRAFTON 发布的原文，见此处。原始内容的所有权利归各自所有者所有。