Como as solicitações são correspondidas a uma configuração de rota

Uma rota na Porta da Frente do Azure define como o tráfego é tratado quando a solicitação de entrada chega à borda da Porta da Frente do Azure. Através das configurações de rota, uma associação é definida entre um domínio e um grupo de origem. Usando recursos avançados, como conjuntos de Padrão para Correspondência e Regras, você pode ter controle granular sobre o tráfego para seus recursos de back-end.

Nota

Ao usar os conjuntos de regras da Porta da Frente, você pode configurar uma regra para substituir o grupo de origem de uma solicitação. O grupo de origem definido pelo conjunto de regras substitui o processo de roteamento descrito neste artigo.

Quando uma solicitação chega à borda (clássica) do Azure Front Door, uma das primeiras coisas que a Front Door faz é determinar como rotear a solicitação correspondente para um recurso de back-end e, em seguida, executar uma ação definida na configuração de roteamento. O documento a seguir explica como o Front Door determina qual configuração de rota usar ao processar uma solicitação.

Estrutura de uma configuração de rota Front Door

Uma regra de roteamento da porta da frente é composta por duas partes principais, o "lado esquerdo" e o "lado direito". Front Door corresponde à solicitação de entrada para o lado esquerdo da rota, enquanto o lado direito define como a solicitação é processada.

Jogo de entrada (lado esquerdo)

As propriedades a seguir determinam se a solicitação de entrada corresponde à regra de roteamento (ou ao lado esquerdo):

  • Protocolos HTTP - HTTP ou HTTPS
  • Domínio - Por exemplo: www.foo.com, *.bar.com
  • Caminhos - Por exemplo: /*, /users/*, /file.gif

Essas propriedades são expandidas internamente para que cada combinação de Protocolo/Domínio/Caminho seja um conjunto de correspondência potencial.

Decisão de encaminhamento (lado direito)

A decisão de como processar a solicitação depende se o cache está habilitado para a rota. Se uma resposta em cache não estiver disponível, a solicitação será encaminhada para a origem apropriada.

Correspondência de rotas

Esta seção se concentra em como o Front Door corresponde a uma regra de roteamento. O conceito básico é que o Front Door sempre corresponde ao pedido mais específico, olhando apenas para o "lado esquerdo". Front Door primeiro correspondem com base no protocolo, depois domínio e, por último, o caminho.

Correspondência de host frontend

O Azure Front Door usa a seguinte lógica para corresponder aos hosts front-end:

  1. Determine se há alguma rota com uma correspondência exata no host frontend.
  2. Se não houver nenhuma correspondência exata de hosts frontend, a solicitação será rejeitada e um erro 400: Bad Request será enviado.

As tabelas a seguir mostram três regras de roteamento diferentes com host frontend e caminhos:

Regra de encaminhamento Anfitriões front-end Caminho
A foo.contoso.com /*
N foo.contoso.com /utilizadores/*
C www.fabrikam.com, foo.adventure-works.com /*, /imagens/*

A tabela a seguir mostra os resultados correspondentes para as regras de roteamento acima:

Host frontend de entrada Regra(s) de roteamento correspondente(s)
foo.contoso.com A, B
www.fabrikam.com C
images.fabrikam.com Erro 400: Solicitação incorreta
foo.adventure-works.com C
contoso.com Erro 400: Solicitação incorreta
www.adventure-works.com Erro 400: Solicitação incorreta
www.northwindtraders.com Erro 400: Solicitação incorreta

Correspondência de caminho

Depois que o Front Door determina o host frontend específico e filtra possíveis regras de roteamento, o Front Door seleciona as regras de roteamento com base no caminho da solicitação. Uma lógica semelhante aos hosts frontend é usada para corresponder ao caminho da solicitação:

  1. Determine se há alguma regra de roteamento com uma correspondência exata com o caminho da solicitação.
  2. Se não houver um caminho de correspondência exato, o Front Door procurará uma regra de roteamento com um caminho curinga correspondente.
  3. Se não forem encontradas regras de roteamento com um caminho correspondente, a solicitação será rejeitada e um erro 400: Solicitação incorreta será definido como enviado.

Nota

O caractere * curinga só é válido para caminhos que não têm outros caracteres depois dele. Além disso, o caractere * curinga deve ser precedido por uma barra /. Os caminhos sem um curinga são considerados caminhos de correspondência exata. Um caminho que termina em uma barra / também é um caminho de correspondência exata. Certifique-se de que seus caminhos sigam essas regras para evitar erros.

Nota

  • Todos os caminhos sem um curinga são considerados caminhos de correspondência exata. Se um caminho termina em um /, isso é considerado uma correspondência exata.
  • Os padrões para corresponder caminhos não diferenciam maiúsculas de minúsculas, o que significa que caminhos com invólucros diferentes são tratados como duplicados. Por exemplo, você tem o mesmo host usando o mesmo protocolo com caminhos /FOO e /foo. Esses caminhos são considerados duplicados, o que não é permitido na configuração Padrões para corresponder.

A tabela a seguir é uma lista de regras de roteamento, host frontend e combinação de caminho:

Regra de encaminhamento Host frontend Caminho
A www.contoso.com /
N www.contoso.com /*
C www.contoso.com /ab
D www.contoso.com /abc
E www.contoso.com /ABC/
F www.contoso.com /ABC/*
G www.contoso.com /ABC/DEF
H www.contoso.com /caminho/

A tabela a seguir mostra a qual regra de roteamento a solicitação de entrada é correspondida ao chegar à borda da Porta da frente:

Pedido de entrada Rota correspondente
www.contoso.com/ A
www.contoso.com/a N
www.contoso.com/ab C
www.contoso.com/abc D
www.contoso.com/abzzz N
www.contoso.com/abc/ E
www.contoso.com/abc/d F
www.contoso.com/abc/def G
www.contoso.com/abc/defzzz F
www.contoso.com/abc/def/ghi F
www.contoso.com/path N
www.contoso.com/path/ H
www.contoso.com/path/zzz N

Aviso

Se não houver regras de roteamento para um host frontend de correspondência exata com um caminho de rota catch-all (/*), não haverá uma correspondência com nenhuma regra de roteamento.

Exemplo de configuração:

Rota Host Caminho
A profile.contoso.com /api/*

Tabela correspondente:

Pedido recebido Rota correspondente
profile.domain.com/other Nenhum. Erro 400: Solicitação incorreta

Decisão de encaminhamento

Uma vez que o Front Door corresponda a uma única regra de roteamento, ele precisa escolher como processar a solicitação. Se o Azure Front Door tiver uma resposta em cache disponível para a regra de roteamento correspondente, a solicitação será atendida de volta ao cliente.

Por fim, o Azure Front Door avalia se você tem ou não um conjunto de regras configurado para a regra de roteamento correspondente. Se nenhum conjunto de regras for definido, a solicitação será encaminhada para o grupo de origem sem alterações. Caso contrário, os conjuntos de regras serão processados na ordem configurada. Os conjuntos de regras podem substituir uma rota forçando o tráfego para um grupo de origem específico.

Se o Front Door (clássico) não tiver uma resposta em cache para a regra de roteamento correspondente, ele avaliará se a reconfiguração de URL está configurada para a regra de roteamento correspondente. Se não houver um caminho de encaminhamento personalizado, a solicitação será encaminhada para o back-end apropriado no pool de back-end configurado sem alterações. Se um caminho de encaminhamento personalizado tiver sido definido, o caminho da solicitação será atualizado conforme definido no caminho de encaminhamento personalizado e, em seguida, será encaminhado para o back-end.

Próximos passos

  • Saiba como criar uma Porta da Frente do Azure.
  • Saiba mais sobre a arquitetura de roteamento do Azure Front Door.