O Anthos Service Mesh e o Traffic Director são agora o Cloud Service Mesh. Para mais informações, consulte a vista geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

Vista geral da gestão avançada de tráfego para APIs de balanceamento de carga

Este documento destina-se a administradores de malhas ou plataformas e programadores de serviços com um nível de familiaridade intermédio a avançado com a Cloud Service Mesh e os conceitos de malha de serviços, e que determinam e configuram a forma como o tráfego é gerido numa implementação da Cloud Service Mesh. Este documento aplica-se apenas às APIs de equilíbrio de carga e não às APIs de encaminhamento de serviços. Se a sua implementação da Cloud Service Mesh usar as APIs de encaminhamento de serviços, consulte o artigo Vista geral da gestão avançada de tráfego.

O Cloud Service Mesh oferece capacidades avançadas de gestão de tráfego que lhe dão um controlo detalhado sobre a forma como o tráfego é processado. O Cloud Service Mesh suporta os seguintes exemplos de utilização:

Encaminhamento de tráfego detalhado de pedidos para um ou mais serviços
Divisão de tráfego baseada em ponderações para distribuir tráfego por vários serviços
Políticas de espelhamento de tráfego que enviam pedidos para um serviço de depuração e cópias para outro
Distribuição de tráfego otimizada nos back-ends de um serviço para melhorar o balanceamento de carga

Estas capacidades avançadas de gestão de tráfego permitem-lhe cumprir os seus objetivos de disponibilidade e desempenho. Uma das vantagens de usar a malha de serviços na nuvem para estes exemplos de utilização é que pode atualizar a forma como o tráfego é gerido sem ter de modificar o código da aplicação.

Quando usa o proxy HTTP de destino para configurar os proxies Envoy para enviar pedidos HTTP, todas as capacidades neste documento estão disponíveis.
Quando usa serviços ou aplicações gRPC sem proxy com o Cloud Service Mesh, algumas das capacidades não estão disponíveis.
Quando usa o proxy TCP de destino para configurar os proxies Envoy para enviar pedidos TCP, nenhuma das capacidades está disponível porque não existe um mapa de URL nas configurações com um proxy TCP de destino.

Para mais detalhes, consulte a página Funcionalidades.

Para configurar a gestão de tráfego avançada, usa o mesmo mapa de regras de encaminhamento e os recursos de serviços de back-end que usa quando configura o Cloud Service Mesh. Por sua vez, o Cloud Service Mesh configura os seus proxies Envoy e aplicações gRPC sem proxy para aplicar as políticas de gestão de tráfego avançadas que configurar.

A um nível elevado, faz o seguinte:

Configure o mapa de regras de encaminhamento para fazer o seguinte, com base nas características do pedido de saída:
1. Selecione o serviço de back-end para o qual os pedidos são encaminhados.
2. Opcionalmente, execute ações adicionais.
Configure o serviço de back-end para controlar como o tráfego é distribuído para back-ends e pontos finais depois de selecionar um serviço de destino.

Configuração de filtragem

Uma das principais responsabilidades da malha de serviços na nuvem é gerar informações de configuração a partir da regra de encaminhamento, do proxy de destino e do mapa de URLs e, em seguida, enviar essas informações para os clientes da malha de serviços na nuvem, por exemplo, proxies Envoy e aplicações gRPC. O Cloud Service Mesh controla a sua malha de serviços enviando informações de configuração aos respetivos clientes que lhes indicam como se comportar e como encaminhar o tráfego. O Cloud Service Mesh é o plano de controlo.

Quando cria ou atualiza informações de configuração na Cloud Service Mesh, a Cloud Service Mesh traduz esta configuração para uma linguagem que os respetivos clientes conseguem compreender. Por predefinição, o Cloud Service Mesh partilha esta configuração com todos os respetivos clientes. Em alguns casos, pode querer personalizar os clientes do Cloud Service Mesh que recebem informações de configuração específicas. Por outras palavras, pode filtrar a configuração para clientes específicos.

Embora seja uma capacidade avançada, os exemplos seguintes ilustram quando a configuração de filtros pode ajudar:

A sua organização usa o modelo de rede de VPC partilhada e várias equipas usam a Cloud Service Mesh em diferentes projetos de serviço. Se quiser isolar a sua configuração de outros projetos de serviço, pode filtrar a configuração para que clientes específicos do Cloud Service Mesh recebam apenas um subconjunto da configuração.
Tem um número muito elevado de regras de encaminhamento e serviços configurados na malha de serviços do Google Cloud e quer evitar o envio de uma quantidade invulgarmente grande de configuração a todos os clientes da malha de serviços do Google Cloud. Tenha em atenção que um cliente que precisa de avaliar um pedido de saída através de uma configuração grande e complexa pode ter um desempenho inferior ao de um cliente que só precisa de avaliar um pedido através de uma configuração simplificada.

A filtragem de configuração baseia-se no conceito de filtros de metadados:

Quando um cliente do Cloud Service Mesh se liga, apresenta informações do respetivo ficheiro de arranque ao Cloud Service Mesh.
Estas informações contêm o conteúdo dos campos de metadados, sob a forma de pares de valor-chave, que especifica no ficheiro de arranque quando implementa os seus proxies Envoy e aplicações gRPC.
Pode adicionar filtros de metadados à regra de encaminhamento. Toda a configuração associada à regra de encaminhamento é filtrada.
Pode adicionar filtros de metadados no mapa de URLs. O filtro de metadados é aplicado com base no encaminhamento por caminho.
O Cloud Service Mesh partilha a configuração apenas com clientes que apresentem metadados que correspondam às condições do filtro de metadados.

Para obter informações sobre como configurar filtros de metadados para o Envoy, consulte o artigo Configure a filtragem de configurações com base na correspondência MetadataFilter.

Encaminhamento e ações de tráfego

Na Cloud Service Mesh, o mapa de regras de encaminhamento refere-se à combinação dos recursos de regra de encaminhamento, proxy de destino e mapa de URLs. Todas as capacidades de gestão de tráfego avançadas relacionadas com o encaminhamento e as ações são configuradas através do mapa de URLs.

As secções seguintes descrevem as funcionalidades avançadas de gestão de tráfego que pode configurar no mapa de regras de encaminhamento.

Processamento de pedidos

Quando um cliente envia um pedido, este é processado conforme descrito nos passos seguintes:

O pedido é associado a um mapa de regras de encaminhamento específico da seguinte forma:
- Se estiver a usar o Envoy:
  - O endereço IP e a porta de destino do pedido são comparados com o endereço IP e a porta das regras de encaminhamento em todos os mapas de regras de encaminhamento. Apenas são considerados os mapeamentos de regras de encaminhamento com regras de encaminhamento que tenham o esquema de balanceamento de carga INTERNAL_SELF_MANAGED.
  - A regra de encaminhamento que corresponde ao pedido faz referência a um proxy HTTP ou gRPC de destino, que faz referência a um mapa de URLs. Este mapa de URLs contém informações que são usadas para o encaminhamento e as ações.
- Se estiver a usar gRPC sem proxy:
  - Um cliente gRPC que usa o esquema de resolução de nomes xds não realiza uma pesquisa de DNS para resolver o nome do anfitrião no URI do canal. Em vez disso, esse cliente resolve o hostname[:port] no URI de destino enviando um pedido LDS para a Cloud Service Mesh.
  - Apenas a porta de uma regra de encaminhamento com um esquema de equilíbrio de carga INTERNAL_SELF_MANAGED é comparada à porta no URI de destino (por exemplo, xds:///example.hostname:8080). O endereço IP da regra de encaminhamento não é usado. O valor predefinido da porta é 80 se não for especificada nenhuma porta no URI de destino.
  - A regra de encaminhamento que corresponde ao pedido faz referência a um proxy gRPC de destino, que faz referência a um mapa de URLs. Este mapa de URLs contém informações que são usadas para o encaminhamento e as ações.
  - Se mais do que uma regra de encaminhamento corresponder ao pedido, o mapa de URLs que contém a regra de anfitrião que corresponde ao hostname[:port] no URI de destino é usado para o encaminhamento e as ações.
Quando o mapa de URLs adequado é determinado, o mapa de URLs é avaliado para determinar o serviço de back-end de destino e, opcionalmente, aplicar ações.
Depois de selecionar o serviço de back-end de destino, o tráfego é distribuído pelos back-ends ou pelos pontos finais desse serviço de back-end de destino, com base na configuração no recurso do serviço de back-end.

O segundo passo é descrito na secção seguinte, Encaminhamento simples com base no anfitrião e no caminho. O terceiro passo é abordado em Encaminhamento e ações avançadas.

Encaminhamento simples com base no anfitrião e no caminho

O Cloud Service Mesh suporta um esquema de encaminhamento simplificado e um esquema mais avançado. No esquema simples, especifica um anfitrião e, opcionalmente, um caminho. O anfitrião e o caminho do pedido são avaliados para determinar o serviço para o qual um pedido deve ser encaminhado:

O anfitrião do pedido é a parte do nome do domínio de um URL, por exemplo, a parte do anfitrião do URL http://example.com/video/ é example.com.
O caminho do pedido é a parte do URL que segue o nome do anfitrião. Por exemplo, a parte do caminho do URL http://example.com/video/ é /video.

Configura o encaminhamento simples com base no anfitrião e no caminho no mapa de regras de encaminhamento, que consiste no seguinte:

Uma regra de encaminhamento global
Um proxy HTTP de destino, um proxy HTTPS de destino ou um proxy gRPC de destino
Um mapa de URLs

A maioria da configuração é feita no mapa de URLs. Depois de criar o mapa de regras de encaminhamento inicial, só tem de modificar a parte do mapa de regras de encaminhamento relativa ao mapa de URLs. No diagrama seguinte, as regras de caminho têm ações semelhantes às ações no diagrama seguinte.

Encaminhamento com base nos recursos de anfitrião e caminho. — Encaminhamento com base nos recursos de anfitrião e caminho (clique para aumentar)

A regra mais simples é uma regra predefinida, na qual especifica apenas uma regra de anfitrião com carateres universais (*) e um correspondente de caminho com um serviço predefinido. Depois de criar a regra predefinida, pode adicionar regras adicionais que especifiquem diferentes anfitriões e caminhos. As solicitações de saída são avaliadas em função destas regras da seguinte forma:

Se o anfitrião de um pedido (como example.com) corresponder a uma regra de anfitrião:
1. Em seguida, é avaliado o correspondente de caminho.
2. Cada correspondência de caminho contém uma ou mais regras de caminho que são avaliadas em função do caminho do pedido.
3. Se for encontrada uma correspondência, o pedido é encaminhado para o serviço especificado na regra de caminho.
4. Se a regra do anfitrião corresponder, mas nenhuma regra do caminho corresponder, os pedidos são encaminhados para um serviço predefinido que cada correspondência de caminho contém.
Se o pedido não corresponder a nenhuma das regras de anfitrião que especificou, é encaminhado para o serviço especificado na regra predefinida.

Para mais informações sobre os campos de recursos do mapa de URLs e como funcionam, consulte a página da urlMaps API REST.

Encaminhamento e ações avançados

Se quiser fazer mais do que encaminhar um pedido com base no anfitrião e no caminho do pedido, pode configurar regras avançadas para encaminhar pedidos e realizar ações.

Encaminhamento avançado. — Encaminhamento avançado (clique para aumentar)

A um nível elevado, o encaminhamento e as ações avançados funcionam da seguinte forma:

Tal como no encaminhamento simples, o anfitrião do pedido é comparado com as regras de anfitrião que configura no mapa de URLs. Se o anfitrião de um pedido corresponder a uma regra de anfitrião, o matcher de caminho da regra de anfitrião é avaliado.
O correspondente de caminhos contém uma ou mais regras de encaminhamento que são avaliadas em função do pedido. Estas regras de encaminhamento são avaliadas por ordem de prioridade através da correspondência dos atributos do pedido (anfitrião, caminho, cabeçalho e parâmetros de consulta) de acordo com condições de correspondência específicas, por exemplo, correspondência de prefixo.
Depois de selecionar uma regra de encaminhamento, pode aplicar ações. A ação predefinida é encaminhar o pedido para um único serviço de destino, mas também pode configurar outras ações.

Encaminhamento avançado

O encaminhamento avançado é semelhante ao encaminhamento simples descrito anteriormente, exceto que pode especificar a prioridade das regras e condições de correspondência adicionais.

Com o encaminhamento avançado, tem de especificar uma prioridade única para cada regra. Esta prioridade determina a ordem pela qual as regras de encaminhamento são avaliadas, com valores de prioridade mais baixos a terem precedência sobre valores de prioridade mais elevados. Depois de um pedido corresponder a uma regra, a regra é aplicada e as outras regras são ignoradas.

O encaminhamento avançado também suporta condições de correspondência adicionais. Por exemplo, pode especificar que uma regra corresponde ao cabeçalho de um pedido se o nome do cabeçalho corresponder exatamente ou apenas parcialmente, por exemplo, com base no prefixo ou no sufixo. Uma regra pode corresponder com base na avaliação do nome do cabeçalho em relação a uma expressão regular ou noutros critérios, como verificar a presença de um cabeçalho.

Para ver condições de correspondência e detalhes adicionais para headerMatches e queryParameterMatches, consulte a página da API REST urlMaps.

Ao combinar parâmetros de anfitrião, caminho, cabeçalho e consulta com prioridades e condições de correspondência, pode criar regras altamente expressivas que se adequam aos seus requisitos exatos de gestão de tráfego. Para ver detalhes, consulte a tabela seguinte.

Aplicação baseada em HTTP Aplicação baseada em gRPC

	Aplicação baseada em HTTP	Aplicação baseada em gRPC
Anfitriões HTTP versus anfitriões gRPC	O anfitrião é a parte do URL referente ao nome do domínio que a aplicação usa para fazer chamadas. Por exemplo, a parte do anfitrião do URL `http://example.com/video/` é `example.com`.	O anfitrião é o nome que um cliente usa no URI do canal para estabelecer ligação a um serviço específico. Por exemplo, a parte do anfitrião do URI do canal `xds:///example.com` é `example.com`.
Caminhos HTTP versus caminhos gRPC	O caminho é a parte do URL que segue o nome do anfitrião. Por exemplo, a parte do caminho do URL `http://example.com/video` é `/video`.	O caminho está no cabeçalho `:path` do pedido HTTP/2 e tem o seguinte aspeto: `/SERVICE_NAME/METHOD_NAME`. Por exemplo, se chamar o método `Download` no serviço gRPC `Example`, o conteúdo do cabeçalho `:path` tem o seguinte aspeto: `/Example/Download`.
Outros cabeçalhos gRPC (metadados)		O gRPC suporta o envio de metadados entre o cliente gRPC e o servidor gRPC para fornecer informações adicionais sobre uma chamada RPC. Estes metadados estão no formato de pares de chave-valor que são transportados como cabeçalhos no pedido HTTP/2.

Anfitriões HTTP versus anfitriões gRPC

O anfitrião é a parte do URL referente ao nome do domínio que a aplicação usa para fazer chamadas.

Por exemplo, a parte do anfitrião do URL http://example.com/video/ é example.com.

O anfitrião é o nome que um cliente usa no URI do canal para estabelecer ligação a um serviço específico.

Por exemplo, a parte do anfitrião do URI do canal xds:///example.com é example.com.

Caminhos HTTP versus caminhos gRPC

O caminho é a parte do URL que segue o nome do anfitrião.

Por exemplo, a parte do caminho do URL http://example.com/video é /video.

O caminho está no cabeçalho :path do pedido HTTP/2 e tem o seguinte aspeto: /SERVICE_NAME/METHOD_NAME.

Por exemplo, se chamar o método Download no serviço gRPC Example, o conteúdo do cabeçalho :path tem o seguinte aspeto: /Example/Download.

Outros cabeçalhos gRPC (metadados) O gRPC suporta o envio de metadados entre o cliente gRPC e o servidor gRPC para fornecer informações adicionais sobre uma chamada RPC. Estes metadados estão no formato de pares de chave-valor que são transportados como cabeçalhos no pedido HTTP/2.

Ações

A malha de serviços na nuvem permite-lhe especificar as ações que os seus proxies Envoy ou as aplicações gRPC sem proxy realizam quando processam um pedido. As seguintes ações podem ser configuradas através da Cloud Service Mesh.

Ação	Nome do campo da API	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 para o 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.
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 duplicado configurado com base no princípio de disparar e esquecer. O equilibrador de carga não aguarda uma resposta do back-end para o qual envia o pedido espelhado. A replicação é útil para testar uma nova versão de um serviço de back-end. Também pode usá-lo para depurar erros de produção numa versão de depuração do serviço de back-end, em vez de na versão de produção.
Divisão de tráfego com base no peso	`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 esteja a executar uma versão mais recente dessa aplicação.
Novas tentativas	`retryPolicy`	Configura as condições em que o equilibrador de carga volta a tentar pedidos com falhas, o tempo que o equilibrador de carga aguarda antes de voltar a tentar e o número máximo de tentativas permitidas.
Tempo limite	`timeout`	Especifica o limite de tempo para o trajeto selecionado. O tempo limite é 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 capacidade de recuperação de um serviço em relação a falhas simuladas.
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.

Para mais informações sobre as ações e o respetivo funcionamento, consulte a página da urlMaps API REST.

Em cada regra de encaminhamento, pode especificar uma das seguintes ações de encaminhamento (denominadas Ações principais na Google Cloud consola):

Encaminhe o tráfego para um único serviço (service)
Divida o tráfego entre vários serviços (weightedBackendServices)
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 (denominadas ações suplementares na Google Cloud consola):

Manipular cabeçalhos de pedidos/respostas (headerAction)
Espelhar tráfego (requestMirrorPolicy)
Reescreva o anfitrião, o caminho ou ambos do URL (urlRewrite)
Volte a tentar pedidos com falhas (retryPolicy)
Definir limite de tempo (timeout)
Introduzir falhas numa percentagem do tráfego (faultInjectionPolicy)
Adicione uma política de CORS (corsPolicy)

Uma vez que as ações estão associadas a regras de encaminhamento específicas, o proxy Envoy ou a aplicação gRPC sem proxy podem aplicar ações diferentes com base no pedido que estão a processar.

Distribuir tráfego entre os back-ends de um serviço

Conforme abordado em Processamento de pedidos, quando um cliente processa um pedido de saída, seleciona primeiro um serviço de destino. Depois de selecionar um serviço de destino, tem de determinar que back-end ou ponto final deve receber o pedido.

Distribuir tráfego entre back-ends. — Distribuir tráfego entre back-ends (clique para aumentar)

No diagrama anterior, a regra foi simplificada. A regra é, normalmente, uma regra de anfitrião, um localizador de caminhos e uma ou mais regras de caminhos ou rotas. O serviço de destino é o serviço(de back-end). Backend 1, … e Backend n recebem e processam o pedido. Estes back-ends podem ser, por exemplo, instâncias de máquinas virtuais (VMs) do Compute Engine que alojam o código da aplicação do lado do servidor.

Por predefinição, o cliente que processa o pedido envia pedidos para o back-end em bom estado mais próximo que tenha capacidade. Para evitar sobrecarregar um back-end específico, usa o algoritmo de balanceamento de carga round robin para equilibrar a carga de pedidos subsequentes noutros back-ends do serviço de destino. No entanto, em alguns casos, pode querer um controlo mais detalhado deste comportamento.

Balanceamento de carga, afinidade de sessão e proteção de back-ends

Pode definir as seguintes políticas de distribuição de tráfego em cada serviço.

Política	Nome do campo da API	Descrição
Modo de balanceamento de carga	`balancingMode`	Controla como um grupo de pontos finais da rede (NEG) ou um grupo de instâncias gerido (MIG) é selecionado depois de um serviço de destino ter sido selecionado. Pode configurar o modo de equilíbrio para distribuir a carga com base nas ligações simultâneas e na taxa de pedidos.
Política de balanceamento de carga	`localityLbPolicy`	Define o algoritmo de equilíbrio de carga usado para distribuir o tráfego entre back-ends num NEG ou num MIG. Para otimizar o desempenho, pode escolher entre vários algoritmos (como o round robin ou o pedido mínimo).
Afinidade de sessão	`sessionAffinity`	Faz uma tentativa de melhor esforço para 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. O Cloud Service Mesh suporta quatro opções de afinidade de sessão: endereço IP do cliente, com base em cookies HTTP, com base em cabeçalhos HTTP e afinidade de cookies gerados (que o Cloud Service Mesh gera automaticamente).
Hash consistente	`consistentHash`	Oferece afinidade de sessão flexível com base em cabeçalhos HTTP, cookies ou outras propriedades.
Disjuntores	`circuitBreakers`	Define limites superiores no volume de ligações e pedidos por ligação a um serviço de back-end.
Deteção de valores atípicos	`outlierDetection`	Especifica os critérios para (1) remover back-ends ou pontos finais não íntegros de MIGs ou NEGs e (2) adicionar novamente um back-end ou um ponto final quando for considerado suficientemente íntegro para receber tráfego novamente. A verificação de funcionamento associada ao serviço determina se um back-end ou um ponto final é considerado em bom estado.

Para mais informações sobre as diferentes opções de distribuição de tráfego e como funcionam, consulte a página da backendServices API REST.

Exemplos de utilização

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

Pode encontrar mais exemplos, incluindo código de exemplo, nos guias Configurar a gestão de tráfego avançada e Configurar serviços gRPC sem proxy com gestão de tráfego avançada.

Encaminhamento de tráfego detalhado para personalização

Pode encaminhar o tráfego para um serviço com base nos parâmetros do pedido. Por exemplo, pode usar este serviço para oferecer uma experiência mais personalizada aos utilizadores do Android. No diagrama seguinte, o Cloud Service Mesh configura a sua malha de serviços para enviar pedidos com o cabeçalho user-agent:Android para o seu serviço Android em vez de para o seu serviço genérico.

Encaminhamento com base no cabeçalho do agente do utilizador definido como Android. — Encaminhamento com base no cabeçalho `user-agent` definido como `Android` (clique para aumentar)

Divisão de tráfego baseada em ponderação para implementações mais seguras

A implementação de uma nova versão de um serviço de produção existente pode ser arriscada. Mesmo depois de os testes serem aprovados num ambiente de teste, pode não querer encaminhar imediatamente todos os seus utilizadores para a nova versão.

A malha de serviços na nuvem permite-lhe definir divisões de tráfego baseadas em peso para distribuir o tráfego por vários serviços. Por exemplo, pode enviar 1% do tráfego para a nova versão do seu serviço, monitorizar se tudo funciona e, em seguida, aumentar gradualmente a proporção de tráfego que vai para o novo serviço.

Divisão de tráfego baseada em ponderação do Cloud Service Mesh. — Divisão de tráfego baseada no peso do Cloud Service Mesh (clique para aumentar)

Espelhamento de tráfego para depuração

Quando depura um problema, pode ser útil enviar cópias do tráfego de produção para um serviço de depuração. A Cloud Service Mesh permite-lhe configurar políticas de replicação de pedidos para que os pedidos sejam enviados para um serviço e sejam enviadas cópias desses pedidos para outro serviço.

Espelhamento de tráfego do Cloud Service Mesh. — Duplicação de tráfego da Cloud Service Mesh (clique para aumentar)

Balanceamento de carga otimizado para desempenho

Consoante as características da sua aplicação, pode verificar que consegue melhorar o desempenho e a disponibilidade ao otimizar a forma como o tráfego é distribuído pelos back-ends de um serviço. Com a malha de serviços na nuvem, pode aplicar algoritmos de equilíbrio de carga avançados para que o tráfego seja distribuído de acordo com as suas necessidades.

O diagrama seguinte, ao contrário dos diagramas anteriores, mostra um serviço de back-end de destino (Serviço de produção) e os back-ends desse serviço de back-end (Máquina virtual 1, Máquina virtual 2 e Máquina virtual 3). Com a gestão de tráfego avançada, pode configurar como um serviço de back-end de destino é selecionado e como o tráfego é distribuído entre os back-ends desse serviço de destino.

Balanceamento de carga do Cloud Service Mesh. — Equilíbrio de carga do Cloud Service Mesh(clique para aumentar)

O que se segue?

Para ler mais sobre mapas de URLs, consulte o artigo Vista geral dos mapas de URLs e Use mapas de URLs.
Para direcionar o tráfego de fora da sua malha para a sua malha, consulte o artigo Tráfego de entrada para a sua malha.
Para configurar funcionalidades com implementações de proxy sidecar, consulte o artigo Configure a gestão avançada de tráfego com o Envoy.
Para configurar funcionalidades com implementações de gRPC sem proxy, consulte o artigo Configure a gestão de tráfego avançada com serviços gRPC sem proxy.