从今年11月开始，亚马逊网络服务 (AWS) GameLift 现在支持完全托管的容器（整整 在我们抱怨它缺乏这些功能五年之后），这最终使开发者能够使用容器，比如 Docker 的容器，在 GameLift 的编排上部署他们的游戏服务器，以便托管和扩展多人游戏服务器。

我们来分析一下，并更重要地问一下——添加容器是否足够真正改善多人游戏的编排和玩家的在线游戏体验。

AWS Gamelift 的多人游戏容器是什么

通过使用亚马逊弹性 Kubernetes 服务 (EKS) 或与 GameLift 编排集成的弹性容器服务 (ECS)，游戏开发者可以管理波动的玩家负载并简化部署。

这种设置允许开发者自定义游戏托管环境，自动扩展，并处理对多人游戏至关重要的复杂网络需求。

GameLift 还增强了玩家匹配和会话管理，提供优化玩家体验的工具。通过这种基于容器的服务架构，开发者获得了操作灵活性，更加专注于游戏玩法，而不那么专注于基础设施。

AWS 对 ECS 容器在 Gamelift 上的多人游戏没有说明的内容

AWS Gamelift 支持容器，但在游戏服务器编排优化的关键领域仍然缺乏透明度，这有助于工作室减少托管成本并最大化在线游戏体验——即分配、扩展、区域分布、匹配和集成与使用的简单性。

分配

首先，AWS 不清楚 Gamelift 中的分配是如何工作。

分配是虚拟机（VM）上游戏服务器占用的空间。除了对游戏工作室来说这是一个痛苦的集成过程外，这意味着优化虚拟机的游戏服务器“填充”以最大化每个 vCPU 的使用是一项挑战。

这种缺乏透明度意味着工作室为未使用的容量付费，以及额外的 DevOps 成本，因为需要管理补位。

其次，您仍然有至少 30% 的开销，因为 Gamelift 必须预热虚拟机，以便舰队容器可以启动容器。虽然您可以在 Gamelift 中设置较低的值，但这样会导致扩展期间长时间（即：破坏玩家体验的持续时间）的容量不足。

注意 Gamelift 的计算器；默认设置的开销为 10%，而我们从未在实际使用中看到过这样的情况，以及需要您的游戏二进制文件（和游戏模式）支持在几分钟内关闭的现货实例。

这具体意味着，如果您不使用足够大的服务器，就会导致不良的玩家体验，例如由于服务器超载而导致的延迟和掉帧。在那种情况下，您可能会更愿意使用对等网络（P2P）。

在 Edgegap，我们为自己能够为游戏开发者提供 优化他们的游戏服务器并分配他们的 vCPU 使用 以降低总体成本感到自豪。 

扩展

AWS 没有明确其虚拟机的扩展是如何工作的。Gamelift 的主要价值主张是按需扩展虚拟机的能力，但他们在文档中根本没有提到这对容器的适用性。 

如果他们预启动容器，那么我们又回到了扩展的问题；他们如何知道何时扩展，因为容器已经在机器上占用空间？

如果他们在运行中部署容器，这样的速度是多快（游戏服务器的垂直扩展），并且它在所选区域间是如何工作的（水平扩展）？

Edgegap 提供了按需容器部署，保证最高可达 40 个游戏服务器的部署，持续 60 分钟。AWS 是 Edgegap 的供应商之一，但它还使用 16 个供应商（截至撰写时）在所需位置进行垂直扩展。

此外，Edgegap “冷启动”服务器的平均时间为 3 秒——这意味着游戏服务器部署时更多的游戏时间和更少的等待时间。相比其他地方报告的 10 秒以上，显著提升了任何在线游戏的生活质量。

与 AWS 不同，Edgegap按需将您的游戏服务器部署到其 615 多个全球位置。虽然在美国东海岸的玩家在 AWS-US-East 进行扩展是很棒的，但实际上，您的游戏托管需要在全球范围内上下扩展，以为全球玩家提供良好的在线游戏体验。

区域分配

公共云，包括 AWS，让您为虚拟机（无论您是否运行游戏服务器）付费，您将不得不为希望在其中存在的每个区域付费。

想要 10 个区域，这将是“AA”或“三级独立游戏”的最低需求，以保持玩家享受游戏的延迟在足够低的水平？您需要至少支付 10 x C5 大型虚拟机的费用。

这种传统的托管方式意味着，即使您是完全支付的服务器中的共用租户，这也可能会轻松 提升您的成本 5-8 倍。

新一代游戏服务器托管编排服务，如 Edgegap，采用按使用付费的方式。它意味着您 仅在玩家游戏时付费（即，在部署期间）以全球相同的价格。在定价方面真正改变游戏规则。

此外，随着 Edgegap 利用全球最大的边缘网络，它能够相对于传统公共云编排提供 平均 58% 的延迟降低。

与匹配/大厅的使用

另一个挑战是您的匹配器或大厅需要选择哪个位置是最佳的。您必须在匹配器中创建区域，您尝试降低延迟（通过在 AWS 中添加区域），排队时间将会更长，因为您将无法进行跨区域匹配。

Edgegap 的匹配器是 默认情况下唯一具有基于延迟参数的匹配器，这有助于为您的玩家部署最低延迟的游戏服务器。

集成和使用的简便性

AWS 对简单性的定义是一篇关于解释其工作方式需要 10 页的博客文章。

不幸的现实是，它需要您集成和配置 Gamelift，这本身就是一个挑战，以及一整套将编排容器的 ECS。

一旦集成工作完成，这只是开始——您将需要至少 1 名工程师或 DevOps 来观察并管理您的流量的起伏。

此外，目前也不清楚您是否可以对每个容器执行自定义元素，例如，注入环境变量。

“及时”游戏服务器的优势在于加载数据，使用户生成内容（UGC）完全自定义，完全回避了这个问题。例如，六天的福尔哈吉 在游戏服务器部署期间加载其完全程序生成的地图，或者 HIBERWORLD 的数十万种 UGC 开发的游戏类型和地图。

容器是否足够 AWS Gamelift？

对于目前使用 Gamelift 的游戏，并希望因为它们的易用性而迁移到容器的情况，这也许足够了。

不幸的是，如果您想要一种更灵活的解决方案，使您能够以及时、按需的方式利用数百个位置（并且不必管理任何内容），您可能应该考虑新一代游戏服务器编排服务——包括 Edgegap。