Общие сведения о маршрутизации на основе URL-путей

Статья
10/24/2023

Маршрутизация на основе URL-адресов позволяет направлять трафик в серверные пулы на основе URL-адресов запроса.

Один из сценариев — это маршрутизация запросов содержимого различных типов в различные пулы тыловых серверов.

В следующем примере Шлюз приложений обслуживает трафик для contoso.com из трех внутренних пулов серверов, например VideoServerPool, ImageServerPool и DefaultServerPool.

imageURLroute

Запросы для http://contoso.com/video/* направляются в VideoServerPool, а запросы для http://contoso.com/images/* — в ImageServerPool. Если ни один из шаблонов пути не подходит, выбирается пул DefaultServerPool.

Важно!

В ценовой категории версий 1 и 2 правила обрабатываются в том порядке, в котором они указаны на портале. Рекомендуется при создании правил пути иметь наименее конкретный путь (те, с дикими карта) в конце. Если дикие карта находятся в верхней части, то они принимают приоритет, даже если в последующих правилах пути есть более конкретное совпадение.

Если базовый прослушиватель стоит первым в списке и совпадает с входящим запросом, он будет обрабатываться прослушивателем. Однако перед настройкой базового прослушивателя настоятельно рекомендуется настроить прослушиватели с несколькими сайтами. Это гарантирует, что трафик будет перенаправляться на правильный внутренний сервер.

Элемент конфигурации UrlPathMap

Элемент URLPathMap используется для указания шаблонов пути для сопоставлений серверного пула серверов. Ниже приведен пример кода, который является фрагментом элемента urlPathMap из файла шаблона.

"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 — это список шаблонов пути для сопоставления. Каждый путь должен начинаться с / и может использовать * как дикий карта символ. Строка, передаваемая в путь, не включает текст после первого ? или #, и эти символы не допускаются здесь. В остальных случаях все допустимые символы в URL-адресе допускаются и в PathPattern.

В правилах для путей не учитывается регистр.

Шаблон пути	Поддерживается?
`/images/*`	yes
`/images*`	yes
`/images/*.jpg`	no
`/*.jpg`	no
`/Repos//Comments/`	no
`/CurrentUser/Comments/*`	yes

Правила пути обрабатываются по порядку на основе того, как они перечислены на портале. Наименее конкретный путь (с дикими карта) должен быть в конце списка, чтобы он был обработан последним. Если дикие карта правила присутствуют в верхней части списка, они принимают приоритет и будут обрабатываться сначала. См. следующие примеры сценариев.

Примеры

Обработка правил на основе пути при использовании wild карта (*):

Пример 1:

/master-dev* to contoso.com

/master-dev/api-core/ to fabrikam.com

/master-dev/* to microsoft.com

Так как дикий карта путь /master-dev* присутствует выше более детализированных путей, все запросы клиента, содержащиеся /master-dev в них, направляются в contoso.com, включая конкретные/master-dev/api-core/. Чтобы убедиться, что клиентские запросы направляются в соответствующие пути, важно иметь детализированные пути над дикими карта пути.

Пример 2:

/ (default) to contoso.com

/master-dev/api-core/ to fabrikam.com

/master-dev/api to bing.com

/master-dev/* to microsoft.com

Все клиентские запросы с шаблоном /master-dev/* пути обрабатываются в порядке, как указано. Если в правилах пути нет совпадений, запрос направляется в целевой объект по умолчанию.

Дополнительные сведения см. в шаблоне Resource Manager с помощью маршрутизации на основе URL-адресов.

Правило PathBasedRouting

Правило RequestRoutingRule типа PathBasedRouting используется для привязки прослушивателя к urlPathMap. Все получаемые запросы для этого прослушивателя распределяются согласно политике, указанной в urlPathMap. Фрагмент правила 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}"
    }

}
    }
]

Следующие шаги

Ознакомившись с маршрутизацией на основе URL-адресов, создайте шлюз приложений с соответствующими правилами маршрутизации, как указано в статье о создании шлюза приложений с помощью маршрутизации на основе URL-адресов .

Share via