Visão geral da arquitetura de roteamento

Quando o Azure Front Door receber suas solicitações de cliente, ele fará uma das duas coisas. Responda a elas se você habilitar o armazenamento em cache ou as encaminhe para o back-end do aplicativo apropriado como um proxy reverso.

Selecionando o ambiente do Front Door para roteamento de tráfego (Anycast)

O tráfego roteado para os ambientes do Azure Front Door usa Anycast para o tráfego DNS (Sistema de Nomes de Domínio) e HTTP, o que permite que as solicitações do usuário cheguem ao ambiente mais próximo com o menor número de saltos de rede. Essa arquitetura oferece um tempo de viagem de ida e volta melhor aos usuários finais, maximizando os benefícios do TCP de divisão. O Front Door organiza seus ambientes em "anéis" primários e de fallback. O anel externo contém ambientes mais próximos aos usuários, oferecendo latências menores. O anel interno contém ambientes que podem manipular o failover para o ambiente do anel externo em caso de problemas. O anel externo é o destino preferido para todo o tráfego, e o anel interno é necessário para manipular o estouro de tráfego do anel externo. Cada host de front-end ou domínio servido pela porta de entrada recebe um VIP primário (endereços de protocolo de Internet virtual), que é anunciado por ambientes no anel interno e externo. Um VIP de fallback é anunciado apenas por ambientes no anel interno.

Essa arquitetura garante que as solicitações de seus usuários finais sempre cheguem ao ambiente do Front Door mais próximo. Mesmo que o ambiente preferencial do Front Door não esteja íntegro, todo o tráfego se moverá automaticamente para o ambiente mais próximo.

Conectando ao ambiente do Front Door (TCP de divisão)

TCP de divisão é uma técnica para reduzir latências e problemas de TCP dividindo em partes menores uma conexão que poderia apresentar um tempo longo de viagem de ida e volta. Com os ambientes do Front Door mais próximos dos usuários finais, as conexões TCP são encerradas dentro do ambiente do Front Door. Uma conexão TCP que tem um RTT (tempo de ida e volta) grande para o back-end do aplicativo é dividida em duas conexões separadas. A "conexão curta" entre o usuário final e o ambiente do Front Door significa que a conexão é estabelecida em três viagens curtas de ida e volta em vez de três idas longas, o que resulta em economia de latência. A "conexão longa" entre o ambiente do Front Door e o back-end pode ser pré-estabelecida e reutilizado em outras solicitações de usuários finais, economizando tempo de conectividade. O efeito do TCP dividido é multiplicado ao estabelecer uma conexão SSL/protocolo TLS, pois há mais viagens de ida e volta para proteger a conexão.

Processando a solicitação para corresponder a uma regra de roteamento

Depois de estabelecer uma conexão e concluir um handshake de TLS, a primeira etapa depois que uma solicitação chega em um ambiente do Front Door é fazer a correspondência com a regra de roteamento. A correspondência é determinada pelas configurações no Front Door à qual a regra de roteamento específica corresponde à solicitação. Leia sobre como o Front Door faz a correspondência de rota para saber mais.

Identificando back-ends disponíveis no pool de back-ends para a regra de roteamento

Depois que o Front Door corresponder a uma regra de roteamento para uma solicitação de entrada, a próxima etapa é obter o status da investigação de integridade para o pool de back-end associado à regra de roteamento se não houver cache. Leia sobre como o Front Door monitora a integridade do back-end usando Investigações de Integridade para saber mais.

Encaminhando a solicitação ao back-end do aplicativo

Finalmente, supondo que o cache não esteja configurado, a solicitação do usuário é encaminhada para o "melhor" back-end com base na configuração do seu método de roteamento.

Próximas etapas