缩放备用
PlayFab 的缩放功能使开发人员能够调整游戏服务器托管容量以满足实际玩家需求。 这些控制可以帮助开发者有效地降低游戏服务器托管成本，同时保持足够的容量，以便在最短时间内快速添加新玩家加入多人游戏。
在成功部署和运行游戏后，开发人员会考虑缩放游戏服务器。 本节中演示的控件可帮助开发人员定义资源缩放的弹性，同时保持足够的容量，无需等待就添加新玩家。
处于支持状态和备用状态的服务器将按游戏计费，你将需要优化这些流程以降低成本。 在我们开始如何计算目标备用之前，这里有一些需要理解的有用术语。
术语
有关缩放备用服务器应了解的术语。
- 目标备用 - 通常也称为备用目标并按目标定位，它是平台设置的值，用于指定备用服务器的目标数量，以避免备用池耗尽。
- 目标备用底层 – 一种游戏开发人员可配置的度量值，表示为满足对新游戏服务器的需求而保持空闲的服务器的最小底层数量。
- 实际备用 – 多人服务器平台报告的备用服务器数量，其值在启用动态备用和禁用动态备用之间是不同的。
- 预部署 - Azure 和 PlayFab 必须创建虚拟机、初始化其操作系统，并配置其环境。 在将虚拟机分配给客户并计费之前，PlayFab 首先驱动此预支持活动。
- 支持 - 必须加载游戏服务器资产，并且游戏服务器应用程序本身通常需要一段时间来为玩家做好准备。
- 备用为了立即满足多人游戏服务器的需求，一些服务器会处于闲置状态，以等待玩家随时使用。
配置目标备用
你可以按每个内部版本和每个区域配置待机目标。 通常情况下，应该根据支持时间和目标分配率按比例设置备用级别：按目标备用 = （支持时间 + 服务器备用时间） * 目标分配率
例如，假设一台 Linux 服务器需要 100 秒来支持，一个游戏预计每 5 秒钟最多分配 1 台服务器（即 0.2 台服务器/秒）。 则 100 * 0.2 = 20 台服务器的待机池将对此内部版本提供稳定支持。 100 秒后，20 台服务器将会用尽，但将有时间再生成另外 20 台。
调用 RequestMultiplayerServer API 时，必须指示玩家体验可接受的所有区域。 如果区域 #1 没有可用的备用服务器，则将请求区域 #2，并将继续请求已配置的所有区域。
缩放优势
缩放优势摘要包括：
| 优势 | 说明 |
|---|---|
| 提高应用程序可用性 | 通过主动预配容量，确保你的游戏服务器池总是拥有合适的虚拟机数量 |
| 降低计算成本 | 仅在需要优化成本时添加实例 |
| 跨购买选项缩放实例 | 缩放选项可优化实例类型、区域、大小和游戏服务器生成配置的性能 |
缩放方法
PlayFab 提供多种机制来缩放服务器的缩放时间和方式。 游戏开发人员可以灵活执行以下操作：
- 配置最小阈值和最大阈值
- 根据服务器编译配置文件自定义缩放配置，例如 (a) 实例类型、(b) 虚拟机大小或 （c） 区域
- 从开发人员门户或从 Multiplayer Servers RESTful API 轻松管理更改
- 监视服务器和使用情况图表中的缩放指标
配置游戏服务器缩放的 3 种方法包括：
- 默认
- 计划
- 动态
每个游戏都有独特的方法，但都是由已知或未知的玩家需求状态触发的。 默认方法扩展到配置的最大服务器，并在会话完成时缩减到最小。 在此机制中，开发人员无需执行任何其他步骤。 这是开发者设置最大服务器和备用限制的最简单方法，这样 PlayFab 就可以根据玩家需求自动减少和增加虚拟机。
| 控件 | 玩家需求 | 方法 | 用例 | 产出 |
|---|---|---|---|---|
| 默认 | 不可预知 | 自动 | 正常游戏操作 | 缩放速度不够快，无法应对流量高峰 |
| 计划 | 可预测 | 已计划 | 计划的事件启动 | 跟踪玩家需求中班次的计划更改 |
| 动态 | 不可预知 | 公式化 | 突然的流量高峰 |
为了充分理解扩展选项的广度，必须首先理解以下关键概念和术语。
重要概念
- 缩放机制控制可用备用服务器的数量
- 备用服务器是 VM 分配的服务器，没有活跃的连接玩家。 在响应 RequestMultiplayerServer API 调用时过渡为玩家连接；当游戏服务器进程退出时，它们转换到终止状态
- 缩放机制在编译的每个区域中唯一应用
- 每个缩放配置都表示为区域替代
备用池耗尽
PlayFab 的多人游戏服务器提供一组备用服务器。 这有助于立即满足其他游戏服务器的请求，以响应玩家需求。 如果对额外服务器的需求增长快于从储备中获取和供应服务器所需的时间，备用服务器池就会耗尽。 可用服务器池进入“不足”状态，对游戏服务器的请求将失败，直到可以预配其他服务器。 计划备用和动态备用缩放方法会自动激活增加的游戏服务器供应，以满足玩家的需求。