Skip to main content
生成别名是生成之上的管理层,它允许对 RequestMultiplayerServer 的调用以受控方式分发到多个生成。这可以提高生成到生成升级和下文列出的其他若干场景的简单性和可靠性。别名通过指定生成 ID 列表以及每个 ID 的权重来实现这一点。权重表示应转发到相应生成的分配调用比率。

向后兼容的安全部署

这是生成到生成升级的最常见场景,即你正在更新游戏服务器,而零售客户端与两台服务器兼容。 客户端将引用别名 1,其配置如下:
  • 生成 1:权重 = 1
创建生成 2 后,别名 1 将更改为:
  • 生成 1:权重 = 8
  • 生成 2:权重 = 2
你可以逐步更改权重,直到所有新的服务器请求都由生成 2 完成。此时,生成 1 的权重为 0,可以从别名中删除。 别名的典型用例是将其绑定到客户端兼容性版本和游戏模式。例如”DeathMatch 客户端 2.2 RETAIL”。别名允许你管理此更高级别的抽象,同时不断更新支持此体验的生成。别名还使你可以在必要时更轻松地回滚生成。

不向后兼容的部署

在这种情况下,你希望在更新游戏客户端的同时更新游戏服务器,因为你当前的游戏客户端与旧的服务器生成不兼容。从一个生成过渡到另一个生成可以按以下方式完成: 旧客户端将引用别名 1,其内容如下:
  • 生成 1:权重 = 1
创建生成 2 后,新客户端将引用别名 2,其内容如下:
  • 生成 2:权重 = 1
在此场景中,别名的使用方式与生成类似,不使用其多路复用功能。

向后兼容的爆炸式部署

这类似于向后兼容的生成到生成升级场景,但需求行为的切换更为突然。从一个生成过渡到另一个生成可以按以下方式完成: 客户端将引用别名 1,其内容如下:
  • 生成 1:权重 = 1
创建生成 2 后,别名 1 将更改为:
  • 生成 1:权重 = 0
  • 生成 2:权重 = 1

测试向后兼容的部署

当你想更新游戏服务器,并且客户端版本与两台服务器都兼容,但你希望先测试第二个版本,然后再为所有玩家大规模部署它时。测试和从一个生成过渡到另一个生成可以按以下方式完成: 客户端将引用别名 1,其内容如下:
  • 生成 1:权重 = 1
创建生成 2 后。测试客户端将引用别名 2,其内容如下:
  • 生成 2:权重 = 1
验证生成 2 后。别名 1 将更改为:
  • 生成 1:权重 = 8
  • 生成 2:权重 = 2
逐步地,生成 2 的权重将增加并吸收所有流量。

回退到其他生成和区域

别名可以通过允许在多个生成之间进行回退,使多人服务器部署更具弹性。例如,假设一个针对生成别名的分配请求将 EastUS 排名为区域 #1,将 West US 排名为区域 #2。此生成别名为两个生成(生成 1 和生成 2)提供了相似的权重。 假设对于给定分配,选择了生成 1。
  1. 尝试在 East US 中为生成 1 分配。
  2. 如果 #1 失败,尝试在 East US 中为生成 2 分配。
  3. 如果 #2 失败,尝试在 WestUS 中为生成 1 分配。
  4. 如果 #3 失败,尝试在 WestUs 中为生成 2 分配。
特别是当你从一个生成逐步升级到另一个生成时,这种回退行为得到了优化,即使其中一个生成出现问题,玩家也能获得延迟最低的服务器。

使用 PlayFab REST API 管理生成别名

你现在可以在 Game Manager 中管理生成别名。若要开始,请参阅生成概述页面
  1. 使用 API 创建生成别名。 API:
    示例正文:
    示例响应:
    生成别名 ID 作为响应的一部分提供。
  2. 更新生成别名的任何参数。 API:
    示例正文:
    示例响应:
  3. 删除生成别名。 API:
    示例正文:
  4. 列出生成别名。 API:
    示例响应:

使用生成别名进行分配

若要使用生成别名进行分配,只需在 RequestMultiplayerServer 调用中指定生成别名 ID。 API:
示例正文:
最后修改于 2026年8月25日