本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon GameLift Servers FleetIQ 最佳实践
最佳实践

Amazon GameLift ServersFleetIQ是一个低级逻辑层，可帮助您管理用于游戏托管的 Amazon EC2 资源。特别是，Amazon GameLift Servers FleetIQ 通过最大限度地减少游戏会话中断的可能性，优化了适用于游戏托管的竞价型实例的使用。它还提供基本的游戏托管功能，以跟踪可用的游戏服务器，并将游戏路由到低成本、高可行性的游戏服务器。

Amazon GameLift Servers FleetIQ 作为独立功能，不提供随完全托管式 Amazon GameLift Servers 解决方案一起提供的高级功能，后者也使用 FleetIQ 来尽可能降低托管成本。如果您需要对战、基于延迟的玩家路由、游戏会话和玩家会话管理以及版本控制等功能，请查看 Amazon GameLift Servers 解决方案。

以下是一些可以帮助您从 Amazon GameLift Servers FleetIQ 中获得最大利益的最佳实践。
+ **将 Amazon GameLift Servers FleetIQ 用于基于会话的游戏。**当 Amazon GameLift Servers FleetIQ 不断地将玩家引导到最不可能出现游戏会话中断的实例时，其效果最佳。保持长寿命的会话会干扰 Amazon GameLift Servers FleetIQ 重新平衡过程，从而增加游戏会话可能被中断的几率。理想的工作流程是让玩家从对战（或服务器选择）到进入游戏。游戏结束后，玩家会返回到对战，并路由到新实例上的另一个游戏服务器。我们建议将 Amazon GameLift Servers FleetIQ 用于会话时间少于两小时的游戏。
+ **提供多种实例类型以供选择。**设置游戏服务器组时，您提供要使用的实例类型列表。您包含的实例类型越多，Amazon GameLift Servers FleetIQ 使用高可行的竞价型实例进行游戏托管的灵活性就越大。例如，您可以列出同一个实例系列中的多种大小（c5.large、c5.xlarge、c5.2xlarge、c5.4xlarge）。对于大型实例，您可以在每个实例上运行更多的游戏服务器，从而可能降低成本。对于小型实例，自动缩放可以更快地响应玩家需求的变化。请记住，所需实例类型列表未按优先顺序排列，自动扩缩组将使用可行实例类型的平衡来保持该组的弹性。
+ **在所有实例类型上测试您的游戏。**确保游戏服务器在为游戏服务器组配置的每个实例类型上正常运行。
+ **使用实例容量加权。**如果您将游戏服务器组配置为使用某个实例大小范围（如 c5.2xlarge、c5.4xlarge、c5.12xlarge），请包括每种实例类型的容量加权信息。有关更多信息，请参阅 Amazon Auto Scalin [g *用户指南中的 Amazon A EC2 ut EC2 o Sc* aling 的实例权重](https://docs.amazonaws.cn/autoscaling/ec2/userguide/asg-instance-weighting.html)。
+ **使用 Amazon GameLift Servers FleetIQ 放置您的游戏会话。**使用游戏服务器放置玩家组时，请使用 Amazon GameLift Servers API `ClaimGameServer()`。Amazon GameLift Servers FleetIQ 避免将玩家置于游戏会话中断几率较高的实例上。
+ **向报告游戏服务器状态Amazon GameLift ServersFleetIQ。**使用 Amazon GameLift Servers API `UpdateGameServer()` 定期报告服务器运行状况和利用状态。保持准确的游戏服务器状态有助于 Amazon GameLift Servers FleetIQ 更高效地放置游戏。它还有助于避免在竞价平衡活动期间终止具有活动游戏的实例。
+ **设置自动扩缩策略。**您可以创建目标跟踪扩展策略，以根据玩家利用情况和预期需求维护您的主机容量。Amazon GameLift Servers FleetIQ 指标 `PercentUtilizedGameServers` 用于衡量当前正在使用的托管容量。大多数游戏希望维护未使用的游戏服务器的缓冲区，以便新玩家能够快速进入游戏。您可以创建一个保持特定缓冲区大小的扩展策略，随着玩家需求的波动添加或删除实例。有关更多信息，请参阅 Amazon A EC2 uto [Scaling 用户指南中的目标跟踪扩展策略](https://docs.amazonaws.cn/autoscaling/ec2/userguide/as-scaling-target-tracking.html)。
+ **在开发和生产环境中使用不同的 Amazon 帐户。**跨账户将您的开发配置与生产配置分开，可以减少影响现场玩家的配置错误风险。
+ **为使用中的游戏服务器组启用游戏会话保护。**为了保护玩家，请打开游戏会话保护，防止活动游戏会话因扩展或平衡活动而提前终止。
+ **在与游戏集成 EC2 之前，请先对其进行测试Amazon GameLift ServersFleetIQ。**我们建议您先启动并运行游戏 EC2 并微调配置。然后，您可以使用相同的启动模板和 AMI 创建游戏服务器组。

  如果您使用的是 Kubernetes，我们建议您先将标准 EC2 实例添加到 Kubernetes 集群，然后使用您为 Kubernetes 集群中的工作节点创建的启动模板创建游戏服务器组。如果您使用的是 EKS，请单独创建 EKS 集群和游戏服务器组。对于游戏服务器组，请将 EKS 优化的 AMI 与合适的用户数据以及用于 EKS 集成的启动模板配置结合使用。在 [Amazon EKS 优化 Linux AMI](https://docs.amazonaws.cn/eks/latest/userguide/eks-optimized-ami.html) 指南中可查看有关 EKS 工作线程节点和 EKS 优化 AMI 的更多信息。
+ **使用游戏服务器组平衡策略 `ON_DEMAND_ONLY` 获得可靠的游戏服务器可用性。**此平衡策略生效后，将不使用竞价型实例。这是一个有用的工具，可以确保服务器在您最需要的时候（例如在特征发布或其他特殊活动期间）的可用性。您可以根据需要将游戏服务器组从竞价型策略切换到按需型策略。

另请查看以下 Amazon 最佳实践：
+ [Amazon 的最佳实践 EC2](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ec2-best-practices.html)
+ [Amazon A EC2 uto Scaling 的最佳实践](https://docs.amazonaws.cn/autoscaling/ec2/userguide/gs-best-practices.html)