- 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 regionais e serviços de back-end regionais.Para os balanceadores de carga de aplicações internos entre regiões, a gestão de tráfego usa os 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:
- Disjuntores
- 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 internos regionais, 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 back-ends podem ser 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 gerido (GIG) ou contentores através de um nó do Google Kubernetes Engine (GKE) num grupo de pontos finais de rede (NEG). O balanceador de carga escolhe um serviço de back-end com base nas regras definidas num mapa de URLs regional.
- 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 regional.
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.
gcloud compute url-maps describe lb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
- '*'
pathMatcher: pathmap
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
name: pathmap
pathRules:
- paths:
- /video
- /video/*
service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1
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.
gcloud compute url-maps describe lb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
name: matcher1
routeRules:
- matchRules:
- prefixMatch: ''
routeAction:
weightedBackendServices:
- backendService: regions/us-west1/backendServices/service-a
weight: 95
- backendService: regions/us-west1/backendServices/service-b
weight: 5
region: regions/us-west1
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 de mapa de URLs regionais.
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 predefinido usado quando nenhum outro serviço de back-end corresponde.
pathMatchers[], pathMatchers[].pathRules[] e
pathMatchers[].routeRules[] na documentação da API
de mapeamento de URLs regionais.
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
de mapeamento de URLs regionais.
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
de mapeamento de URLs regionais.
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 de mapa de URLs regional.
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. |
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. |
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 que duas regras de encaminhamento partilhem um endereço IP interno comum, tem de reservar o endereço IP e incluir a flag--purpose=SHARED_LOADBALANCER_VIP:
gcloud compute addresses create NAME \
--region=us-west1 \
--subnet=backend-subnet \
--purpose=SHARED_LOADBALANCER_VIP
Para ver um exemplo completo, consulte o artigo Configure o redirecionamento de HTTP para HTTPS para balanceadores de carga de aplicações internos.
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 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 ponderação/fração do tráfego que deve ser enviada para cada back-end (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 faz 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. Para mais informações sobre a afinidade de sessão, consulte a secção
|
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
|
Interrupção de circuito (circuitBreakers) |
Define limites superiores no volume de associações e pedidos por associação a um serviço de back-end. Para mais informações sobre a
interrupção de circuitos, consulte |
O que se segue?
- Para configurar a gestão de tráfego para balanceadores de carga de aplicações internos, consulte o artigo Configure a gestão de tráfego para balanceadores de carga de aplicações internos.