Esta página foi traduzida pela API Cloud Translation.

Vista geral dos mapas de URLs

Google Cloud Os balanceadores de carga de aplicações e a malha de serviços na nuvem usam um Google Cloud recurso de configuração denominado mapa de URLs para encaminhar pedidos HTTP(S) para serviços de back-end ou contentores de back-end.

Por exemplo, com um balanceador de carga da aplicação externo, pode usar um único mapa de URLs para encaminhar pedidos para diferentes destinos com base nas regras configuradas no mapa de URLs:

Os pedidos de https://example.com/video são encaminhados para um serviço de back-end.
Os pedidos de https://example.com/audio são encaminhados para um serviço de back-end diferente.

Os pedidos de https://example.com/images são encaminhados para um contentor de back-end do Cloud Storage.

Os pedidos de qualquer outra combinação de anfitrião e caminho são encaminhados para um serviço de back-end predefinido.

Os mapas de URLs são usados com os seguintes Google Cloud produtos:

Balanceador de carga de aplicações externo (modos global, regional e clássico)
Balanceador de carga de aplicações interno (modos regional e entre regiões)
Cloud Service Mesh, quando o Cloud Service Mesh é implementado com as APIs de balanceamento de carga

Existem dois tipos de recursos de mapa de URL disponíveis: global e regional.

Os urlMaps globais são usados por balanceadores de carga de aplicações externos globais, balanceadores de carga de aplicações clássicos, balanceadores de carga de aplicações internos entre regiões e Cloud Service Mesh.
regionUrlMaps são usados por balanceadores de carga de aplicações externos regionais e balanceadores de carga de aplicações internos regionais.

O tipo de recurso que usa depende do esquema de equilíbrio de carga do produto.

Produto	Esquema de balanceamento de carga	Tipo de recurso do mapa de URL	Destinos suportados
Balanceador de carga de aplicações externo global	`EXTERNAL_MANAGED`	Global	Serviços de back-end, contentores de back-end
Balanceador de carga de aplicações clássico	`EXTERNAL`	Global	Serviços de back-end, contentores de back-end
Balanceador de carga de aplicações externo regional	`EXTERNAL_MANAGED`	Regional	Serviços de back-end
Balanceador de carga de aplicações interno entre regiões	`INTERNAL_MANAGED`	Global	Serviços de back-end
Balanceador de carga de aplicações interno regional	`INTERNAL_MANAGED`	Regional	Serviços de back-end
Cloud Service Mesh	`INTERNAL_SELF_MANAGED`	Global	Serviços de back-end

Nem todas as funcionalidades do mapa de URLs estão disponíveis para todos os produtos. Os mapas de URLs usados com balanceadores de carga de aplicações externos globais, balanceadores de carga de aplicações externos regionais, balanceadores de carga de aplicações internos e a malha de serviços da nuvem também suportam várias funcionalidades avançadas de gestão de tráfego. Para mais informações acerca destas diferenças, consulte o artigo Comparação de funcionalidades do equilibrador de carga: encaminhamento e gestão de tráfego. Além disso, os mapas de URLs regionais podem ser um recurso designado como um serviço nas aplicações do App Hub.

Como funcionam os mapas de URLs

Quando um pedido chega ao balanceador de carga, este encaminha o pedido para um serviço de back-end específicoou um contentor de back-end com base nas regras definidas no mapa de URLs.

Um serviço de back-end representa uma coleção de back-ends, que são instâncias de uma aplicação ou um microsserviço. Um contentor de back-end é um contentor do Cloud Storage, que é usado frequentemente para alojar conteúdo estático, como imagens.

Para balanceadores de carga de aplicações externos regionais, balanceadores de carga de aplicações internos e Cloud Service Mesh, os destinos possíveis são os seguintes:

Serviço de back-end predefinido
Serviço de back-end não predefinido

Além disso, os balanceadores de carga de aplicações externos globais suportam o seguinte:

Segmento de back-end predefinido
Contentor de back-end não predefinido

Por exemplo, suponha que tem a seguinte configuração:

Um endereço IP:
- Todos os pedidos à sua organização são enviados para o mesmo endereço IP e o mesmo equilibrador de carga.
- O tráfego é direcionado para diferentes serviços de back-end com base no URL do pedido.
Dois domínios:
- example.net aloja vídeos de formação.
- example.org aloja o Website da sua organização.
Quatro conjuntos de servidores:
- Um aloja o Website da sua organização (serviço de back-end: org-site).
- Um aloja o Website de vídeo de formação geral (serviço de back-end: video-site).
- Um aloja vídeos de formação em alta definição (HD) (serviço de back-end: video-hd).
- Um aloja vídeos de formação em definição padrão (SD) (serviço de back-end: video-sd).

Quer que aconteça o seguinte:

Pedidos para example.org (ou qualquer domínio que não seja example.net) para aceder ao serviço de back-end org-site.
Pedidos para example.net que não correspondem a caminhos mais específicos para aceder ao serviço de back-end video-site.
Pedidos para example.net/video/hd/* para aceder ao serviço de back-end video-hd.
Pedidos para example.net/video/sd/* para aceder ao serviço de back-end video-sd.

Um --path-rule para /video/* corresponde a URIs como /video/test1 e /video/test2. No entanto, esta regra de caminho não corresponde ao caminho /video.

Se o balanceador de carga receber um pedido com /../ no URL, o balanceador de carga transforma o URL removendo o segmento do caminho antes de .. e responde com o URL transformado. Por exemplo, quando é enviado um pedido para http://example.net/video/../abc, o equilibrador de carga responde com um redirecionamento 302 para http://example.net/abc. Em seguida, a maioria dos clientes reage emitindo um pedido para o URL devolvido pelo balanceador de carga (neste caso, http://example.net/abc). Este redirecionamento 302 não é registado no Cloud Logging.

O mapa de URLs permite-lhe configurar este tipo de encaminhamento com base no anfitrião e no caminho.

Exemplo de configuração do serviço de back-end. — Exemplo de configuração do serviço de back-end (clique para aumentar).

Nomenclatura do balanceador de carga

Para balanceadores de carga de aplicações, o nome do balanceador de carga é sempre igual ao nome do mapa de URLs. O comportamento de cada Google Cloud interface é o seguinte:

Google Cloud consola. Se criar um Application Load Balancer através da Google Cloud consola, o mapa de URLs é automaticamente atribuído ao mesmo nome que introduziu para o nome do balanceador de carga.
CLI do Google Cloud ou API. Se criar um balanceador de carga de aplicações através da CLI gcloud ou da API, introduz um nome à sua escolha ao criar o mapa de URLs. Em seguida, este nome do mapa de URLs é refletido na consola doGoogle Cloud como o nome do balanceador de carga.

Para saber como funciona a nomenclatura dos balanceadores de carga de rede de proxy e dos balanceadores de carga de rede de passagem, consulte o artigo Vista geral dos serviços de back-end: nomenclatura do balanceador de carga.

Componentes do mapa de URLs

Um mapa de URLs é um conjunto de Google Cloud recursos de configuração que direcionam pedidos de URLs para serviços de back-end ou contentores de back-end. O mapa de URLs faz isso através das partes hostname e path para cada URL que processa:

Um nome do anfitrião é a parte do nome do domínio de um URL. Por exemplo, a parte do nome do anfitrião do URL http://example.net/video/hd é example.net.
Um caminho é a parte de um URL que segue o nome do anfitrião e o número da porta opcional; por exemplo, a parte do caminho do URL http://example.net/video/hd é /video/hd.

Configuração do balanceador de carga com mapa de URLs básico. — Configuração do balanceador de carga com mapa de URL básico (clique para aumentar).

Este diagrama mostra a estrutura dos objetos de configuração do equilíbrio de carga em relação uns aos outros.

Controla que serviços de back-end ou contentores de back-end recebem pedidos recebidos através dos seguintes parâmetros de configuração do mapa de URLs:

Serviço de back-end predefinido ou segmento de back-end predefinido. Quando cria um mapa de URLs, tem de especificar um serviço de back-end predefinido ou um contentor de back-end predefinido, mas não ambos. Esta predefinição representa o serviço de back-end ou o contentor de back-end para o qual Google Cloud direciona pedidos de URLs com qualquer nome de anfitrião, a menos que exista uma regra de anfitrião aplicável.

Regra de anfitrião (hostRules). Uma regra de anfitrião direciona as solicitações enviadas para um ou mais nomes de anfitrião associados para um único localizador de caminhos (pathMatchers). A parte do URL referente ao nome de anfitrião é exatamente correspondida com o conjunto de nomes de anfitrião configurados da regra de anfitrião. Numa regra de anfitrião e caminho do mapa de URLs, se omitir o anfitrião, a regra corresponde a qualquer anfitrião pedido. Para direcionar pedidos para http://example.net/video/hd para um correspondente de caminhos, precisa de uma única regra de anfitrião que inclua, pelo menos, o nome do anfitrião example.net. Essa mesma regra de anfitrião também pode processar pedidos de outros nomes de anfitriões, mas direciona-os para o mesmo correspondente de caminho.

Se precisar de direcionar pedidos para diferentes correspondências de caminhos, tem de usar regras de anfitriões diferentes. Duas regras de anfitrião num mapa de URLs não podem incluir o mesmo nome de anfitrião.

É possível fazer corresponder todos os nomes de anfitrião especificando o caráter universal * na regra de anfitrião. Por exemplo, para os URLs http://example.org, http://example.net/video/hd e http://example.com/audio, todos os três nomes de anfitrião example.org, example.net e example.com podem ser correspondidos especificando * na regra de anfitrião. Também é possível fazer corresponder um nome de anfitrião parcial especificando o caráter universal *. Por exemplo, uma regra de anfitrião *.example.net é correspondida com os nomes de anfitrião news.example.net e finance.example.net.
- Número da porta. Os diferentes equilibradores de carga de aplicações processam os números de porta de forma diferente. No caso do Application Load Balancer interno, pode usar o parâmetro Regra de anfitrião para especificar um número de porta. Por exemplo, para direcionar pedidos para a porta 8080, defina a regra de anfitrião como example.net:8080. No caso do Application Load Balancer clássico, apenas o nome do anfitrião no URL é considerado quando se faz a correspondência com uma regra de anfitrião.example.net Por exemplo, os example.netpedidos para a porta 8080 e a porta 80 correspondem à regra de anfitrião example.net.
Correspondência de caminhos (pathMatchers). Uma correspondência de caminhos é o parâmetro de configuração referenciado por uma regra de anfitrião. Define a relação entre a parte do caminho de um URL e o serviço de back-end ou o contentor de back-end que deve publicar o pedido. Um correspondente de caminho é composto por dois elementos:
- Serviço de back-end predefinido do Path Matcher ou contentor de back-end predefinido do Path Matcher. Para cada correspondência de caminho, tem de especificar, pelo menos, um serviço de back-end predefinido ou um contentor de back-end predefinido, mas não ambos. Esta predefinição representa o serviço de back-end ou o contentor de back-end para o qual Google Cloud direciona pedidos de URLs cujos nomes de anfitrião correspondem a uma regra de anfitrião associada ao matcher de caminhos e cujos caminhos de URL não correspondem a nenhuma regra de caminho no matcher de caminhos.
- Regras do caminho. Para cada correspondência de caminho, pode especificar uma ou mais regras de caminho, que são pares de chave/valor que mapeiam um caminho de URL para um único serviço de back-end ou contentor de back-end. A secção seguinte contém mais informações sobre o funcionamento das regras de caminho.

Ordem das operações

Para um determinado nome de anfitrião e caminho num URL pedido, Google Cloud usa o seguinte procedimento para direcionar o pedido para o serviço de back-end correto ou o contentor de back-end, conforme configurado no seu mapa de URLs:

Se o mapa de URLs não contiver uma regra de anfitrião para o nome de anfitrião do URL, Google Cloud direciona os pedidos para o serviço de back-end predefinido do mapa de URLs ou o contentor de back-end predefinido, consoante o que tiver definido.
Se o mapa de URLs contiver uma regra de anfitrião que inclua o nome do anfitrião do URL, consulta-se o localizador de caminhos referenciado por essa regra de anfitrião:
- Se o matcher de caminhos contiver uma regra de caminho que corresponda exatamente ao caminho do URL, Google Cloud direciona os pedidos para o serviço de back-end ou o contentor de back-end para essa regra de caminho.
- Se o matcher de caminhos não contiver uma regra de caminho que corresponda exatamente ao caminho do URL, mas contiver uma regra de caminho que termine em /* cujo prefixo corresponda à secção mais longa do caminho do URL, o Google Clouddireciona os pedidos para o serviço de back-end ou o contentor de back-end para essa regra de caminho. Por exemplo, para o mapa de URLs que contém duas regras de correspondência de caminhos /video/hd/movie1 e /video/hd/*, se o URL contiver o caminho exato /video/hd/movie1, é feita a correspondência com essa regra de caminho.
- Se nenhuma das condições anteriores for verdadeira, Google Cloud direciona as solicitações para o serviço de back-end predefinido do Path Matcher ou para o contentor de back-endpredefinido, consoante o que tiver definido.

Restrições do localizador de caminhos

Os nomes de anfitrião, os localizadores de caminhos e as regras de caminhos têm restrições.

Carateres universais, expressões regulares e URLs dinâmicos em regras de caminho

Uma regra de caminho só pode incluir um caráter universal (*) após um caráter de barra invertida (/). Por exemplo, /videos/* e /videos/hd/* são válidos para regras de caminho, mas /videos* e /videos/hd* não são.
As regras de caminho não usam expressões regulares nem correspondência de substring. PathTemplateMatch pode usar operadores de correspondência de caminhos simplificados. Por exemplo, as regras de caminho para /videos/hd ou /videos/hd/* não se aplicam a um URL com o caminho /video/hd-abcd. No entanto, uma regra do caminho para /video/* aplica-se a esse caminho.
Os correspondentes de caminhos (e os mapas de URLs em geral) não oferecem funcionalidades que funcionam como as diretivas do Apache LocationMatch. Se tiver uma aplicação que gere caminhos de URL dinâmicos com um prefixo comum, como /videos/hd-abcd e /videos/hd-pqrs, e precisar de enviar pedidos feitos a esses caminhos para diferentes serviços de back-end, pode não conseguir fazê-lo com um mapa de URLs. Para casos que contenham apenas alguns URLs dinâmicos possíveis, pode criar um correspondente de caminho com um conjunto limitado de regras de caminho. Para casos mais complexos, tem de fazer a correspondência de expressões regulares baseada no caminho nos seus back-ends.

Carateres universais e operadores de correspondência de padrões em modelos de caminhos para regras de encaminhamento

Os operadores de correspondência de padrões flexíveis permitem-lhe fazer corresponder várias partes de um caminho de URL, incluindo URLs parciais e sufixos (extensões de ficheiros), através da sintaxe de carateres universais. Estes operadores podem ser úteis quando precisa de encaminhar tráfego e executar reescritas com base em caminhos de URL complexos. Também pode associar um ou mais componentes do caminho a variáveis com nomes e, em seguida, referir-se a essas variáveis ao reescrever o URL. Com as variáveis com nome, pode reordenar e remover componentes do URL antes de o pedido ser enviado para a sua origem.

A correspondência de padrões com carateres universais só é suportada para os seguintes produtos:

Balanceador de carga de aplicações externo global

Balanceador de carga de aplicações externo regional
Balanceador de carga de aplicações interno regional

Balanceador de carga de aplicações interno entre regiões
Cloud Service Mesh

O exemplo seguinte encaminha o tráfego para uma aplicação de comércio eletrónico que tem serviços separados para informações do carrinho e informações do utilizador. Pode configurar routeRules com operadores de correspondência de padrões flexíveis e variáveis com nomes para enviar o ID exclusivo do utilizador para uma página de detalhes da conta de utilizador e as informações do carrinho do utilizador para um serviço de processamento de carrinhos após reescrever o URL.

  pathMatchers:
    - name: cart-matcher
      routeRules:
        - description: CartService
          matchRules:
            - pathTemplateMatch: '/xyzwebservices/v2/xyz/users/{username=*}/carts/{cartid=**}'
          service: cart-backend
          priority: 1
          routeAction:
            urlRewrite:
              pathTemplateRewrite: '/{username}-{cartid}/'
    - name: user-matcher
      routeRules:
        - description: UserService
          matchRules:
            - pathTemplateMatch: '/xyzwebservices/v2/xyz/users/*/accountinfo/*'
          service: user-backend
          priority: 1

Veja o que acontece quando um cliente pede /xyzwebservices/v2/xyz/users/abc@xyz.com/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB, que tem informações do utilizador e informações do carrinho:

O caminho do pedido corresponde ao pathTemplateMatch no cart-matcher pathMatcher. A variável {username=*} corresponde a abc@xyz.com e a variável {cartid=**} corresponde a FL0001090004/entries/SJFI38u3401nms.
Os parâmetros de consulta são separados do caminho, o caminho é reescrito com base em pathTemplateRewrite e os parâmetros de consulta são anexados ao caminho reescrito. Só podemos usar as mesmas variáveis que usámos para definir o pathTemplateMatch no nosso pathTemplateRewrite.
O pedido reescrito é enviado para cart-backend com o caminho do URL reescrito: /abc@xyz.com-FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB.

Quando um cliente pede /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234, que tem apenas informações do utilizador e da conta, acontece o seguinte:

O caminho do pedido corresponde ao pathTemplateMatch no user-matcher pathMatcher. O primeiro * corresponde a abc%40xyz.com e o segundo * corresponde a abc-1234.
O pedido é enviado para user-backend.

A tabela seguinte descreve a sintaxe dos padrões de modelos de caminhos.

Operador	Correspondências
*``**	Um único segmento de caminho, não incluindo os carateres separadores de caminho `/` circundantes.
``**	Corresponde a zero ou mais carateres, incluindo quaisquer carateres separadores de caminho `/` entre vários segmentos de caminho. Se forem incluídos outros operadores, o operador `**` tem de ser o último.
*`{name}` ou `{name=}`**	Uma variável com nome que corresponda a um segmento do caminho. Corresponde a um único segmento de caminho, não incluindo os carateres `/` do separador de caminho circundantes.
*`{name=news/}`**	Uma variável com nome que corresponde explicitamente a dois segmentos do caminho: `news` e um segmento com carateres universais `*`.
*`{name=/news/}`*	Uma variável com nome que corresponde a três segmentos do caminho.
`{name=}`**	Uma variável com nome que corresponde a zero ou mais carateres. Se estiver presente, tem de ser o último operador.

Quando usa estes operadores para a correspondência de padrões flexível, tenha em atenção as seguintes considerações:

É possível combinar vários operadores num único padrão.
Os parâmetros de consulta são separados do caminho, o caminho é reescrito com base em pathTemplateRewrite e os parâmetros de consulta são anexados ao caminho reescrito.
Os pedidos não são normalizados com codificação em percentagem. Por exemplo, um URL com um caráter de barra invertida codificado em percentagem (%2F) não é descodificado para o formato não codificado.
Cada nome de variável, como {segment} ou {region}, só pode aparecer uma vez no mesmo padrão. As variáveis múltiplas com o mesmo nome são inválidas e são rejeitadas.
Os nomes das variáveis são sensíveis a maiúsculas e minúsculas e têm de ser identificadores válidos. Para verificar se um nome de variável é válido, certifique-se de que corresponde à expressão regular ^[a-zA-Z][a-zA-Z0-9_]*$.
- {API}, {api} e {api_v1} são todos identificadores válidos. Identificam três variáveis distintas.
- {1}, {_api} e {10alpha} não são identificadores válidos.
Existe um limite de cinco operadores por padrão de modelo.

Para executar uma reescrita de URL opcional antes de o pedido ser enviado para a origem, pode usar as mesmas variáveis que definiu para capturar um caminho. Por exemplo, pode fazer referência, reordenar ou omitir variáveis no campo pathTemplateRewrite ao definir urlRewrite.

Quando usa variáveis e operadores para a correspondência de padrões flexível para reescritas de URLs, tenha em atenção estas considerações:

Ao reescrever um URL, pode omitir variáveis se não forem necessárias como parte do URL reescrito.
Antes de qualquer reescrita, pode identificar o URL enviado pelo cliente na sua origem inspecionando os cabeçalhos de resposta. O URL do cliente original é preenchido com o cabeçalho x-client-request-url e o cabeçalho x-envoy-original-path.

Relação entre o nome do anfitrião e a regra do anfitrião

Um nome de anfitrião só pode referenciar uma regra de anfitrião.
Uma única regra de anfitrião pode processar vários nomes de anfitriões.

A relação entre os nomes de anfitriões e as regras de anfitriões. — A relação entre os nomes de anfitriões e as regras de anfitriões (clique para aumentar).

Relação entre a regra de anfitrião e o correspondente de caminhos

Várias regras de anfitrião podem fazer referência a um único localizador de caminhos.
Uma regra de anfitrião só pode referenciar um único correspondente de caminho.

O diagrama seguinte ilustra estes pontos.

A relação entre as regras de anfitriões e os correspondentes de caminhos. — A relação entre as regras de anfitrião e os correspondentes de caminhos (clique para aumentar).

Relação entre o URL e o back-end

Cada URL exclusivo é direcionado para apenas um serviço de back-end ou um contentor de back-end. Consequentemente:

Google Cloud usa a parte do nome do anfitrião de um URL para selecionar uma única regra de anfitrião e o respetivo correspondente de caminho referenciado.
Quando usa regras de caminho num correspondente de caminho, não pode criar mais do que uma regra de caminho para o mesmo caminho. Por exemplo, os pedidos de /videos/hd não podem ser direcionados para mais do que um serviço de back-end ou um contentor de back-end. Os serviços de back-end podem ter grupos de instâncias de back-end ou grupos de pontos finais de rede (NEGs) de back-end em diferentes zonas e regiões, e pode criar contentores de back-end que usam classes de armazenamento multirregionais.

Para direcionar o tráfego de um URL exclusivo para vários serviços, pode usar regras de encaminhamento em vez de regras de caminho. Se configurar a correspondência de caminhos com regras de encaminhamento para correspondências de cabeçalhos ou parâmetros, um URL exclusivo pode ser direcionado para mais do que um serviço de back-end ou um contentor, com base no conteúdo dos cabeçalhos ou dos parâmetros de consulta no URL.

Da mesma forma, para os Application Load Balancers externos regionais e o Cloud Service Mesh, os serviços de back-end ponderados nas ações de encaminhamento podem direcionar o mesmo URL para vários serviços de back-end ou contentores, consoante as ponderações definidas no serviço de back-end ponderado.

Mapas de URLs e protocolos

Pode usar o mesmo mapa de URLs, regras de anfitriões e correspondências de caminhos para processar pedidos HTTP e HTTPS enviados pelos clientes, desde que um proxy HTTP de destino e um proxy HTTPS de destino referenciem o mapa de URLs.

Mapa de URL mais simples

O mapa de URLs mais simples tem apenas um serviço de back-end predefinido ou um contentor de back-end predefinido. Não contém regras de anfitrião nem correspondências de caminhos. O serviço de back-end predefinido ou o contentor de back-end predefinido(conforme o que definiu) processa todos os URLs pedidos.

Se definir um serviço de back-end predefinido, Google Cloud direciona os pedidos para os respetivos grupos de instâncias de back-end ou NEGs de back-end de acordo com a configuração do serviço de back-end.

Mapa de URLs sem regras, exceto a predefinição. — Mapa de URLs sem regras, exceto a predefinição (clique para aumentar).

Exemplo de fluxo de trabalho de mapa de URLs com um balanceador de carga de aplicações externo

O exemplo seguinte ilustra a ordem das operações para um mapa de URL. Este exemplo configura apenas o mapa de URLs para um balanceador de carga da aplicação clássico existente. Para simplificar o conceito, usa apenas serviços de back-end. No entanto, pode substituir os serviços de back-end por contentores de back-end. Para saber como criar os outros componentes do balanceador de carga, consulte o artigo Crie um balanceador de carga de aplicações clássico.

Para mais informações sobre como criar e configurar mapas de URLs com correspondências de caminhos e regras de anfitriões, consulte a gcloud compute url-maps create documentação.

Crie um mapa de URLs para o balanceador de carga e especifique um serviço de back-end predefinido. Este exemplo cria um mapa de URLs denominado video-org-url-map que faz referência a um serviço de back-end existente denominado org-site.
```
gcloud compute url-maps create video-org-url-map \
    --default-service=org-site
```
Crie um correspondente de caminho com o nome video-matcher com as seguintes características:
- O serviço de back-end predefinido é video-site, um serviço de back-end existente.
- Adicione regras de caminho que direcionam pedidos para o caminho de URL exato /video/hd ou o prefixo do caminho de URL /video/hd/* para um serviço de back-end existente denominado video-hd.
- Adicione regras de caminho que direcionam pedidos para o caminho de URL exato /video/sd ou o prefixo do caminho de URL /video/sd/* para um serviço de back-end existente denominado video-sd.
```
gcloud compute url-maps add-path-matcher video-org-url-map \
    --path-matcher-name=video-matcher \
    --default-service=video-site \
    --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd
```

Crie uma regra de anfitrião para o nome do anfitrião example.net que faça referência ao matcher de caminho video-matcher.

gcloud compute url-maps add-host-rule video-org-url-map \
    --hosts=example.net \
    --path-matcher-name=video-matcher

O video-org-url-map mapa de URLs deve ter o seguinte aspeto:

gcloud compute url-maps describe video-org-url-map

creationTimestamp: '2021-03-05T13:34:15.833-08:00'
defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site
fingerprint: mfyJIT7Zurs=
hostRules:
- hosts:
  - '*'
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
id: '8886405179645041976'
kind: compute#urlMap
name: video-org-url-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site
  name: video-matcher
  pathRules:
  - paths:
    - /video/hd
    - /video/hd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd
  - paths:
    - /video/sd
    - /video/sd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map

O mapa de URLs video-org-url-map direciona os URLs solicitados para back-ends da seguinte forma.

Mapa de URLs com uma regra de caminho, correspondências de caminho e uma regra de anfitrião. — Mapa de URLs com uma regra de caminho, correspondências de caminho e uma regra de anfitrião (clique para aumentar).

A tabela seguinte explica o processamento de pedidos apresentado no diagrama anterior.

Nome do anfitrião	Caminhos de URLs	Serviço de back-end selecionado	Motivo da seleção
Nome do anfitrião: `example.org` e todos os outros nomes de anfitriões diferentes de `example.net`	todos os caminhos	`org-site`	O nome do anfitrião não está em nenhuma regra de anfitrião do mapa de URLs, pelo que o pedido é direcionado para o serviço de back-end predefinido do mapa de URLs.
Nome do anfitrião: `example.net`	`/video` `/video/examples`	`video-site`	O pedido é enviado para o serviço de back-end predefinido porque não existe nenhuma regra de caminho para `/video/` ou `/video/*`. A regra de anfitrião `example.net` faz referência a um correspondente de caminhos, mas esse correspondente de caminhos não tem regras de caminhos que se aplicariam a estes caminhos.
Nome do anfitrião: `example.net`	`/video/hd` `/video/hd/movie1` `/video/hd/movies/movie2` Outros URLs que começam por `/video/hd/*`	`video-hd`	Uma regra de anfitrião para `example.net` faz referência a um matcher de caminho cujas regras de caminho direcionam pedidos de caminhos de URL que correspondem exatamente `/video/hd` ou que começam com `/video/hd/*` para o serviço de back-end `video-hd`.
Nome do anfitrião: `example.net`	`/video/sd` `/video/sd/show1` `/video/sd/shows/show2` Outros URLs que começam por `/video/sd/*`	`video-sd`	Uma regra de anfitrião para `example.net` faz referência a um matcher de caminho cujas regras de caminho direcionam pedidos de caminhos de URL que correspondem exatamente `/video/sd` ou que começam com `/video/sd/*` para o serviço de back-end `video-sd`.

Redirecionamentos de URL

Um redirecionamento de URL redireciona os visitantes do seu domínio de um URL para outro.

Um redirecionamento de URL predefinido não está condicionado à correspondência de nenhum padrão específico no pedido recebido. Por exemplo, é recomendável usar um redirecionamento de URL predefinido para redirecionar qualquer nome do anfitrião para um nome do anfitrião à sua escolha.

Existem várias formas de criar um redirecionamento de URL, conforme descrito na tabela seguinte.

Método	Configuração
Redirecionamento de URL predefinido do mapa de URLs	Nível superior `defaultUrlRedirect`
Um redirecionamento de URL predefinido de um correspondente de caminho	`pathMatchers[].defaultUrlRedirect[]`
O redirecionamento de URL da regra de caminho de um correspondente de caminho	`pathMatchers[].pathRules[].urlRedirect`
O redirecionamento de URL da regra de encaminhamento de um correspondente de caminho	`pathMatchers[].routeRules[].urlRedirect`

Dentro de um defaultUrlRedirect ou urlRedirect, pathRedirect funciona sempre da seguinte forma:

Todo o caminho do pedido é substituído pelo caminho que especificar.

Dentro de um defaultUrlRedirect ou urlRedirect, o funcionamento do prefixRedirect depende da forma como o usa:

Se usar um defaultUrlRedirect, prefixRedirect é efetivamente um prefixo adicionado porque o caminho correspondente é sempre /.
Se usar um urlRedirect numa regra de trajeto ou numa regra de caminho de um matcher de caminhos, prefixRedirect é uma substituição de prefixo com base na forma como o caminho pedido foi correspondido conforme definido na regra de caminho ou na regra de trajeto.

Exemplos de redirecionamentos

A tabela seguinte apresenta alguns exemplos de configurações de redirecionamento. A coluna do lado direito mostra a configuração da API para um redirecionamento de URL predefinido.

Quer	Realizado através de um redirecionamento de URL predefinido
Redirecionamento de HTTP para HTTPS Redirecionar http://host.name/path para https://host.name/path	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True
HTTP para HTTPS + redirecionamento de anfitrião Redirecionamento http://any-host-name/path para https://www.example.com/path	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com"
HTTP para HTTPS + redirecionamento de anfitrião + redirecionamento de caminho completo Redirecionamento http://any-host-name/path para https://www.example.com/newPath	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" pathRedirect: "/newPath"
HTTP para HTTPS + redirecionamento de anfitrião + redirecionamento de prefixo Redirecionamento http://any-host-name/originalPath para https://www.example.com/newPrefix/originalPath	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" prefixRedirect: "/newPrefix"

O fragmento parcial seguinte anota cada recurso da API:

defaultUrlRedirect:
   redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
   httpsRedirect: True # True if you want https://, false if you want http://
   hostRedirect: "new-host-name.com" # Omit to keep the requested host
   pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
   prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
   stripQuery: False # True to omit everything in the URL after ?
   ...

O que se segue?

Para adicionar, validar, testar, listar ou eliminar um mapa de URLs, consulte o artigo Use mapas de URLs.
Para obter informações sobre mapas de regras de encaminhamento com a Cloud Service Mesh, consulte a vista geral dos mapas de regras de encaminhamento da Cloud Service Mesh.