Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Uma rota no Azure Front Door define como o tráfego é tratado quando a solicitação recebida chega à borda do Azure Front Door. As configurações de rota estabelecem uma associação 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 exercer controle granular sobre o tráfego para seus recursos de backend.
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
Azure Front Door (clássico) se aposenta em 31 de março de 2027. Como o serviço está se aposentando, ele não suporta mais criação de perfil, integração de novos domínios ou certificados gerenciados. Para evitar a interrupção do serviço, igrate para Azure Front Door Standard ou Premium. Para obter mais informações, confira Desativação do Azure Front Door (clássico).
Quando uma solicitação chega à borda do Azure Front Door (clássico), uma das primeira etapas é 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 compara a solicitação recebida 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 (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, de modo que cada combinação de Protocolo/Domínio/Caminho constitui um conjunto de correspondências potenciais.
Decisão de roteamento (lado direito)
A decisão de como processar a solicitação depende da possibilidade do 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
Esta seção explica como o Front Door associa as solicitações às regras de roteamento. O princípio básico é que o Front Door sempre faz a correspondência com a solicitação mais específica avaliando as propriedades do "lado esquerdo": protocolo, domínio e caminho, nessa ordem.
Correspondência do host de front-end
O Azure Front Door utiliza as seguintes etapas para mapear os hosts de front-end:
- Verificar se há rotas com uma correspondência exata no host do frontend.
- Se ele não encontrar uma correspondência exata, rejeitará a solicitação com um erro 404: Solicitação Incorreta.
As tabelas a seguir ilustram três regras de roteamento diferentes com seus hosts e caminhos de front-end:
| Regra de roteamento | Hosts de front-end | Caminho |
|---|---|---|
| Um | foo.contoso.com | /* |
| B | foo.contoso.com | /Usuários/* |
| C | www.fabrikam.com, foo.adventure-works.com | /*, /imagens/* |
A tabela a seguir mostra os resultados correspondentes para as regras de roteamento na tabela anterior:
| Host de front-end de entrada | Regras de roteamento correspondentes |
|---|---|
| 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 Azure Front Door determina o host de front-end específico e filtra possíveis regras de roteamento, ele seleciona as regras de roteamento com base no caminho da solicitação. O serviço usa a seguinte lógica:
- Verifique se há regras de roteamento com uma correspondência exata para o caminho da solicitação.
- Se não for encontrada uma correspondência exata, procure uma regra de roteamento com um caminho curinga que corresponda.
- Se ele não encontrar um caminho correspondente, rejeite a solicitação com um erro 404: Solicitação Incorreta.
Observação
O caractere curinga * só é válido para um caminho que não tem outros caracteres depois dele. Além disso, o caractere curinga * deve ser precedido por uma barra /. Os caminhos sem caracteres 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
- Os caminhos sem caracteres curinga são considerados caminhos de correspondência exata. Um caminho que termina com um
/também é uma correspondência exata. - Os padrões de caminho não diferenciam maiúsculas de minúsculas. Por exemplo,
/FOOe/foosão consideradas duplicatas e não são permitidas na configuração “Padrões a serem correspondidos”.
A tabela a seguir lista as regras de roteamento com suas combinações de host e caminho de front-end:
| 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 |
/caminho/ |
A tabela a seguir mostra qual regra de roteamento corresponde a uma solicitação recebida no Azure Front Door:
| Solicitação Recebida | 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 com correspondência exata e sem um caminho de rota genérico (/*), nenhuma regra de roteamento será encontrada.
Exemplo de configuração:
| Rota | Anfitrião | 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
Assim que o Azure Front Door identifica uma regra de roteamento, ele decide como processar a solicitação. Se uma resposta armazenada em cache estiver disponível, ela enviará essa resposta de volta ao cliente.
Se você configurar um conjunto de regras para a regra de roteamento correspondente, o Azure Front Door irá processá-lo em ordem. Os conjuntos de regras podem substituir uma rota forçando o tráfego para um grupo de origem específico. Se você não definir um conjunto de regras, Azure Front Door encaminha a solicitação para o grupo de origem sem alterações.
Se o Azure Front Door (clássico) não tiver uma resposta armazenada em cache, ele verificará se há uma configuração de reescrita de URL. Se você não definir um caminho de encaminhamento personalizado, Azure Front Door encaminha a solicitação para o back-end apropriado no pool de back-end configurado. Se você definir um caminho de encaminhamento personalizado, Azure Front Door atualizará o caminho da solicitação adequadamente e o encaminha para o back-end.
Próximas etapas
- Criar Azure Front Door.
- Saiba mais sobre a arquitetura de roteamento do Azure Front Door.
- Criar um "Azure Front Door" clássico.
- Saiba mais sobre a arquitetura de roteamento do Azure Front Door.