最佳实践与发布检查清单

• 在游戏会话结束时（例如比赛结束或最后一个已连接玩家离开时）让您的游戏服务器进程退出。如果您的游戏允许玩家重新连接，请先等待一小段宽限期。MPS 不会替您结束游戏会话。服务器在其进程退出之前一直保持 Active 状态。当您的生成缩减规模时，MPS 不会移除 Active 服务器，因此一个从不退出的服务器会持续占用您需要付费的容量。当进程退出时，MPS 会用新服务器替换它。有关详细信息，请参阅多人服务器的生命周期。
• 在服务器变为 Active 时（例如游戏服务器 SDK (GSDK) 的 ReadyForPlayers 方法返回 true 时）启动一个计时器。如果几分钟内没有玩家连接，则退出进程。这样，无论出于何种原因无人加入的服务器都不会无限期地保持 Active 状态。请根据玩家通常需要多长时间进行连接来设置超时。
• 注册一个 GSDK 关闭回调，执行服务器所需的任何清理工作，然后退出进程。GSDK 不会替您退出进程。当您调用 ShutdownMultiplayerServer API 时，MPS 会调用您的回调。仅在紧急情况下调用此 API，例如终止卡住的游戏服务器。在正常情况下，不要使用它来结束游戏会话。您的游戏服务器应自行退出，如本节前面所述。如果在关闭请求发出 15 分钟后进程仍在运行，MPS 会强制终止它。有关详细信息，请参阅正常关闭游戏服务器。

​

开发

• 使用 LocalMultiplayerAgent (LMA) 在本地工作站上进行迭代测试。这既节省时间又节省成本，同时由于所有产物都在本地运行，也简化了调试。该工具已开源，欢迎贡献和增强。有关详细信息，请参阅在本地调试游戏服务器以及与 PlayFab 的集成。
• 使用计划设置具体的调度计划，以节省 standingBy 服务器成本。例如，如果所有测试和验证都是在工作时间进行的，可以将计划设置为仅在工作时间内保留 standingBy 服务器。设置计划不产生额外费用。
• 使用 VM 指标或您自己的分析器来确定在您所选大小的单个 VM 上运行多少个游戏服务器。在 VM 上的每个服务器都处于 Active 状态且满员的情况下进行负载测试。同一 VM 上的服务器可能几乎同时被分配并开始其游戏会话，因此请在测试中包含这种情况。请预留 CPU 余量：在 CPU 已饱和的 VM 上，分配可能会很慢或失败。
• 使用服务器日志和崩溃转储进行深入分析。

​

发布准备

• 将您的分配请求调整为面向生成别名。它们有助于在服务器更新过程中将游戏客户端无缝迁移到较新的游戏服务器，还可以帮助管理配额问题（稍后讨论）。
• 使用 QoS 信标跟踪游戏客户端最近的区域，并利用该信息进行分配。这些还可以与 PlayFab 匹配 结合使用，将具有相似延迟的客户端分组在一起，并为它们分配最近的服务器。
• 充分利用 PlayFab MPS 的完整地理覆盖范围，以确保游戏服务器始终位于玩家附近。考虑在一个地理区域内使用多个区域，以在发生区域性故障时提供更高的可用性。例如，在 NorthEurope 和 WestEurope 都有服务器，并在分配请求中（按优先级顺序）指定这两个区域，可以让在一个区域失败的分配在列表中的下一个区域成功。
• 当您针对生成别名进行分配时，请在 PreferredRegions 中按偏好顺序列出能为玩家提供可接受体验的每个区域。MPS 按该顺序尝试您的区域，生成权重仅决定在某个区域内由哪个生成处理请求。权重为 0 的生成永远不会被使用，即使作为回退也不会。有关详细信息，请参阅回退到其他生成和区域。
• 如果 RequestMultiplayerServer 失败并返回 MultiplayerServerTooManyRequests 错误，则表示在任何请求的区域中都没有生成具有 StandingBy 服务器。尽管名称如此，此错误并不表示您的请求受到了限流。若要避免此错误：
  • 在 PreferredRegions 中列出多个邻近区域。
  • 根据预期峰值设置备用服务器。
  • 为每个生成区域设置最大服务器数，并在预期峰值之上留出余量。即使备用服务器耗尽，MPS 也不会创建超出该最大值的服务器。
• 在发布之前尽早为生成所使用的每个 VM 系列和区域请求配额。当您推出新生成时，在旧生成的服务器耗尽之前，旧生成和新生成会同时使用核心，因此请为两者请求足够的配额。若要分散容量，请考虑将使用不同 VM 系列的生成放在同一个别名之后，以便分配可以回退到同一区域中的另一个 VM 系列。
• 可能存在您的游戏服务器所选的虚拟机 SKU 并非在游戏预定发布的所有区域中都可用的情况。在这种情况下，可以使用别名按 SKU 和区域拆分生成，或在单个生成中使用区域覆盖，仅为这些区域选择不同的虚拟机 SKU。
• 使用动态 StandingBy 根据需求扩展游戏服务器。这与默认的静态 standingBy 配置相结合，可以提供一种经济高效的方式来应对发布期间的高需求。
• 在发布之前为游戏服务器设置监视。打开 VM 指标，即可在 Game Manager 中查看 VM 的 CPU、内存、磁盘和网络指标。若要进行更高级的监视，请使用 VmStartupScript 在 VM 上安装您自己的监视工具。VmStartupScriptGallery 存储库提供了将 VM 指标和游戏服务器日志发送到 Azure Monitor、Application Insights 和 Azure Data Explorer 等服务的示例。

​

发布日

• 通过 PlayFab Game Manager 中的仪表板和事件流跟踪您游戏的成功发布。花些时间庆祝一下，这是您应得的！

​

发布后

• 游戏往往会形成一个需求节奏，可以再次编排为计划。使用计划与动态 StandingBy 相结合，实现经济高效的发布后游戏扩展。
• 使用生成别名进行游戏服务器更新，并逐渐将流量转移到新的游戏体验。
• 当您将别名迁移到新生成时，请将旧生成的备用服务器设置为 0，以便 MPS 可以释放其空闲 VM。仅在旧生成的 Active 服务器耗尽后再删除旧生成。此外，请使客户端请求的区域与别名中生成所部署的区域保持同步。如果别名中的所有生成均未部署在任何请求的区域中，请求将失败并返回 MultiplayerServerNotFound。