Esta página foi traduzida pela API Cloud Translation.

Vista geral da gestão de tráfego para um balanceador de carga de aplicações clássico

Esta página oferece uma vista geral das capacidades de gestão de tráfego disponíveis para o balanceador de carga de aplicações clássico. Esta página destina-se apenas ao balanceador de carga de aplicações clássico. Se usar um balanceador de carga num modo diferente com suporte para o conjunto expandido de funcionalidades de gestão de tráfego, consulte uma das seguintes páginas:

O Application Load Balancer clássico suporta a funcionalidade de gestão de tráfego que lhe permite usar as seguintes funcionalidades:

Encaminhamento de tráfego. Encaminhe o tráfego de forma inteligente com base nos parâmetros HTTP(S):
- Anfitrião e caminho
Ações de tráfego. Realizar ações baseadas em pedidos:
Políticas de tráfego. Ajuste o comportamento do balanceamento de carga:
- Limites de tempo
- Tarifas máximas e ligações máximas

Configura estas funcionalidades através do mapa de URLs do balanceador de carga. Para obter informações gerais, consulte os seguintes tópicos:

Componentes de gestão de tráfego

Em termos gerais, os balanceadores de carga de aplicações externos fornecem gestão de tráfego através de mapas de URLs globais.

O balanceador de carga oferece as seguintes ações principais mutuamente exclusivas:

Encaminhe pedidos para um serviço de back-end
Faça um redirecionamento

Quando configura um equilibrador de carga, pode configurar uma ação de reescrita de URL antes de o equilibrador de carga enviar pedidos para o serviço de back-end ou o contentor de back-end.

As reescritas ou os redirecionamentos podem ser aplicados a três níveis no mapa de URLs:

No pathRule onde a ação entra em vigor quando um caminho é correspondido
No pathMatcher onde a ação entra em vigor quando não são encontradas correspondências de caminhos para este pathMatcher
No urlMap onde a ação entra em vigor quando nenhum dos anfitriões especificados em nenhuma das regras de anfitriões é correspondido

A utilização de routeRules num pathMatcher é uma alternativa à utilização de pathRules. pathRules e routeRules não podem aparecer no mesmo pathMatcher. Ao contrário de pathRules, em que a ordem não é importante, routeRules são examinados por ordem. Um routeRule pode testar o caminho do URL, os cabeçalhos HTTP e os parâmetros de consulta do URL.

Exemplos de utilização

A gestão do tráfego aborda muitos exemplos de utilização. Esta secção apresenta alguns exemplos de alto nível.

Reescritas

A reescrita de URLs permite-lhe apresentar aos utilizadores externos URLs diferentes dos URLs usados pelos seus serviços.

Uma reescrita de URL separa um URL de um recurso. Pode traduzir URLs fáceis de usar, que são mais fáceis de memorizar e usar para os utilizadores, transformando-os em URLs fáceis de usar para motores de pesquisa, que são mais fáceis de encontrar para os motores de pesquisa, ou em URLs internos específicos da implementação.

A funcionalidade de reescrita de URLs faz o seguinte:

Lê o URL recebido no pedido.
Substitui o anfitrião, o caminho ou ambos, transformando o URL antes de direcionar o tráfego para o serviço de back-end ou o contentor de back-end.

No diagrama seguinte:

Um utilizador no Japão envia um pedido para o URL www.mydomain.com/static/images/someimage.jpg.
Quando o pedido atinge o balanceador de carga de aplicações externo, o balanceador de carga usa informações no mapa de URLs para reescrever o URL para www.myorigin.com/august_snapshot/images/someimage.jpg.
(Opcional) Neste exemplo, o mapa de URLs envia o pedido para um backend externo.

Reescrita de URL com o balanceador de carga de aplicações clássico. — **Figura 1.** Reescrita de URLs com o balanceador de carga de aplicações clássico.

Para ver um exemplo de configuração, consulte a secção Reescritas.

Redirecionamentos

Com os redirecionamentos de URL, pode redirecionar pedidos de clientes de um URL para outro.

Isto inclui a capacidade de:

Redirecionar todos os pedidos HTTP para pedidos HTTPS.
Redirecionar para um URL diferente formado pela modificação do anfitrião, do caminho ou de ambos, e remover ou reter quaisquer parâmetros de consulta.
Escolha os códigos de resposta de redirecionamento a emitir.

Use redirecionamentos de URL para as seguintes capacidades:

Fornecer abreviação de URLs. Os URLs visíveis para os clientes podem ser substancialmente mais curtos. Este serviço emite um redirecionamento para a página Web com o URL longo.
Evite links danificados quando as páginas Web são movidas ou ficam desatualizadas.
Permitir que vários nomes de domínios pertencentes ao mesmo proprietário façam referência a um único Website.
Evite o trabalho árduo e as ineficiências da configuração de soluções alternativas no servidor de back-end para suportar o redirecionamento necessário.
Reduzir a latência. Os redirecionamentos criados no limite podem resultar numa latência inferior em comparação com os redirecionamentos criados nos pontos finais de back-end.

Os redirecionamentos de HTTP para HTTPS ajudam especificamente a:

Cumprir os requisitos de conformidade (como a HIPAA) para tráfego encriptado.
Redirecionar pedidos através de HTTPS em vez de rejeitar pedidos enviados com o protocolo HTTP.
Melhora o perfil de segurança da sua aplicação ao redirecionar o tráfego no próprio equilibrador de carga da camada 7, em vez de implementar o redirecionamento no servidor de back-end.

No diagrama seguinte:

Um utilizador no Japão envia um pedido GET http://example.com/img1.
Com base no redirecionamento definido no mapa de URLs, o balanceador de carga envia de volta um redirecionamento HTTP/1.1 302 Found Location: https://example.com/img1, redirecionando o pedido HTTP para um pedido HTTPS.
O navegador do utilizador envia um pedido GET https://example.com/img1.

**Figura 2.** Redirecionamento de URL com o balanceador de carga de aplicações clássico.

Para ver um exemplo de configuração, consulte a secção Redirecionamentos.

Códigos de resposta suportados

Os códigos de resposta de redirecionamento suportados são apresentados na tabela.

Código de resposta	Número	Notas
MOVED_PERMANENTLY_DEFAULT	301
FOUND	302
PERMANENT_REDIRECT	308	Neste caso, o método de pedido é mantido.
TEMPORARY_REDIRECT	307	Neste caso, o método de pedido é mantido.
SEE_OTHER	303

Encaminhamento com base no cabeçalho e em parâmetros

O encaminhamento baseado em cabeçalhos e parâmetros permite que um equilibrador de carga tome decisões de encaminhamento com base em cabeçalhos HTTP e parâmetros de consulta de URL.

Com esta funcionalidade, pode simplificar a sua arquitetura na nuvem sem implementar camadas adicionais de proxies (por exemplo, NGINX) para fazer o encaminhamento.

Pode usar o Application Load Balancer externo para fazer o seguinte:

Testes A/B
Atribuir clientes a diferentes conjuntos de serviços executados em back-ends
Apresentar páginas e experiências diferentes com base em diferentes categorias de dispositivos a partir dos quais as solicitações têm origem

Depois de selecionar um pathMatcher com base na string de anfitrião, o routeRules em pathMatcher selecione um caminho de URL. Para mais informações, consulte a vista geral dos mapas de URLs.

Exemplo: configurar testes A/B com o encaminhamento baseado em parâmetros de consulta

O exemplo seguinte mostra como fazer testes A/B fazendo a correspondência com a string de consulta para especificar a experiência e a entrada.

Suponhamos que quer garantir que os pedidos são processados da seguinte forma:

Todos os pedidos com o valor do parâmetro de consulta A vão para o serviço de back-end denominado BackendServiceForProcessingOptionA.
Todos os pedidos com o valor do parâmetro de consulta B vão para o serviço de back-end denominado BackendServiceForProcessingOptionB.

Estes requisitos estão resumidos na tabela seguinte.

Pedido	Serviço de back-end
`http://test.mydomain.com?ABTest=A`	`BackendServiceForProcessingOptionA`
`http://test.mydomain.com?ABTest=B`	`BackendServiceForProcessingOptionB`

Para configurar esta opção no seu mapa de URLs global, pode criar as seguintes definições.

Correspondência	Ação
`pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest` `pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = A`	`pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionA`
`pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest` `pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = B`	`pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionB`

Para ver um exemplo de configuração, consulte o artigo Encaminhamento baseado em cabeçalhos e parâmetros.

Encaminhamento de pedidos para back-ends

O back-end do seu tráfego é determinado através de uma abordagem de duas fases:

O balanceador de carga seleciona um serviço de back-end com back-ends. Os backends podem ser os seguintes:
- Instâncias de máquinas virtuais (VMs) do Compute Engine num grupo de instâncias não gerido
- VMs do Compute Engine num grupo de instâncias geridas (GIG)
- Contentores através de um nó do Google Kubernetes Engine (GKE) num grupo de pontos finais da rede (NEG) zonal
- Back-ends externos fora de Google Cloud num NEG da Internet
- Cloud Storage em contentores de back-end
- Funções do App Engine, do Cloud Run ou serviços do Cloud Run num NEG sem servidor
O balanceador de carga escolhe um serviço de back-end com base nas regras definidas num mapa de URLs global.
O serviço de back-end seleciona uma instância de back-end com base nas políticas definidas num serviço de back-end global.

Quando configura o planeamento de trajeto, pode escolher entre os seguintes modos:

Testes simples de anfitrião e caminho através da utilização de pathRules
Testes de pedidos avançados com routeRules

Para cada mapa de URLs, pode optar por usar regras de anfitrião e caminho simples ou regras de anfitrião, caminho e rota avançadas. Os dois modos são mutuamente exclusivos. Cada mapa de URLs só pode conter um modo ou o outro.

Regra de anfitrião e caminho simples

Numa regra de anfitrião e caminho simples, os mapeamentos de URLs funcionam conforme descrito na vista geral do mapeamento de URLs.

O diagrama seguinte mostra o fluxo lógico de uma regra de anfitrião e caminho simples.

**Figura 3.** Fluxo do mapa de URLs com uma regra de anfitrião e caminho simples.

Inicialmente, um pedido é avaliado através de regras de anfitrião. Um anfitrião é o domínio especificado pelo pedido. Se o pedido host corresponder a uma das entradas no campo hosts, é usado o matcher de caminho associado.

Em seguida, o correspondente de caminhos é avaliado. As regras de caminho são avaliadas com base na correspondência do caminho mais longo primeiro, e pode especificar regras de caminho em qualquer ordem. Depois de encontrar a correspondência mais específica, o pedido é encaminhado para o serviço de back-end correspondente. Se o pedido não corresponder, é usado o serviço de back-end predefinido.

Uma regra de caminho e anfitrião simples típica pode ter o seguinte aspeto, em que o tráfego de vídeo é encaminhado para video-backend-service e todo o outro tráfego é encaminhado para web-backend-service.

$ gcloud compute url-maps describe ext-https-map

defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: ext-https-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: global/backendServices/video-backend-service

Para ver um exemplo de configuração, consulte Host e caminho.

Regra avançada de anfitrião, caminho e rota

As regras avançadas de anfitrião, caminho e rota oferecem opções de configuração adicionais em comparação com as regras simples de anfitrião e caminho. Estas opções ativam padrões de gestão de tráfego mais avançados e também modificam algumas das semânticas. Por exemplo, as regras de encaminhamento são executadas por ordem (em vez de usar a semântica de correspondências de caminho mais longo primeiro).

Tal como no exemplo anterior de regra de anfitrião e caminho simples, pode configurar a gestão de tráfego avançada através de um mapa de URLs global, mas, em vez de usar pathMatchers[].pathRules[], usa pathMatchers[].routeRules[].

As secções seguintes explicam os componentes avançados de anfitrião, caminho e regra de trajeto.

Regras de anfitrião

Quando um pedido chega ao seu equilibrador de carga, o campo host do pedido é avaliado em função do hostRules definido no mapa de URLs. Cada regra de anfitrião consiste numa lista de um ou mais anfitriões e num único correspondente de caminho (pathMatcher). Se não forem definidos hostRules, o pedido é encaminhado para o defaultService.

Para mais informações, consulte hostRules[] e defaultService na documentação da API global URL map.

Correspondências de caminhos

Depois de um pedido corresponder a uma regra de anfitrião, o equilibrador de carga avalia o correspondente do caminho correspondente ao anfitrião.

Um correspondente de caminhos é composto pelos seguintes componentes:

Uma ou mais regras do caminho (pathRules) ou regras de encaminhamento (routeRules).
Uma regra predefinida que é executada quando nenhum outro serviço de back-end corresponde. A regra tem as seguintes opções que se excluem mutuamente:
- Um serviço predefinido especifica o serviço de back-end predefinido para o qual encaminhar quando nenhum outro serviço de back-end corresponde.
- Um redirecionamento predefinido especifica o URL para o qual redirecionar quando nenhum outro serviço de back-end corresponde.

Quando o balanceador de carga está configurado para um serviço predefinido, também pode ser configurado para reescrever o URL antes de enviar o pedido para o serviço predefinido.

Para mais informações, consulte pathMatchers[], pathMatchers[].pathRules[] e pathMatchers[].routeRules[] na documentação da API global de mapeamento de URLs.

Regras do caminho

As regras de caminho (pathRules) especificam um ou mais caminhos de URL, como / ou /video. Geralmente, as regras de caminho destinam-se ao tipo de encaminhamento simples baseado no anfitrião e no caminho descrito anteriormente.

Para mais informações, consulte pathRules[] na documentação da API global URL map.

Regras de rotas

Uma regra de encaminhamento (routeRules) corresponde a informações num pedido recebido e toma uma decisão de encaminhamento com base na correspondência.

As regras de encaminhamento podem conter várias regras de correspondência diferentes (matchRules) e várias ações de encaminhamento diferentes (routeAction).

Uma regra de correspondência avalia o pedido recebido com base no caminho, nos cabeçalhos e nos parâmetros de consulta do pedido HTTP(S). As regras de correspondência suportam vários tipos de correspondências (por exemplo, correspondência de prefixo), bem como modificadores (por exemplo, não sensibilidade a maiúsculas e minúsculas). Isto permite-lhe, por exemplo, enviar pedidos HTTP(S) a um conjunto de back-ends com base na presença de um cabeçalho HTTP definido personalizado.

Para uma lista detalhada das opções suportadas por matchRules, consulte matchRules[] na documentação da API global URL map.

Se tiver várias regras de encaminhamento, o balanceador de carga executa-as por ordem, o que lhe permite especificar uma lógica personalizada para a correspondência, o encaminhamento e outras ações.

Numa determinada regra de encaminhamento, quando é feita a primeira correspondência, o balanceador de carga deixa de avaliar as regras de correspondência e quaisquer regras de correspondência restantes são ignoradas.

OGoogle Cloud realiza as seguintes ações:

Procura a primeira regra de correspondência que corresponda ao pedido.
Deixa de analisar outras regras de correspondência.
Aplica as ações nas ações de trajeto correspondentes.

As regras de encaminhamento têm vários componentes, conforme descrito na tabela seguinte.

Componente de regra de encaminhamento (`API field name`)	Descrição
Prioridade (`priority`)	Um número de 0 a 2 147 483 647 (ou seja, (2^31)-1) atribuído a uma regra de trajeto num determinado correspondente de caminho para determinar a ordem de avaliação da regra de trajeto. A prioridade mais elevada é `0`. A prioridade mais baixa é `2147483647`. Por exemplo, uma regra com a prioridade `4` é avaliada antes de uma regra com a prioridade `25`. A primeira regra que corresponde ao pedido é aplicada. Os números de prioridade podem ter lacunas; não têm de ser contíguos. Não pode criar várias regras com a mesma prioridade.
Descrição (`description`)	Uma descrição opcional de até 1024 carateres.
Serviço (`service`)	O URL completo ou parcial do recurso de serviço de back-end para o qual o tráfego é direcionado se esta regra for correspondente.
Regras de correspondência (`matchRules`)	Uma ou mais regras que são avaliadas em função do pedido. Estes `matchRules` podem corresponder a todos ou a um subconjunto dos atributos HTTP do pedido, como o caminho, os cabeçalhos HTTP e os parâmetros de consulta (GET). Num `matchRule`, todos os critérios correspondentes têm de ser cumpridos para que o `routeRule` do `routeActions` entre em vigor. Se um `routeRule` tiver vários `matchRules`, o `routeActions` do `routeRule` entra em vigor quando um pedido corresponde a qualquer um dos `routeRule`'s `matchRules`.
Ação de trajeto (`routeAction`)	Permite-lhe especificar uma ação de reescrita de URL a tomar quando os critérios da regra de correspondência são cumpridos.
Ação de redirecionamento (`urlRedirect`)	Pode configurar uma ação para responder com um redirecionamento HTTP quando os critérios da regra de correspondência forem cumpridos. Não é possível usar este campo em conjunto com uma ação de rota.

Para mais informações, consulte os seguintes campos na documentação da API global URL map:

routeRules[]
routeRules[].priority
routeRules[].description
routeRules[].service
routeRules[].matchRules[]
routeRules[].routeAction
routeRules[].urlRedirect

Regras de correspondência

As regras de correspondência (matchRules) correspondem a um ou mais atributos de um pedido e tomam ações especificadas na regra de encaminhamento. A lista seguinte apresenta alguns exemplos de atributos de pedidos que podem ser associados através de regras de correspondência:

Anfitrião: um nome de anfitrião é a parte do nome de domínio de um URL; por exemplo, a parte do nome de anfitrião do URL http://example.net/video/hd é example.net. No pedido, o nome do anfitrião é proveniente do cabeçalho Host, como mostrado neste comando curl de exemplo, em que 10.1.2.9 é o endereço IP com equilíbrio de carga:
```
curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
```
Os caminhos seguem o nome do anfitrião; por exemplo, /images. A regra pode especificar se todo o caminho ou apenas a parte inicial do caminho tem de corresponder.
Outros parâmetros de pedidos HTTP, como cabeçalhos HTTP, que permitem a correspondência de cookies, bem como a correspondência com base em parâmetros de consulta (variáveis GET). Tenha em atenção que a correspondência de expressões regulares para valores de cabeçalho não é suportada.

Para uma lista completa das regras de correspondência suportadas, consulte a secção pathMatchers[].routeRules[].matchRules[] na documentação da API global de mapeamento de URLs.

Configurar a gestão de tráfego

Pode usar a Google Cloud consolagcloud ou a API Cloud Load Balancing para configurar a gestão de tráfego. No ambiente de configuração escolhido, pode configurar a gestão de tráfego através de configurações YAML.

Para obter ajuda na escrita destes ficheiros YAML, pode usar os seguintes recursos:

A documentação da API global URL map

Fornece uma lista completa de campos, incluindo semântica relativa a relações, restrições e cardinalidade.
Exemplos na página de configuração da gestão do tráfego:

Vista geral da gestão de tráfego para um balanceador de carga de aplicações clássico Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.