Pular para o conteúdo principal
Um alias de build é uma camada de gerenciamento sobre os builds que permite que as chamadas a RequestMultiplayerServer sejam distribuídas entre vários builds de forma controlada. Isso pode melhorar a simplicidade e a confiabilidade das atualizações de um build para outro e de vários outros cenários listados abaixo. Os aliases fazem isso especificando uma lista de IDs de build junto com o peso de cada um. O peso de um build define a probabilidade de esse build ser tentado primeiro em cada solicitação de alocação. Por exemplo, se o Build 1 tiver peso 8 e o Build 2 tiver peso 2, o Build 1 será tentado primeiro em cerca de 80% das solicitações e, portanto, atenderá cerca de 80% delas enquanto tiver servidores StandingBy. Se o Build 1 ficar sem servidores StandingBy em uma região, essas solicitações irão para o Build 2, de modo que o Build 2 poderá atender mais de 20% das solicitações nessa região. No entanto, as regiões de cada solicitação têm prioridade, e os pesos apenas decidem qual build atende a uma solicitação dentro de uma região. Para obter detalhes, consulte Fallback para outros builds e regiões.

​
Implantação segura compatível com versões anteriores

Este é o cenário mais comum de atualização de um build para outro, em que você está atualizando o servidor de jogo e os clientes de varejo são compatíveis com os dois servidores. Os clientes farão referência ao Alias 1, que teria a seguinte configuração:
  • Build 1: Weight = 1
Depois que o Build 2 for criado, o Alias 1 será alterado para:
  • Build 1: Weight = 8
  • Build 2: Weight = 2
Você pode alterar os pesos gradualmente até que todas as novas solicitações de servidor sejam atendidas pelo Build 2. Nesse ponto, o peso do Build 1 será 0 e ele poderá ser removido do alias. Um caso de uso típico de um alias é associá-lo a uma versão de compatibilidade do cliente e a um modo de jogo. Por exemplo, “DeathMatch client 2.2 RETAIL”. Os aliases permitem gerenciar essa abstração de nível mais alto enquanto você atualiza continuamente os builds que alimentam essa experiência. Os aliases também facilitam a reversão de builds, se necessário.

​
Implantação não compatível com versões anteriores

Nesse caso, você quer atualizar o servidor de jogo ao mesmo tempo em que atualiza os clientes do jogo, pois seus clientes de jogo atuais não são compatíveis com o build de servidor antigo. A transição de um build para outro seria feita da seguinte forma: Os clientes antigos farão referência ao Alias 1, que teria o seguinte:
  • Build 1: Weight = 1
Depois que o Build 2 for criado, os novos clientes farão referência ao Alias 2, que teria o seguinte:
  • Build 2: Weight = 1
Nesse cenário, os aliases são usados de forma semelhante aos builds, e a funcionalidade de multiplexação deles não é usada.

​
Implantação imediata compatível com versões anteriores

Este cenário é semelhante ao de atualização de um build para outro compatível com versões anteriores, mas com uma mudança mais repentina no comportamento de demanda. A transição de um build para outro seria feita da seguinte forma: Os clientes farão referência ao Alias 1, que teria o seguinte:
  • Build 1: Weight = 1
Depois que o Build 2 for criado, o Alias 1 será alterado para:
  • Build 1: Weight = 0
  • Build 2: Weight = 1

​
Testando uma implantação compatível com versões anteriores

Quando você quer atualizar o servidor de jogo e a versão do cliente é compatível com os dois servidores, mas deseja testar a segunda versão antes de implantá-la em escala para todos os jogadores. O teste e a transição de um build para outro poderiam ser feitos da seguinte forma: Os clientes farão referência ao Alias 1, que teria o seguinte:
  • Build 1: Weight = 1
Depois que o Build 2 for criado, os clientes de teste farão referência ao Alias 2, que teria o seguinte:
  • Build 2: Weight = 1
Depois que o Build 2 for verificado, o Alias 1 será alterado para:
  • Build 1: Weight = 8
  • Build 2: Weight = 2
Gradualmente, o Build 2 receberia mais peso e absorveria todo o tráfego.

​
Fallback para outros builds e regiões

Os aliases podem tornar suas implantações de servidores multijogador mais resilientes, permitindo fallback entre vários builds. Ao solicitar um servidor de um alias, liste em PreferredRegions, em ordem de preferência, todas as regiões que oferecem uma experiência aceitável aos seus jogadores. O PlayFab Multiplayer Servers (MPS) trata cada solicitação da seguinte forma:
  1. O MPS usa os pesos dos builds para ordenar os builds do alias para a solicitação. Um build com peso maior tem mais probabilidade de vir primeiro.
  2. O MPS percorre suas regiões na ordem em que você as listou. Em cada região, ele tenta todos os builds nessa ordem. Ele ignora builds que não estão implantados na região.
  3. O MPS aloca um servidor do primeiro build que tiver um servidor StandingBy. Se nenhum build tiver um na região, o MPS passa para a próxima região. Se nenhuma região tiver um, a solicitação falhará com o erro MultiplayerServerTooManyRequests.
A ordem das regiões sempre tem prioridade sobre os pesos dos builds. Os jogadores recebem um servidor na região mais preferida que tiver capacidade, e os pesos apenas decidem qual build os atende nessa região. Use os pesos para expressar suas preferências de custo e desempenho entre builds, por exemplo, entre tamanhos de máquina virtual (VM). Adicionar a um alias builds que cobrem mais regiões só pode aumentar a capacidade. Um build com peso 0 nunca é usado para alocações, nem mesmo como fallback. Para manter um build como fallback, atribua a ele um peso pequeno diferente de zero, por exemplo, 1 contra 999 do seu build principal. Se nenhum dos builds do alias estiver implantado em nenhuma das regiões solicitadas, a solicitação falhará com o erro MultiplayerServerNotFound. Para conhecer maneiras de evitar os dois erros, consulte Práticas recomendadas e lista de verificação de lançamento. Por exemplo, suponha que uma solicitação de alocação direcionada a um alias de build classifique EastUS como região nº 1 e West US como região nº 2. Esse alias de build atribui pesos semelhantes a dois builds, Build 1 e Build 2. Suponha que o Build 1 venha primeiro na ordem de uma determinada alocação.
  1. É feita uma tentativa de alocação em East US para o Build 1.
  2. Se a nº 1 falhar, é feita uma tentativa de alocação em East US para o Build 2.
  3. Se a nº 2 falhar, é feita uma tentativa de alocação em WestUS para o Build 1.
  4. Se a nº 3 falhar, é feita uma tentativa de alocação em WestUs para o Build 2.
Especialmente à medida que você atualiza gradualmente de um build para outro, esse comportamento de fallback é otimizado para que os jogadores obtenham o servidor de menor latência, mesmo que um dos builds esteja com problemas.

​
Gerenciar um alias de build com as APIs REST do PlayFab

Agora você pode gerenciar aliases de build no Game Manager. Para começar, consulte a página de visão geral de builds
  1. Crie um alias de build usando a API. API:
    Corpo de exemplo:
    Resposta de exemplo:
    A ID do alias de build é fornecida como parte da resposta.
  2. Atualize qualquer parâmetro do alias de build. API:
    Corpo de exemplo:
    Resposta de exemplo:
  3. Exclua um alias de build. API:
    Corpo de exemplo:
  4. Liste os aliases de build. API:
    Resposta de exemplo:

​
Alocar usando um alias de build

Para alocar usando um alias de build, especifique a ID do alias de build na chamada a RequestMultiplayerServer. API:
Corpo de exemplo:
Última modificação em 12 de outubro de 2026