在本文中，我们将介绍适用于所有多人游戏开发者的关键见解，涉及《绝地求生》（Player Unknown's: Battlegrounds）架构从基于大厅的编排向基于容器的游戏服务器编排的迁移。

该演讲由当时在 KRAFTON 担任 DevOps 团队负责人的 JungHun Kim 与 Minsuk Kim 以及 Minwook Chun 于 2024 年共同发表。它重点介绍了他们将《PUBG: Battlegrounds》的基础设施从基于 EC2 的传统服务器转变为完全容器化的 Kubernetes 生态系统的多年历程。

他们的经验为游戏开发者提供了宝贵的见解，但同时也揭示了自行管理如此复杂的基础设施往往被忽视的复杂性和成本。

从传统架构到现代容器化

《PUBG: Battlegrounds》当时是 Steam 上按当前玩家数量排名前三的游戏之一，采用双组件架构运行。

大厅作为匹配、商店运营和个性化定制的入口点。随后，会话服务器负责处理全球分布区域的核心 100 人大逃杀游戏玩法。

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

现代化之旅始于 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 分钟以内。团队通过面向设计师、开发者、QA 工程师和产品经理的 Web UI 获得了自助服务能力。

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

事实证明，迁移生产工作负载远比 QA 环境复杂得多。

生产系统需要实现零数据库清空、平滑迁移策略以及完善的回滚计划。该团队实施了复杂的基于集群的服务发现机制，以同步 IP 地址、服务名称和位置数据。

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

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

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

他们评估了 Agones，这是一个构建在 Kubernetes 上的开源多人游戏服务器编排平台。Agones 像管理 Kubernetes Deployment 一样管理游戏服务器，每个游戏实例对应一个 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 的服务器平均部署时间在冷启动状态下仅需 2 秒：从零开始配置而不是分配到已运行的服务器上，并且测量至容器准备就绪（在游戏引擎启动之前）（平台数据，截至 2026 年 9 月）。这与 KRAFTON 在其 Agones 实现中经历的 15 分钟引导延迟相比，完全不在一个数量级。

这意味着等待部署游戏服务器的玩家必须在当前资源回收时在队列中排队。更具体地说，这意味着游戏服务器无法完成部署，而在队列中等待的玩家会感到沮丧并彻底停止玩你的多人游戏，正如《在线延迟报告》（Online Latency report）指出，34% 的玩家会因此流失。

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

工作室可以将其工程资源集中在游戏开发上，而不是基础设施管理上，同时仍然能获得 KRAFTON 耗费数年才得以高质量实现的性能和扩展优势。

PUBG 是否有专用服务器？

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

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

PUBG 服务器位于何处？

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

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

AWS 的区域定价模型意味着开发者需要单独购买不同位置的服务以确保全球覆盖。

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

结论

游戏开发者应仔细评估构建和管理基于 Kubernetes 的复杂基础设施是否符合其核心能力和资源可用性。

KRAFTON 取得了令人瞩目的成果，正如他们在演讲中所强调的那样，其多年的历程消耗了巨大的工程精力。问题在于，较小的工作室是否承受得起从核心游戏开发中抽调资源的代价。对某些人来说这是一个可行的选择，但某些工作室可能缺乏构建和维护复杂的 Kubernetes 基础设施所需的庞大资源和专属 DevOps 专业能力。

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

—

本文基于并引用了 KRAFTON 发表在此处的原文。原始内容的所有权利均归其各自所有者所有。