Nesta página, você encontra uma visão geral dos recursos de gerenciamento de tráfego disponíveis para o balanceador de carga de aplicativo clássico. Esta página é apenas sobre o balanceador de carga de aplicativo clássico. Se você estiver usando um balanceador de carga em um modo diferente com suporte ao conjunto expandido de recursos de gerenciamento de tráfego, consulte uma das seguintes páginas:
Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos regionais
Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos globais
O balanceador de carga de aplicativo clássico é compatível com a funcionalidade de gerenciamento de tráfego que permite usar os seguintes recursos:
- Direcionamento de tráfego. Encaminhe o tráfego de modo inteligente com base em parâmetros HTTP(S):
- Ações de tráfego. Execute ações com base em solicitações:
- Políticas de tráfego. Ajuste o comportamento do balanceamento de carga:
Para configurar esses recursos, use o mapa de URLs do balanceador de carga. Para mais informações, consulte os seguintes tópicos:
Componentes do gerenciamento de tráfego
De modo geral, os balanceadores de carga de aplicativo externos usam mapas de URL globais para fornecer gerenciamento de tráfego.
O balanceador de carga fornece as seguintes ações principais e mutuamente exclusivas:
- Encaminhar solicitações para um serviço de back-end
- Executar um redirecionamento
Ao configurar um balanceador de carga, é possível configurar uma ação de regravação de URL antes que o balanceador de carga envie solicitações ao serviço ou ao bucket de back-end.
As regravações ou os redirecionamentos podem ser aplicados em três níveis ao mapa de URLs:
- No
pathRule
, em que a ação entra em vigor quando um caminho é correspondido - No
pathMatcher
, em que a ação entra em vigor quando não há caminhos correspondentes a estepathMatcher
- No
urlMap
, em que a ação entra em vigor quando nenhum dos hosts especificados em qualquer uma das regras de host é correspondido
Usar routeRules
em um pathMatcher
é uma alternativa ao uso de pathRules
.
pathRules
e routeRules
não podem aparecer juntos no mesmo pathMatcher
.
Ao contrário de pathRules
, em que a ordem não importa, as routeRules
são examinadas
em ordem. Um routeRule
pode testar o caminho do URL, os cabeçalhos HTTP e os parâmetros de consulta
de URL.
Exemplos de casos de uso
O gerenciamento de tráfego é aplicável a muitos casos de uso. Nesta seção, veremos alguns exemplos detalhados.
Substituições
As regravações de URL permitem que você apresente aos usuários externos URLs diferentes daqueles usados pelos seus serviços.
Uma regravação de URL separa um URL de um recurso. É possível converter com base em URLs legíveis, que são mais fáceis de lembrar e usar, transformando-os em URLs compatíveis com mecanismos de pesquisa, que são mais fáceis de encontrar pelos mecanismos de pesquisa, ou em URLs internos específicos da implementação.
O recurso de reescrita de URL faz o seguinte:
- Ler o URL recebido na solicitação.
- Substituir o host, o caminho ou ambos, transformando o URL antes de direcionar o tráfego para o serviço ou bucket de back-end.
No diagrama a seguir:
- Um usuário no Japão envia uma solicitação para o URL
www.mydomain.com/static/images/someimage.jpg
. - Quando a solicitação chega ao balanceador de carga de aplicativo externo, ele usa as informações no mapa de URL para regravar o URL como
www.myorigin.com/august_snapshot/images/someimage.jpg
. - (Opcional) Neste exemplo, o mapa de URLs envia a solicitação para um back-end externo.
Para ver um exemplo de configuração, consulte Regravações.
Redirecionamentos
Com redirecionamentos de URL, é possível redirecionar solicitações de clientes de um URL para outro.
Isso inclui a capacidade de:
- redirecionar todas as solicitações HTTP para solicitações HTTPS;
- redirecionar para um URL diferente formado ao modificar o host, o caminho ou a parte do host e do caminho do URL, ou mesmo ao remover ou manter parâmetros de consulta;
- escolher os códigos de resposta de redirecionamento a serem emitidos.
Use os redirecionamentos de URL para os seguintes recursos:
- fornecer o encurtamento de URL. Os URLs voltados para o cliente podem ser significativamente mais curtos. Esse serviço emite um redirecionamento para a página da Web com o URL longo;
- evitar links corrompidos quando páginas da Web são movidas ou ficam desatualizadas;
- permitir que vários nomes de domínio pertencentes ao mesmo proprietário façam referência a um único site;
- evitar o trabalho e as ineficiências da configuração de soluções alternativas no servidor de back-end para aceitar o redirecionamento necessário;
- reduzir a latência. Redirecionamentos criados na borda podem resultar em menor latência em comparação com redirecionamentos criados nos endpoints de back-end.
Os redirecionamentos de HTTP para HTTPS ajudam você a:
- atender aos requisitos de conformidade (como HIPAA) para tráfego criptografado;
- redirecionar solicitações por meio de HTTPS em vez de rejeitar solicitações enviadas com o protocolo HTTP;
- melhorar o perfil de segurança do seu aplicativo redirecionando o tráfego no próprio balanceador de carga da camada 7, em vez de implementar o redirecionamento no servidor de back-end.
No diagrama a seguir:
- Um usuário no Japão envia uma solicitação
GET http://example.com/img1
. - Com base no redirecionamento definido no mapa de URLs, o balanceador de carga retorna
um redirecionamento
HTTP/1.1 302 Found Location: https://example.com/img1
, redirecionando a solicitação HTTP para uma solicitação HTTPS. - O navegador do usuário envia uma solicitação
GET https://example.com/img1
.
Para ver um exemplo de configuração, consulte Redirecionamentos.
Códigos de resposta compatíveis
Os códigos de resposta de redirecionamento compatíveis estão listados na tabela.
Código de resposta | Número | Observações |
---|---|---|
MOVED_PERMANENTLY_DEFAULT | 301 | |
FOUND | 302 | |
PERMANENT_REDIRECT | 308 | Neste caso, o método de solicitação é mantido. |
TEMPORARY_REDIRECT | 307 | Neste caso, o método de solicitação é mantido. |
SEE_OTHER | 303 |
Roteamento com base em cabeçalho e em parâmetros
O roteamento com base em cabeçalho e em parâmetros permite que um balanceador de carga tome decisões de roteamento baseadas em cabeçalhos HTTP e em parâmetros de consulta de URL.
Com esse recurso, é possível simplificar sua arquitetura de nuvem sem implantar níveis adicionais de proxies (NGINX, por exemplo) para fazer o roteamento.
É possível usar o balanceador de carga de aplicativo externo para realizar as seguintes ações:
- Teste A/B
- Atribuir clientes a diferentes conjuntos de serviços em execução em back-ends
- Fornecer páginas e proporcionar experiências diferentes com base em diferentes categorias de dispositivos de origem das solicitações
Depois que um pathMatcher
é selecionado com base na string do host, o routeRules
no
pathMatcher
seleciona um caminho do URL. Para mais informações, consulte a visão geral
dos mapas de URL.
Exemplo: configuração de testes A/B com roteamento baseado em parâmetros de consulta
O exemplo a seguir mostra como fazer testes A/B por meio da correspondência na string de consulta para especificar o experimento e a entrada.
Suponha que você queira garantir que as solicitações sejam tratadas da seguinte maneira:
- Todas as solicitações com o valor de parâmetro de consulta
A
vão para o serviço de back-end chamadoBackendServiceForProcessingOptionA
. - Todas as solicitações com o valor de parâmetro de consulta
B
vão para o serviço de back-end chamadoBackendServiceForProcessingOptionB
.
Esses requisitos estão resumidos na tabela a seguir.
Solicitação | Serviço de back-end |
---|---|
http://test.mydomain.com?ABTest=A |
BackendServiceForProcessingOptionA |
http://test.mydomain.com?ABTest=B |
BackendServiceForProcessingOptionB |
Para definir isso no seu mapa de URLs global, crie as seguintes configuraçõ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 Roteamento com base em cabeçalho e em parâmetro.
Como rotear solicitações para back-ends
O back-end do tráfego é determinado usando uma abordagem de duas fases:
O balanceador de carga seleciona um serviço de back-end que inclua back-ends. Os back-ends podem ser os seguintes:
- Instâncias de máquina virtual (VM) do Compute Engine em um grupo de instâncias não gerenciadas
- VMs do Compute Engine em um grupo de instâncias gerenciadas (MIG, na sigla em inglês)
- Contêineres por meio de um nó do Google Kubernetes Engine (GKE) em um grupo de endpoints de rede zonais (NEG, na sigla em inglês)
- Back-ends externos fora do Google Cloud em um NEG da Internet
- Cloud Storage em buckets de back-end
- Serviços do App Engine, Cloud Functions ou Cloud Run em um NEG sem servidor
O balanceador de carga escolhe um serviço de back-end com base em regras definidas em um mapa de URLs global.
O serviço de back-end seleciona uma instância de back-end com base em políticas definidas em um serviço de back-end global.
Ao configurar o roteamento, escolha um dos modos a seguir:
- Teste simples de host e caminho por meio de
pathRules
- Teste avançado de solicitação por meio de
routeRules
Em cada mapa de URL, é possível usar as regras simples de host e caminho ou as avançadas de host, caminho e rota. Os dois modos são mutuamente exclusivos. Cada mapa de URL pode conter somente um desses modos.
Regra simples de host e caminho
Em uma regra simples de host e caminho, os mapas de URL funcionam conforme descrito na visão geral do mapa de URLs.
Veja no diagrama a seguir o fluxo lógico de uma regra simples de host e caminho.
Regras de host são usadas para avaliar inicialmente uma solicitação. Um host é o domínio
especificado pela solicitação. Se o host
da solicitação corresponder a uma das entradas no
campo hosts
, a correspondência de caminho associada será usada.
Depois, essa correspondência será avaliada. As regras de caminho são avaliadas com base na semântica "primeiro as correspondências de caminho mais longas" e podem ser especificadas em qualquer ordem. Depois que a correspondência mais específica é encontrada, a solicitação é roteada para o respectivo serviço de back-end. Se a solicitação não for correspondente, o serviço de back-end padrão será usado.
Veja a seguir como é uma regra simples de host e caminho comum.
Nela, o tráfego de vídeo vai para video-backend-service
, e todo o restante
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 host, caminho e rota
Em comparação com as simples, as regras avançadas de host, caminho e rota fornecem mais opções de configuração. Com essas opções, é possível ativar padrões de gerenciamento de tráfego mais avançados e modificar algumas partes da semântica. Por exemplo, em vez de usar a semântica de caminho mais longo, as regras de rota são executadas em ordem.
Como no exemplo de regra simples de host e caminho, é possível configurar
o gerenciamento avançado de tráfego por meio de um mapa de URLs global. No entanto, em vez de usar pathMatchers[].pathRules[]
, você usa pathMatchers[].routeRules[]
.
As seções a seguir explicam os componentes da regra avançada de host, caminho e rota.
Regras do host
Quando uma solicitação chega ao seu balanceador de carga, o campo host
da solicitação é
avaliado em relação às hostRules
definidas no mapa de URLs. Cada regra de host
consiste em uma lista de um ou mais hosts e uma correspondência de caminho
(pathMatcher
). Se nenhuma das hostRules
forem definidas, a solicitação será roteada para
defaultService
.
Para mais informações, consulte hostRules[]
e defaultService
na
documentação da API de mapa de URLs global.
Correspondências de caminho
Depois que uma solicitação corresponde a uma regra de host, o balanceador de carga avalia a correspondência de caminho aplicável ao host.
Uma correspondência de caminho é composta pelos seguintes componentes:
- Uma ou mais regras de caminho (
pathRules
) ou de rota (routeRules
). Uma regra padrão executada quando nenhum outro serviço de back-end corresponde. A regra tem as seguintes opções mutuamente exclusivas:
- Um serviço padrão especifica o serviço de back-end padrão para roteamento quando nenhum outro serviço de back-end corresponde.
- Um redirecionamento padrão especifica para qual URL redirecionar quando nenhum outro serviço de back-end corresponde.
Quando o balanceador de carga é configurado para um serviço padrão, ele também pode ser configurado para regravar o URL antes de enviar a solicitação ao serviço padrão.
Para mais informações, consulte pathMatchers[]
, pathMatchers[].pathRules[]
e
pathMatchers[].routeRules[]
na documentação da API
de mapa de URLs global.
Regras para caminhos
As regras de caminho (pathRules
) especificam um ou mais caminhos de URL, como /
ou /video
.
Geralmente, elas são destinadas ao tipo de roteamento que tenha base em regras simples de host e caminho,
como descrito anteriormente.
Para mais informações, consulte pathRules[]
na documentação da API
de mapa de URLs global.
Regras de rota
A regra de rota (routeRules
) corresponde às informações em uma solicitação recebida e decide o roteamento com base na correspondência.
Ela pode conter várias regras de correspondência diferentes (matchRules
) e
muitas ações de rota distintas (routeAction
).
Uma regra de correspondência avalia a solicitação recebida com base nos parâmetros de consulta, cabeçalhos e caminhos da solicitação HTTP(S). As regras de correspondência são compatíveis com vários tipos de correspondência, como as de prefixo, e de modificadores, como a não diferenciação de maiúsculas e minúsculas. Assim, por exemplo, é possível enviar solicitações HTTP(S) a um conjunto de back-ends com base na presença de um cabeçalho HTTP personalizado.
Para ver uma lista detalhada de opções compatíveis com matchRules
, consulte
matchRules[]
na documentação da API
de mapa de URLs global.
Se você tiver várias regras de rota, o balanceador de carga as executará em ordem, o que permite especificar uma lógica personalizada para correspondência, roteamento e outras ações.
Em uma determinada regra de rota, quando a primeira correspondência é feita, o balanceador de carga para de avaliar as regras de correspondência, e todas as restantes são ignoradas.
O Google Cloud realiza as ações a seguir:
- Procura a primeira regra de correspondência aplicável à solicitação.
- Interrompe a procura por outras regras de correspondência.
- Aplica as ações de rota correspondentes.
As regras de rota têm vários componentes, conforme descrito na tabela a seguir.
Componente da regra de rota (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 rota dentro de uma determinada correspondência de caminho para especificar a ordem da avaliação
da regra de rota. A prioridade mais alta é 0 . A prioridade mais baixa é
2147483647 .
Por exemplo, uma regra com prioridade 4 é avaliada antes de uma
regra com prioridade 25 . A primeira regra que corresponde à
solicitação é aplicada.
Os números de prioridade podem ter lacunas e não precisam ser contíguos. Não é possível criar várias regras com a mesma prioridade. |
Descrição (description ) |
Uma descrição opcional de até 1.024 caracteres. |
Serviço (service ) |
O URL completo ou parcial do recurso do serviço de back-end a que o tráfego será direcionado se essa regra for correspondida. |
Regras de correspondência (matchRules ) |
Uma ou mais regras avaliadas em relação à solicitação. Essas
matchRules podem corresponder a todos os atributos HTTP da solicitação ou a um
subconjunto deles, como o caminho, os cabeçalhos HTTP e os parâmetros
de consulta (GET).Em uma matchRule , todos os critérios correspondentes
precisam ser atendidos para que as routeActions da routeRule
entrem em vigor. Se uma routeRule tiver várias
matchRules , as routeActions da
routeRule entrarão em vigor quando uma solicitação corresponder a uma das
matchRules da routeRule .
|
Ação de rota (routeAction ) |
Permite que você especifique uma ação de regravação de URL a ser realizada quando os critérios da regra de correspondência forem atendidos. |
Ação de redirecionamento (urlRedirect ) |
É possível configurar uma ação para responder com um redirecionamento HTTP quando os critérios da regra de correspondência forem atendidos. Não é possível usar esse campo com uma ação de rota. |
Para mais informações, consulte os campos a seguir na documentação da API de mapa de URLs global:
routeRules[]
routeRules[].priority
routeRules[].description
routeRules[].service
routeRules[].matchRules[]
routeRules[].routeAction
routeRules[].urlRedirect
Corresponder às regras
As regras de correspondência (matchRules
) se aplicam a um ou mais atributos de uma solicitação e realizam
ações especificadas na regra de rota. Veja na lista a seguir alguns exemplos
de atributos de solicitação que podem ser correspondidos por meio de regras de correspondência:
Host: um nome de host é a parte do nome de domínio de um URL. Por exemplo, a parte do nome do host do URL
http://example.net/video/hd
éexample.net
. Na solicitação, o nome de host vem do cabeçalhoHost
, conforme mostrado neste exemplo de comando curl. Nele,10.1.2.9
é o endereço IP com a carga balanceada:curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
Os caminhos vêm depois do nome de host. Por exemplo,
/images
. A regra pode especificar se a correspondência deve ser feita com todo o caminho ou apenas com a parte inicial dele.Outros parâmetros de solicitação HTTP, como cabeçalhos, que permitem a correspondência de cookie e a baseada em parâmetros de consulta (variáveis GET). A correspondência de expressões regulares para valores de cabeçalho não é aceita.
Para ver uma lista completa de regras de correspondência compatíveis, consulte
pathMatchers[].routeRules[].matchRules[]
na documentação da API
de mapa de URLs global.
Como configurar o gerenciamento de tráfego
Use o console do Google Cloud, a gcloud
ou a API Cloud Load Balancing para
configurar o gerenciamento de tráfego. No ambiente de configuração escolhido,
defina o gerenciamento de tráfego por meio de configurações YAML.
Se precisar de ajuda para gravar esses arquivos YAML, use os recursos a seguir:
A documentação da API de mapa de URLs global
fornece uma lista completa de campos, incluindo a semântica sobre relações, restrições e cardinalidade.
Exemplos na página de configuração do gerenciamento de tráfego: