Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aplica-se a: ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door (clássico)
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 que você 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 suporta quatro métodos de encaminhamento de tráfego para gerir a forma como o seu tráfego de HTTP/HTTPS é distribuído entre as 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
No 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ássico).
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, nome do ponto de extremidade é referido como host Frontend no Azure Front Door (clássico).
Todas as configurações do Front Door incluem monitorização da integridade do back-end e failover global automatizado. Para obter mais informações, consulte Monitorização do back-end do Front Door. 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, pode configurar regras para sobrescrever configurações de rota nas camadas Standard e Premium do Azure Front Door ou sobrescrever 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:
-
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.
-
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.
-
Sinal de latência (com base na sonda de integridade): Selecione as origens dentro do intervalo de latência permitido no ambiente do Front Door 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.
-
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 a arquitetura de roteamento do Azure Front Door.
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. Esta configuração é conhecida como uma implementação Ativa/Standby 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 saúde monitoram a disponibilidade dos pontos de origem com base no seu estado e saúde configurados.
Configurando a prioridade para origens
Cada origem no 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 partilhar o mesmo valor de prioridade.
Método ponderado de encaminhamento de tráfego
Nota
Para clientes com RPS (Requests Per Second) muito baixos, devido à natureza de como os POPs AFD e as máquinas estão distribuídos, não podemos garantir que os pesos configurados pelo cliente serão estritamente seguidos e o balanceamento de carga pode parecer desequilibrado.
O método de roteamento de tráfego ponderado permite distribuir o tráfego com base em pesos predefinidos.
Neste método, atribui-se um peso a cada origem no grupo de origens do Azure Front Door. 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é que assumam a maior parte do tráfego, depois desative e elimine as origens menos preferidas.
- Escalamento dinâmico na nuvem para capacidade adicional: expanda as implementações locais na nuvem, adicionando ou habilitando mais origens de dados 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 aplicações com estado ou cenários em que solicitações subsequentes do mesmo usuário precisam ser processadas pela mesma origem. Esta funcionalidade assegura que a mesma origem processa a sessão de um utilizador, o que é vantajoso 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 cabeçalho
Cache-Controlcom 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 um Azure Front Door.
- Saiba como funciona o Azure Front Door.