Como as solicitações são correspondentes a uma configuração de rota
Uma rota no Azure Front Door define como o tráfego é tratado quando a solicitação recebida chega à borda do Azure Front Door. 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 Padrão de Correspondência e Conjuntos de regras , você pode ter controle granular sobre o tráfego para seus recursos de back-end.
Observação
Ao usar os conjuntos de regras do Front Door, 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.
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ê migre 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 Desativação do Azure Front Door (clássico).
Quando uma solicitação chega à borda do Azure Front Door (Clássico), uma das primeiras coisas que o 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 do Front Door
Uma regra de roteamento do Front Door é composta de duas partes principais, o "lado esquerdo" e o "lado direito". O Front Door faz a correspondência da solicitação de entrada com o lado esquerdo da rota, enquanto o lado direito define como a solicitação é processada.
Correspondência de entrada (lado esquerdo)
As propriedades a seguir determinam se a solicitação de entrada corresponde à regra de roteamento (ou 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 possível conjunto de correspondências.
Decisão de roteamento (lado direito)
A decisão de como processar a solicitação depende do fato de o cache estar 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
Essa seção se concentra em como o Front Door corresponde a uma regra de roteamento. O conceito básico é que o Front Door sempre corresponda à solicitação mais específica olhando apenas para o “lado esquerdo”. O Front Door faz a primeira correspondência com base no protocolo, depois no domínio e, por último, no caminho.
Correspondência do host de front-end
O Azure Front Door utiliza a seguinte lógica para corresponder aos hosts de front-end:
- Determine se há alguma rota com uma correspondência exata no host do front-end.
- Se não houver correspondência exata entre os hosts do front-end, a solicitação será rejeitada e um erro 404: Solicitação Inválida será enviado.
As tabelas a seguir mostram três regras de roteamento diferentes com host e caminhos de front-end:
Regra de roteamento | Hosts de front-end | Caminho |
---|---|---|
Um | foo.contoso.com | /* |
B | foo.contoso.com | /users/* |
C | www.fabrikam.com, foo.adventure-works.com | /*, /images/* |
A tabela a seguir mostra os resultados de correspondência para as regras de roteamento acima:
Host de front-end de entrada | Regras de roteamentos com correspondência |
---|---|
foo.contoso.com | A, B |
www.fabrikam.com | C |
images.fabrikam.com | Erro 404: solicitação inválida |
foo.adventure-works.com | C |
contoso.com | Erro 404: solicitação inválida |
www.adventure-works.com | Erro 404: solicitação inválida |
www.northwindtraders.com | Erro 404: solicitação inválida |
Correspondência de caminho
Depois que o Front Door determina o host de front-end e os filtros específicos para possíveis regras de roteamento, o Front Door seleciona as regras de roteamento com base no caminho da solicitação. Uma lógica semelhante à dos hosts de front-end é usada para corresponder ao caminho da solicitação:
- Determine se há alguma regra de roteamento com uma correspondência exata para o caminho da solicitação.
- Se não houver um caminho exato de correspondência, o Front Door procurará uma regra de roteamento com um caminho curinga que correspondente.
- Se não forem encontradas regras de roteamento com um caminho correspondente, a solicitação será rejeitada e um erro 404: Solicitação Inválida será enviado.
Observação
O *
de caracteres curinga só é válido para caminhos que não tenham outros caracteres depois dele. Além disso, o caractere curinga *
deve ser precedido por uma barra /
. Caminhos sem 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.
Observação
- Quaisquer caminhos sem um caractere curinga são considerados caminhos de correspondência exata. Se um caminho terminar em
/
, isso será considerado uma correspondência exata. - Os caminhos dos padrões de correspondência não diferenciam maiúsculas de minúsculas, o que significa que caminhos com maiúsculas e minúsculas diferentes são tratados como duplicatas. Por exemplo, o mesmo host usa o mesmo protocolo com os caminhos
/FOO
e/foo
. Esses caminhos são considerados duplicatas, o que não é permitido na configuração dos padrões de correspondência.
A tabela a seguir é uma lista de regras de roteamento, combinação de host front-end e caminho:
Regra de roteamento | Host de front-end | Caminho |
---|---|---|
Um | www.contoso.com | / |
B | 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 | /path/ |
A tabela a seguir mostra com qual regra de roteamento a solicitação recebida corresponde ao chegar à borda da Front Door:
Solicitação de entrada | Rota correspondente |
---|---|
www.contoso.com/ | Um |
www.contoso.com/a | B |
www.contoso.com/ab | C |
www.contoso.com/abc | D |
www.contoso.com/abzzz | B |
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 | B |
www.contoso.com/path/ | H |
www.contoso.com/path/zzz | B |
Aviso
Se não houver regras de roteamento para um host de front-end 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 |
---|---|---|
Um | profile.contoso.com | /api/* |
Tabela de correspondência:
Solicitação de entrada | Rota correspondente |
---|---|
profile.domain.com/other | Nenhum. Erro 404: solicitação inválida |
Decisão de roteamento
Depois que o Front Door faz a correspondência com 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á enviada de volta para o 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 nenhuma alteração. 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 reescrita da 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 em caminho do encaminhamento personalizado e, em seguida, encaminhado para o back-end.
Próximas etapas
- Saiba como criar um Azure Front Door.
- Saiba mais sobre a arquitetura de roteamento do Azure Front Door.
- Saiba como criar um Azure Front Door (clássico).
- Saiba mais sobre a arquitetura de roteamento do Azure Front Door.