Visão geral do Roteamento Baseado em Caminho de URL
O roteamento baseado em caminho de URL permite rotear o tráfego para pools de servidores back-end de acordo com os caminhos de URL da solicitação.
Um dos cenários possíveis é rotear as solicitações de tipos de conteúdo diferentes para pools de servidores de back-end diferentes.
No exemplo a seguir, o Gateway de Aplicativo está fornecendo tráfego para contoso.com de três pools de servidor back-end, por exemplo: VideoServerPool, ImageServerPool e DefaultServerPool.
As solicitações de http://contoso.com/video/* são encaminhadas para VideoServerPool, e as de http://contoso.com/images/* são encaminhadas para ImageServerPool. O DefaultServerPool será selecionado se nenhum dos padrões de caminho forem compatíveis.
Observação
Quando a solicitação é roteada, o caminho de URL completo é enviado para o pool de back-end. Se os recursos solicitados estiverem em um caminho diferente (por exemplo, se uma solicitação para http://contoso.com/video/* exigir que os vídeos sejam fornecidos da raiz do site por trás do VideoServerPool), você também precisará configurar uma Regra de Reescrita de URL ou substitua o caminho de back-end em suas configurações de back-end.
Importante
Tanto para a SKU v1 quanto para a v2, as regras são processadas na ordem em que estão listadas no Portal. A melhor prática ao criar regras de caminho é ter o caminho menos específico (aqueles com curingas) no final. Se os curingas estiverem no início, eles terão prioridade, mesmo se houver uma correspondência mais específica nas regras de caminho subsequentes.
Se um ouvinte básico for listado primeiro e corresponder a uma solicitação de entrada, ele é processado por esse ouvinte. No entanto, é altamente recomendável configurar primeiro os ouvintes de vários locais para configurar um ouvinte básico. Isso garante que o tráfego seja roteado para o back-end correto.
Elemento de configuração UrlPathMap
O elemento urlPathMap é usado para especificar padrões de Caminho para mapeamentos do pool do servidor back-end. O seguinte é o snippet do elemento urlPathMap do arquivo de modelo.
"urlPathMaps": [{
"name": "{urlpathMapName}",
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/urlPathMaps/{urlpathMapName}",
"properties": {
"defaultBackendAddressPool": {
"id": "/subscriptions/ {subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName1}"
},
"defaultBackendHttpSettings": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpSettingsCollection/{settingname1}"
},
"pathRules": [{
"name": "{pathRuleName}",
"properties": {
"paths": [
"{pathPattern}"
],
"backendAddressPool": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName2}"
},
"backendHttpsettings": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpSettingsCollection/{settingName2}"
}
}
}]
}
}]
PathPattern
PathPattern é uma a lista de padrões de caminho para correspondência. Cada caminho deve começar com / e pode usar * como um caractere curinga. A cadeia de caracteres inserida no correspondente de caminho não inclui nenhum texto após o primeiro ?
ou #
, e esses caracteres não são permitidos aqui. Caso contrário, todos os caracteres permitidos em um URL serão permitidos no PathPattern.
As regras de caminho não diferenciam maiúsculas de minúsculas.
Padrão de caminho | É compatível? |
---|---|
/images/* |
sim |
/images* |
sim |
/images/*.jpg |
não |
/*.jpg |
não |
/Repos/*/Comments/* |
não |
/CurrentUser/Comments/* |
sim |
As regras de caminho são processadas na ordem em que são listadas no portal. O caminho menos específico (com curingas) deve estar no final da lista, para que ele seja processado por último. Se as regras curinga estiverem presentes na parte superior da lista, elas terão prioridade e serão processadas primeiro. Confira os seguintes cenários de exemplo.
Exemplos
Processamento de regras baseadas em caminho quando o curinga (*) é usado:
Exemplo 1:
/master-dev* to contoso.com
/master-dev/api-core/ to fabrikam.com
/master-dev/* to microsoft.com
Como o caminho curinga /master-dev*
está presente acima de caminhos mais granulares, todas as solicitações de cliente que contêm /master-dev
são roteadas para contoso.com, incluindo o /master-dev/api-core/
específico. Para garantir que as solicitações do cliente sejam roteadas para os caminhos apropriados, é essencial ter os caminhos granulares acima dos caminhos curinga.
Exemplo 2:
/ (default) to contoso.com
/master-dev/api-core/ to fabrikam.com
/master-dev/api to bing.com
/master-dev/* to microsoft.com
Todas as solicitações de cliente com o padrão de caminho /master-dev/*
são processadas na ordem, conforme listado. Se não houver nenhuma combinação dentro das regras de caminho, a solicitação será roteada para o destino padrão.
Para obter mais informações, confira Modelo do Resource Manager usando o roteamento baseado em URL.
Regra de PathBasedRouting
RequestRoutingRule do tipo PathBasedRouting é usada para associar um ouvinte a um urlPathMap. Todas as solicitações recebidas por este ouvinte são roteadas com base na política especificada no urlPathMap. snippet de código da regra de PathBasedRouting:
"requestRoutingRules": [
{
"name": "{ruleName}",
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/requestRoutingRules/{ruleName}",
"properties": {
"ruleType": "PathBasedRouting",
"httpListener": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/httpListeners/<listenerName>"
},
"urlPathMap": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/urlPathMaps/{urlpathMapName}"
}
}
}
]
Próximas etapas
Depois de conhecer o roteamento de conteúdo baseado em URL, acesse criar um application gateway usando o roteamento baseado em URL para criar um application gateway com as regras de roteamento de URL.