以下是在游戏生命周期的各个阶段中充分利用 PlayFab MPS 的一些最佳做法：
开发
使用 LocalMultiplayerAgent (LMA) 对本地工作站进行迭代测试。 这既节省了时间，又节省了资金，同时简化了调试，因为所有项目都在本地运行。 该工具是开放源代码的，并且始终欢迎提供/增强功能。 此处提供了 有关使用它的更多详细信息
使用 计划 来设置具体的计划，以节省常用服务器成本。 例如，如果所有测试和验证都是在工作时间内执行的，则只能在工作时间内将计划设置为具有备用服务器。 设置计划无需额外费用。
使用 服务器日志 和 故障转储进行更深入的 分析。
发布准备
针对生成别名定制分配请求。 它们有助于在服务器更新过程中将游戏客户端无缝迁移到较新的游戏服务器，还有助于管理配额问题（稍后讨论）。
使用 QoS 信标 跟踪游戏客户端最近的区域，并使用该区域进行分配。 它们还可以与 PlayFab 匹配 相结合，将具有类似延迟的客户端组合在一起，并分配最靠近它们的服务器。
使用 PlayFab MPS 的完整地理覆盖范围，确保游戏服务器始终靠近玩家。 考虑在地理区域中使用多个区域，以便在发生区域故障时提高可用性。 例如，在 NorthEurope 和 WestEurope 中使用服务器并在分配请求中指定这两个区域（按优先级顺序）允许在一个区域中失败的分配在列表的下一个区域中成功。
确保已请求并已 批准为游戏服务器选择的虚拟机 SKU 的配额 。
在某些情况下，游戏服务器的虚拟机 SKU 在游戏设置为启动的所有区域都不可用。 在这种情况下，请使用别名按 SKU 和区域拆分生成，或在单个生成中使用区域替代，仅针对这些区域选择不同的虚拟机 SKU。
使用 Dynamic StandingBy 根据需要纵向扩展游戏服务器。 这结合了默认的静态常用By 配置，可以提供一种经济高效的方式来处理启动期间的高需求。
午餐日
- 在 PlayFab Game Manager 中使用仪表板和事件流跟踪游戏的成功启动。 请花些时间来庆祝，你已经获得了它！
投放市场后
游戏往往会进入一种可再次组成 日程安排的需求节奏。 将计划与 Dynamic StandingBy一起使用，实现经济高效的发布后游戏缩放。
使用 生成别 名进行游戏服务器更新，并逐渐调整流向新游戏体验的流量。