Esta página oferece uma vista geral das capacidades de gestão de tráfego avançada disponíveis para balanceadores de carga de aplicações externos globais. Esta página destina-se apenas ao balanceador de carga de aplicações externo global. Estes balanceadores de carga são sempre globais e estão sempre no nível Premium. Se usar um balanceador de carga num modo diferente, consulte uma das seguintes páginas:
Vista geral da gestão de tráfego para um balanceador de carga de aplicações clássico
Vista geral da gestão de tráfego para balanceadores de carga de aplicações externos regionais
- Encaminhamento de tráfego. Encaminhe o tráfego de forma inteligente com base em parâmetros HTTP(S) (por exemplo, anfitrião, caminho, cabeçalhos e outros parâmetros de pedido).
- Ações de tráfego. Realizar ações baseadas em pedidos e respostas (por exemplo, redirecionamentos e transformações de cabeçalhos).
- Políticas de tráfego. Ajustar o comportamento do balanceamento de carga (por exemplo, algoritmos de balanceamento de carga avançados).
Pode configurar estas funcionalidades através de mapas de URLs e serviços de back-end. Para mais informações, consulte os seguintes tópicos:
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.
Encaminhamento de tráfego: encaminhamento com base no cabeçalho
O encaminhamento de tráfego permite-lhe direcionar o tráfego para instâncias de serviço com base em parâmetros HTTP, como cabeçalhos de pedidos. Por exemplo, se o dispositivo de um utilizador for um dispositivo móvel com user-agent:Mobile no cabeçalho do pedido, o encaminhamento de tráfego pode enviar esse tráfego para instâncias de serviço designadas para processar tráfego móvel e enviar tráfego que não tenha user-agent:Mobile para instâncias designadas para processar tráfego de outros dispositivos.
Ações de tráfego: divisão de tráfego com base no peso
A implementação de uma nova versão de um serviço de produção existente geralmente acarreta algum risco. Mesmo que os testes sejam aprovados na preparação, provavelmente não quer sujeitar 100% dos utilizadores à nova versão imediatamente. Com a gestão de tráfego, pode definir divisões de tráfego baseadas em percentagens em vários serviços de back-end.
Por exemplo, pode enviar 95% do tráfego para a versão anterior do seu serviço e 5% para a nova versão do seu serviço. Depois de validar que a nova versão de produção funciona como esperado, pode alterar gradualmente as percentagens até que 100% do tráfego atinja a nova versão do seu serviço. A divisão de tráfego é normalmente usada para implementar novas versões, testes A/B, migração de serviços e processos semelhantes.
Políticas de tráfego: solicite o espelhamento
A sua organização pode ter requisitos de conformidade específicos que determinam que todo o tráfego seja espelhado num serviço adicional que, por exemplo, possa registar os detalhes do pedido numa base de dados para reprodução posterior.
Extensibilidade com extensões de serviços
A integração com extensões de serviço permite-lhe inserir lógica personalizada no caminho de dados de balanceamento de carga dos balanceadores de carga de aplicações suportados.
Para mais informações, consulte o artigo Vista geral das extensões de serviços.
Componentes de gestão de tráfego
A um nível elevado, os balanceadores de carga fornecem gestão de tráfego através da utilização de recursos de mapas de URLs globais e serviços de back-end globais.Pode configurar o encaminhamento de tráfego e as ações de tráfego através de mapas de URLs. Os recursosGoogle Cloud associados a mapas de URLs incluem o seguinte:
- Regra de trajeto
- Correspondência de regra
- Ação da regra
Pode configurar políticas de tráfego através de serviços de back-end. OsGoogle Cloud recursos associados a serviços de back-end incluem o seguinte:
- Política do balanceador de carga de localidade
- Definições do balanceador de carga de hash consistente
- Deteção de valores atípicos
O diagrama seguinte mostra os recursos usados para implementar cada funcionalidade.
Encaminhamento de pedidos para back-ends
Nos balanceadores de carga de aplicações externos globais, 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 ou um contentor 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:
- Regra de anfitrião e caminho simples
- Regra avançada de anfitrião, caminho e rota
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.
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 anfitrião e caminho 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.
O defaultService e o service podem apontar para um serviço de back-end ou um contentor de back-end. Este exemplo mostra os serviços de back-end.
gcloud compute url-maps describe lb-map
defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
- '*'
pathMatcher: pathmap
name: lb-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
name: pathmap
pathRules:
- paths:
- /video
- /video/*
service: global/backendServices/video-backend-service
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 têm um valor de prioridade associado e são interpretadas por ordem de prioridade (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. Por exemplo, a seguinte configuração do mapa de URLs configura o encaminhamento em que 95% do tráfego é encaminhado para um serviço de back-end e 5% do tráfego é encaminhado para outro serviço de back-end.
O defaultService e o service podem apontar para um serviço de back-end ou um contentor de back-end. Este exemplo mostra os serviços de back-end.
gcloud compute url-maps describe lb-map
defaultService: global/backendServices/service-a
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: lb-map
pathMatchers:
- defaultService: global/backendServices/service-a
name: matcher1
routeRules:
- matchRules:
- prefixMatch: ''
routeAction:
weightedBackendServices:
- backendService: global/backendServices/service-a
weight: 95
- backendService: global/backendServices/service-b
weight: 5
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.
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 caminho é composto pelos seguintes elementos:
- Uma ou mais regras do caminho (
pathRules) ou regras de encaminhamento (routeRules). - Um serviço predefinido (
defaultService), que é o serviço de back-end ou o contentor de back-end predefinido usado quando não existe correspondência com outros serviços de back-end ou contentores de back-end.
pathMatchers[], pathMatchers[].pathRules[] e
pathMatchers[].routeRules[] na documentação da API global URL map.
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.
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 pelo utilizador.
Nota: as opções de correspondência e a semântica diferem consoante a parte do pedido com a qual estabelece correspondência. Para mais informações, consultematchRules[] na documentação da API global URL map.
Se tiver várias regras de trajeto, o equilibrador de carga executa-as por ordem de prioridade (com base no campo priority), 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 encaminhamento num determinado correspondente de caminho. A prioridade determina a ordem de avaliação das regras de encaminhamento. A prioridade de uma regra diminui à medida que o respetivo número aumenta, pelo que uma regra com prioridade 4 é avaliada antes de uma regra com
prioridade 25. A primeira regra que corresponde ao pedido é aplicada.
Os números de prioridade podem ter lacunas. Não pode criar mais do que uma regra 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 especificar as ações a realizar quando os critérios da regra de correspondência são cumpridos. Estas ações incluem a divisão do tráfego, a reescrita de URLs, a repetição e a duplicação, a injeção de falhas e as políticas de CORS. |
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. |
Ação do cabeçalho (headerAction) |
Pode configurar regras de transformação de cabeçalhos de pedidos e
respostas quando os critérios em
matchRules forem cumpridos.
|
routeRules[]routeRules[].priorityrouteRules[].descriptionrouteRules[].servicerouteRules[].matchRules[]routeRules[].routeActionrouteRules[].urlRedirectrouteRules[].headerAction
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çalhoHost, conforme mostrado neste comando curl de exemplo, em que10.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).
pathMatchers[].routeRules[].matchRules[] na documentação da API global de mapeamento de URLs.
Ações de planeamento de trajeto
As ações de encaminhamento são ações específicas a tomar quando uma regra de encaminhamento corresponde aos atributos de um pedido.
Ação de trajeto (API field name) |
Descrição |
|---|---|
Redirecionamentos (urlRedirect) |
Devolve um código de resposta 3xx configurável. Também define o cabeçalho de resposta Location com o URI adequado, substituindo o anfitrião e o caminho conforme especificado na ação de redirecionamento.
|
Reescritas de URLs (urlRewrite) |
Reescreve a parte do URL referente ao nome do anfitrião, a parte do URL referente ao caminho ou ambas antes de enviar um pedido ao serviço de back-end selecionado.
Para as reescritas da parte do caminho, pode usar carateres universais em
pathTemplateRewrite.
|
Transformações de cabeçalhos (headerAction) |
Adiciona ou remove cabeçalhos de pedidos antes de enviar um pedido ao serviço de back-end. Também pode adicionar ou remover cabeçalhos de resposta depois de receber uma resposta do serviço de back-end. A tentativa de adicionar e remover o mesmo cabeçalho resulta na remoção do cabeçalho, a menos que a flag replace: True seja usada com a operação requestHeadersToAdd.
|
Espelhamento de tráfego (requestMirrorPolicy) |
Além de encaminhar o pedido para o serviço de back-end selecionado, envia um pedido idêntico para o serviço de back-end espelhado configurado com base no princípio de "disparar e esquecer". O balanceador de carga não aguarda uma resposta do back-end para o qual envia o pedido espelhado. Tenha em atenção as seguintes limitações quando usar a replicação de tráfego:
|
Divisão de tráfego ponderada (weightedBackendServices) |
Permite que o tráfego de uma regra correspondente seja distribuído por vários serviços de back-end, proporcionalmente a um peso definido pelo utilizador atribuído ao serviço de back-end individual. Esta capacidade é útil para configurar implementações faseadas ou testes A/B. Por exemplo, a ação de encaminhamento pode ser configurada de modo que 99% do tráfego seja enviado para um serviço que esteja a executar uma versão estável de uma aplicação, enquanto 1% do tráfego é enviado para um serviço separado que executa uma versão mais recente dessa aplicação. |
Retenta (retryPolicy) |
Configura as condições em que o equilibrador de carga volta a tentar pedidos com falhas, o tempo que o equilibrador de carga espera antes de voltar a tentar e o número máximo de tentativas permitidas. Tenha em atenção o seguinte:
|
Limite de tempo (timeout) |
Especifica o limite de tempo para o trajeto selecionado. O limite de tempo é calculado a partir do momento em que o pedido é totalmente processado até ao momento em que a resposta é totalmente processada. O tempo limite inclui todas as novas tentativas. |
Injeção de falhas (faultInjectionPolicy) |
Introduz erros quando processa pedidos para simular falhas, incluindo: latência elevada, sobrecarga do serviço, falhas do serviço e partição da rede. Esta funcionalidade é útil para testar a resiliência de um serviço a falhas simuladas. |
Atraso na injeção (faultInjectionPolicy) |
Introduz atrasos para uma parte definida pelo utilizador dos pedidos antes de enviar o pedido para o serviço de back-end selecionado. |
Anular injeção (faultInjectionPolicy) |
Responde diretamente a uma fração de pedidos com códigos de estado HTTP definidos pelo utilizador, em vez de encaminhar esses pedidos para o serviço de back-end. |
Políticas de segurança (corsPolicy) |
As políticas de partilha de recursos de origem cruzada (CORS) processam as definições para aplicar pedidos CORS. |
Pode especificar uma das seguintes ações de trajeto:
- Encaminhar o tráfego para um único serviço (
service). - Dividir o tráfego entre vários serviços (
weightedBackendServices weight:x, onde x tem de estar entre 0 e 1000). - URLs de redirecionamento (
urlRedirect).
Além disso, pode combinar qualquer uma das ações de trajeto mencionadas anteriormente com uma ou mais das seguintes ações de trajeto:
- Espelhar tráfego (
requestMirrorPolicy). - Reescrever o anfitrião e o caminho do URL (
urlRewrite). - Tentar novamente pedidos com falhas (
retryPolicy). - Defina o limite de tempo (
timeout). - Introduzir falhas numa percentagem do tráfego (
faultInjectionPolicy). - Adicione uma política de CORS (
corsPolicy). - Manipular cabeçalhos de pedidos ou respostas (
headerAction).
urlRedirecturlRewriteheaderActionrequestMirrorPolicyweightedBackendServicesretryPolicytimeoutfaultInjectionPolicycorsPolicy
Redirecionamentos de HTTP para HTTPS
Se precisar de redirecionar o tráfego HTTP para HTTPS, pode criar duas regras de encaminhamento com um endereço IP comum.
Para ver um exemplo completo, consulte o artigo Configure o redirecionamento de HTTP para HTTPS para balanceadores de carga de aplicações externos globais.Políticas de tráfego
Ao usar recursos de serviço de back-end, pode configurar políticas de tráfego para ajustar o balanceamento de carga num grupo de instâncias ou num grupo de pontos finais da rede (NEG). Estas políticas só entram em vigor depois de um serviço de back-end ter sido selecionado através do mapa de URLs (conforme descrito anteriormente).
As políticas de tráfego permitem-lhe:
- Controlar o algoritmo de balanceamento de carga entre instâncias no serviço de back-end.
- Controlar o volume de ligações a um serviço a montante.
- Controlar a remoção de anfitriões não íntegros de um serviço de back-end.
Política de tráfego (API field name) |
Descrição |
|---|---|
Política de localidade de balanceamento de carga (LocalityLbPolicy) |
Para um serviço ou um contentor de back-end, a distribuição de tráfego baseia-se num modo de balanceamento de carga e numa política de localidade de balanceamento de carga. O modo de equilíbrio determina a fração de tráfego que deve ser enviada para cada back-end (contentor, grupo de instâncias ou Para ver os modos de equilíbrio suportados, consulte o artigo Modo de equilíbrio. Para ver os algoritmos da política de equilíbrio de carga suportados, consulte
|
Afinidade de sessão (consistentHash) |
Inclui afinidade baseada em cookies HTTP, afinidade baseada em cabeçalhos HTTP, afinidade de endereço IP do cliente, afinidade de sessão baseada em cookies com estado e afinidade de cookie gerado. A afinidade de sessão oferece uma tentativa de enviar pedidos de um cliente específico para o mesmo back-end durante o tempo em que o back-end estiver em bom estado e tiver capacidade. As definições de afinidade de sessão só são cumpridas se a política de localidade de equilíbrio de carga estiver definida como Para mais informações sobre a afinidade de sessão, consulte
|
Deteção de valores atípicos (outlierDetection) |
Um conjunto de políticas que especificam os critérios para a remoção de VMs ou pontos finais de back-end não íntegros em NEGs, juntamente com os critérios que definem quando um back-end ou um ponto final é considerado suficientemente íntegro para receber tráfego novamente. Para mais informações sobre a deteção de valores atípicos, consulte
|
O que se segue?
- Para configurar a gestão de tráfego para o balanceador de carga de aplicações externo global, consulte o artigo Configurar a gestão de tráfego para balanceadores de carga de aplicações externos globais.