Descrição geral do Encaminhamento Baseado no Caminho do URL
O Roteamento Baseado em Caminho de URL permite rotear o tráfego para pools de servidores de back-end com base nos Caminhos de URL da solicitação.
Um dos cenários consiste em encaminhar pedidos de diferentes tipos de conteúdo para diversos agrupamentos de servidores de back-end.
No exemplo a seguir, o Application Gateway está servindo tráfego para contoso.com de três pools de servidores back-end, por exemplo: VideoServerPool, ImageServerPool e DefaultServerPool.
Os pedidos para http://contoso.com/video/* são encaminhados para VideoServerPool e os pedidos para http://contoso.com/images/* são encaminhados para ImageServerPool. É selecionado o DefaultServerPool se nenhum dos padrões de caminho corresponder.
Nota
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 servidos a partir da raiz do site por trás do VideoServerPool), você também precisará configurar uma Regra de Reconfiguração de URL ou substituir o caminho de back-end em suas configurações de back-end.
Importante
Para as SKUs v1 e v2, as regras são processadas na ordem em que são listadas no portal. A prática recomendada ao criar regras de caminho é ter o caminho menos específico (aqueles com curingas) no final. Se os curingas estiverem no topo, eles terão prioridade, mesmo que haja uma correspondência mais específica nas regras de caminho subsequentes.
Se for apresentado primeiro um serviço de escuta básico e este corresponde a um pedido de entrada, o pedido é processado por esse serviço de escuta. No entanto, é altamente recomendável configurar ouvintes multissite primeiro antes de configurar um ouvinte básico. Desta forma, assegura que o tráfego é encaminhado para o back-end certo.
Elemento de configuração UrlPathMap
O elemento urlPathMap é usado para especificar padrões Path para mapeamentos de pool de servidores back-end. O seguinte exemplo de código é o fragmento do elemento UrlPathMap do ficheiro 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 lista de padrões de caminho a serem correspondidos. Cada caminho deve começar com / e pode usar * como um caractere curinga. A cadeia de caracteres alimentada para o matcher de caminho não inclui nenhum texto após o primeiro ?
ou #
, e esses caracteres não são permitidos aqui. Caso contrário, quaisquer caracteres permitidos em uma URL são permitidos em PathPattern.
As regras de caminho não diferenciam maiúsculas de minúsculas.
Padrão do caminho | É suportado? |
---|---|
/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 em ordem, com base em como estão listadas no portal. O caminho menos específico (com curingas) deve estar no final da lista, para que seja processado por último. Se as regras curinga estiverem presentes no topo da lista, elas terão prioridade e serão processadas primeiro. Consulte os seguintes cenários de exemplo.
Exemplos
Processamento de regras baseado em caminho quando curinga (*) é usado:
Exemplo 1:
/master-dev* to contoso.com
/master-dev/api-core/ to fabrikam.com
/master-dev/* to microsoft.com
Como o caminho /master-dev*
curinga está presente acima de caminhos mais granulares, todas as solicitações de cliente contidas /master-dev
são roteadas para contoso.com, incluindo o ./master-dev/api-core/
Para garantir que as solicitações do cliente sejam roteadas para os caminhos apropriados, é fundamental 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 /master-dev/*
de caminho são processadas na ordem listada. Se não houver correspondência nas regras de caminho, a solicitação será roteada para o destino padrão.
Para obter mais informações, consulte Modelo do Gerenciador de Recursos usando roteamento baseado em URL.
Regra PathBasedRouting
A RequestRoutingRule do tipo PathBasedRouting é utilizada para vincular um serviço de escuta a um UrlPathMap. Todos os pedidos que são recebidos para este serviço de escuta são encaminhados com base na política especificada no urlPathMap. Fragmento da regra 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óximos passos
Depois de saber mais sobre o encaminhamento de conteúdo baseado em URL, aceda a Criar um gateway de aplicação com encaminhamento baseado em URL para criar um gateway de aplicação com regras de encaminhamento do URL.