Métodos de encaminhamento de tráfego para a origem

Importante

O Azure Front Door (clássico) será desativado em 31 de março de 2027. Para evitar qualquer interrupção do serviço, é importante migrar seus perfis do Azure Front Door (clássico) para a camada Azure Front Door Standard ou Premium até março de 2027. Para obter mais informações, consulte Aposentadoria (clássica) do Azure Front Door.

O Azure Front Door dá suporte a quatro métodos de roteamento de tráfego para gerenciar como seu tráfego HTTP/HTTPS é distribuído entre diferentes origens. Quando as solicitações do usuário chegam aos pontos de presença da Front Door, o método de roteamento configurado garante que as solicitações sejam encaminhadas para o melhor recurso de back-end.

Nota

Neste artigo, um Origin refere-se ao back-end e um grupo de origem refere-se ao pool de back-end na configuração do Azure Front Door (clássica).

Os quatro métodos de roteamento de tráfego são:

• Latência: encaminha as solicitações para as origens com a menor latência dentro de um intervalo de sensibilidade aceitável, garantindo que as solicitações sejam enviadas para as origens mais próximas em termos de latência de rede.

• Prioridade: Permite definir uma prioridade para suas origens, designando uma origem primária para lidar com todo o tráfego e uma origem secundária como backup se a primária ficar indisponível.

• Ponderado: Atribui um peso a cada origem para distribuir o tráfego uniformemente ou de acordo com coeficientes de peso especificados. O tráfego é distribuído com base em valores de peso se as latências das origens estiverem dentro do intervalo de sensibilidade aceitável.

• Afinidade de sessão: garante que as solicitações do mesmo usuário final sejam enviadas para a mesma origem, configurando a afinidade de sessão para seus hosts ou domínios de frontend.

Nota

Nas camadas Standard e Premium do Azure Front Door, o nome do ponto de extremidade é conhecido como host Frontend no Azure Front Door (clássico).

Todas as configurações de porta frontal incluem monitoramento de integridade de back-end e failover global automatizado. Para obter mais informações, consulte Monitoramento de back-end de porta frontal. O Azure Front Door pode usar um único método de roteamento ou combinar vários métodos para criar uma topologia de roteamento ideal com base nas necessidades do seu aplicativo.

Nota

Usando o mecanismo de regras da Front Door, você pode configurar regras para substituir configurações de rota nas camadas Standard e Premium do Azure Front Door ou substituir o pool de back-end no Azure Front Door (clássico) para uma solicitação. O grupo de origem ou pool de back-end definido pelo mecanismo de regras substituirá o processo de roteamento descrito neste artigo.

Fluxo de decisão global

O diagrama seguinte ilustra o fluxo de decisão global:

As etapas de decisão são:

1. Origens disponíveis: selecione todas as origens habilitadas e íntegras (200 OK) com base na sonda de integridade.
   • Exemplo: Se houver seis origens A, B, C, D, E e F, e C não estiver íntegro e E estiver desativado, as origens disponíveis serão A, B, D e F.
2. Prioridade: Selecione as origens de prioridade máxima entre as disponíveis.
   • Exemplo: Se as origens A, B e D tiverem prioridade 1 e a origem F tiver prioridade 2, as origens selecionadas serão A, B e D.
3. Sinal de latência (com base na sonda de integridade): selecione as origens dentro do intervalo de latência permitido no ambiente da porta da frente onde a solicitação chegou. Isso se baseia na configuração de sensibilidade de latência do grupo de origem e na latência das origens mais próximas.
   • Exemplo: Se a latência para a origem A é de 15 ms, para B é de 30 ms e para D é de 60 ms, e a sensibilidade de latência é definida como 30 ms, as origens selecionadas são A e B, pois D excede o intervalo de 30 ms.
4. Pesos: distribua o tráfego entre as origens finais selecionadas com base nas relações de peso especificadas.
   • Exemplo: Se a origem A tem um peso de 3 e a origem B tem um peso de 7, o tráfego é distribuído 3/10 para A e 7/10 para B.

Se a afinidade de sessão estiver habilitada, a primeira solicitação em uma sessão seguirá o fluxo explicado anteriormente. Os pedidos subsequentes são enviados para a origem selecionada no primeiro pedido.

Roteamento de tráfego baseado em latências mais baixas

A implantação de origens em vários locais globais pode melhorar a capacidade de resposta do seu aplicativo, roteando o tráfego para a origem que está "mais próxima" dos usuários finais. O método de roteamento de latência é o padrão para configurações de porta frontal do Azure. Esse método direciona as solicitações do usuário para a origem com a menor latência de rede, em vez da localização geográfica mais próxima, garantindo um desempenho ideal.

A arquitetura anycast do Azure Front Door, combinada com o método de roteamento de latência, garante que cada usuário tenha o melhor desempenho com base em sua localização. Cada ambiente Front Door mede de forma independente a latência para as origens, o que significa que os usuários em diferentes locais são encaminhados para a origem que oferece o melhor desempenho para seu ambiente específico.

Nota

Por padrão, a propriedade de sensibilidade de latência é definida como 0 ms. Com essa configuração, as solicitações são sempre encaminhadas para as origens mais rápidas disponíveis. Os pesos nas origens só entram em vigor se duas origens tiverem a mesma latência de rede.

Para obter mais informações, consulte Arquitetura de roteamento da porta frontal do Azure.

Roteamento de tráfego baseado em prioridades

Para garantir a alta disponibilidade, as organizações geralmente implantam serviços de backup para assumir o controle se o serviço principal falhar. Essa configuração é conhecida como implantação Ativa/Em espera ou Ativa/Passiva. O método de roteamento de tráfego prioritário no Azure Front Door permite que você implemente esse padrão de failover de forma eficaz.

Por padrão, o Azure Front Door roteia o tráfego para as origens com a prioridade mais alta (menor valor de prioridade). Se essas origens primárias ficarem indisponíveis, ele roteia o tráfego para as origens secundárias (próximo valor de prioridade mais baixo). Este processo continua com origens terciárias se as origens primárias e secundárias não estiverem disponíveis. As sondas de integridade monitoram a disponibilidade das origens com base em seu status e integridade configurados.

Configurando a prioridade para origens

Cada origem em seu grupo de origem do Azure Front Door tem uma propriedade Priority , que pode ser definida como um valor entre 1 e 5. Valores mais baixos indicam maior prioridade. Várias origens podem compartilhar o mesmo valor de prioridade.

Método ponderado de encaminhamento de tráfego

O método de roteamento de tráfego ponderado permite distribuir o tráfego com base em pesos predefinidos.

Neste método, você atribui um peso a cada origem em seu grupo de origem da Porta da Frente do Azure. O peso é um número inteiro entre 1 e 1000, com um valor padrão de 50.

O tráfego é distribuído entre as origens disponíveis usando um mecanismo round-robin baseado nas relações de peso especificadas, desde que as origens atendam à sensibilidade de latência aceitável. Se a sensibilidade à latência estiver definida como 0 milissegundos, os pesos só terão efeito se duas origens tiverem a mesma latência de rede.

O método ponderado suporta vários cenários:

• Atualização gradual do aplicativo: roteie uma porcentagem do tráfego para uma nova origem e aumente-a gradualmente ao longo do tempo.
• Migração de aplicativos para o Azure: crie um grupo de origem com origens do Azure e externas. Ajuste os pesos para preferir novas origens, aumentando gradualmente a sua quota de tráfego até lidar com a maior parte do tráfego, depois desative e remova menos origens preferidas.
• Explosão na nuvem para capacidade adicional: expanda as implantações locais na nuvem adicionando ou habilitando mais origens e especificando a distribuição de tráfego.

Afinidade de sessão

Por padrão, o Azure Front Door encaminha solicitações do mesmo cliente para origens diferentes. No entanto, a afinidade de sessão é útil para aplicativos com monitoração de estado ou cenários em que solicitações subsequentes do mesmo usuário precisam ser processadas pela mesma origem. Esse recurso garante que a mesma origem manipule a sessão de um usuário, o que é benéfico para cenários como a autenticação de cliente.

O Azure Front Door usa afinidade de sessão baseada em cookies, onde cookies gerenciados com SHA256 da URL de origem como identificador são usados. Isso direciona o tráfego subsequente de uma sessão de usuário para a mesma origem.

A afinidade de sessão pode ser habilitada no nível do grupo de origem nas camadas Standard e Premium do Azure Front Door e no nível do host frontend no Azure Front Door (clássico) para cada domínio ou subdomínio configurado. Uma vez habilitado, o Azure Front Door adiciona cookies nomeados ASLBSA e ASLBSACORS à sessão do usuário. Estes cookies ajudam a identificar diferentes utilizadores, mesmo que partilhem o mesmo endereço IP, permitindo uma distribuição mais uniforme do tráfego entre as origens.

O tempo de vida do cookie corresponde à sessão do utilizador, uma vez que o Front Door suporta atualmente apenas cookies de sessão.

Nota

A afinidade de sessão é mantida através do cookie de sessão do navegador ao nível do domínio. Subdomínios sob o mesmo domínio curinga podem compartilhar afinidade de sessão, desde que o navegador do usuário envie solicitações para o mesmo recurso de origem.

Proxies públicos podem interferir na afinidade de sessão porque estabelecer uma sessão requer que o Front Door adicione um cookie de afinidade de sessão à resposta. Isso não pode ser feito se a resposta for armazenável em cache, pois interromperia os cookies para outros clientes que solicitam o mesmo recurso. Para evitar isso, a afinidade de sessão não será estabelecida se a origem enviar uma resposta armazenável em cache. Se a sessão já estiver estabelecida, a capacidade de cache da resposta não importa.

A afinidade de sessão será estabelecida nas seguintes circunstâncias, além dos cenários padrão não armazenáveis em cache:

• A resposta inclui o Cache-Control cabeçalho com no-store.
• A resposta contém um cabeçalho válido Authorization .
• A resposta é um código de status HTTP 302.

Próximos passos

• Saiba como criar uma Porta da Frente do Azure.
• Saiba como funciona o Azure Front Door.