Vista geral da gestão avançada de tráfego

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.

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 com base na ponderação para distribuir o 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. A replicação de tráfego não é suportada com o recurso TCPRoute nem com o recurso TLSRoute.
  • 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.

A gestão de tráfego numa malha de serviços do Cloud Service Mesh baseia-se nos seguintes recursos:

  • Mesh, que identifica a malha de serviços e representa o componente responsável por encaminhar o tráfego e aplicar políticas. O recurso Mesh também identifica a porta de interceção de tráfego.
  • Gateway, que identifica proxies intermédios e representa o componente que escuta numa lista de pares de endereço IP:porta, encaminha o tráfego e aplica políticas.
  • Route, que pode ser de vários tipos e que contém informações de encaminhamento de tráfego para a malha. Os recursos Route identificam nomes de anfitriões e portas que os clientes podem usar para encaminhar tráfego para serviços de back-end. Seguem-se os tipos de recursos Route:
    • HTTPRoute, que só está disponível em malhas que usam proxies Envoy. Quando usa o recurso HTTPRoute para configurar os proxies do Envoy para enviar pedidos HTTP, todas as capacidades neste documento estão disponíveis.
    • TCPRoute, que só está disponível em malhas que usam proxies Envoy.
    • TLSRoute, que só está disponível em malhas que usam proxies Envoy.
    • GRPCRoute, que está disponível em malhas que usam proxies complementares do Envoy e gRPC sem proxy. Quando usa serviços ou aplicações gRPC sem proxy com o Cloud Service Mesh, algumas das capacidades descritas neste documento não estão disponíveis.
  • Serviço de back-end, ao qual os recursos Route estão associados.

Configuração

Para configurar a gestão de tráfego avançada, usa os mesmos recursos de Route e 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:

  1. Configure um recurso Mesh para identificar a malha de serviço.

  2. Configure os recursos Route 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.

  3. 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.

Encaminhamento e ações de tráfego

No Cloud Service Mesh, o tráfego é encaminhado com base nos valores no recurso Mesh, no recurso Route e no recurso de serviço de back-end. Todas as capacidades avançadas de gestão de tráfego relacionadas com o encaminhamento e as ações são configuradas através dos Routeobjetos.

As secções seguintes descrevem as funcionalidades avançadas de gestão de tráfego que pode configurar nos objetos Route.

Processamento de pedidos

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

  1. O pedido é associado a um recurso Route específico da seguinte forma:

    • Se estiver a usar o Envoy:
      • O cabeçalho do anfitrião no pedido HTTP é comparado com o campo hostnames em cada recurso HTTPRoute ou GRPCRoute para selecionar o recurso Route correto para o pedido. Apenas os recursos HTTPRoute e GRPCRoute têm o campo hostnames.
      • O endereço IP é correspondido para encaminhar o tráfego TCP através de TCPPRoute.
      • O SNI e o ALPN são usados para a passagem direta de TLS através do TLSRoute.
      • Os recursos HTTPRoute e GRPCRoute associados a um Mesh ou a um Gateway têm de ter nomes de anfitrião exclusivos. Se tentar anexar várias rotas com nomes de anfitriões em conflito, a configuração é rejeitada.
      • Da mesma forma, o campo IP:Port do elemento TCPRoute tem de ser exclusivo ou a configuração é rejeitada.
      • Da mesma forma, o SNI e o ALPN têm de ser exclusivos para o TLSRoute.
      • Se existirem nomes de anfitrião sobrepostos, como a.example.com e *.example.com, o pedido corresponde à rota mais específica.
    • Se estiver a usar gRPC sem proxy:
      • Os clientes gRPC sem proxy usam o esquema de resolução de nomes xds. Resolve o hostname[:port] no URI de destino enviando um pedido ao Cloud Service Mesh.
      • Apenas a porta de um recurso GRPCRoute é comparada com a porta no URI de destino (por exemplo, xds:///example.hostname:8080). O URI de destino tem de corresponder exatamente à string no campo hostnames do recurso GRPCRoute.

  2. O recurso Route pode conter mais informações e regras de encaminhamento.

  3. 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 de back-end para o qual o pedido é 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 Mesh global
  • Um HTTPRoute ou um GRPCRoute

A maioria da configuração é feita no HTTPRoute. Depois de criar o mapa da regra de encaminhamento inicial, só tem de modificar o recurso HTTPRoute.

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 ao nome de anfitrião de HTTPRoute:

    1. Em seguida, é avaliado o RouteRule. O elemento RouteRule especifica como fazer a correspondência do tráfego e como encaminhar o tráfego quando é encontrada uma correspondência.
    2. Cada RouteRule contém uma ou mais correspondências de rotas 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 no elemento RouteAction.

Para mais informações sobre os campos de recursos da HTTPRoutee como funcionam, consulte a documentação da API de serviços de rede.

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.

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

  1. Tal como no encaminhamento simples, o anfitrião do pedido é comparado com as regras de anfitrião que configura no HTTPRoute ou GRPCRoute. Se o anfitrião de um pedido corresponder ao nome de anfitrião, o HTTPRoute ou o GRPCRoute é avaliado.
  2. Depois de selecionar um trajeto, pode aplicar ações.

Encaminhamento avançado

O encaminhamento avançado é semelhante ao encaminhamento simples descrito anteriormente, exceto que pode especificar 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 network services.

Ao combinar parâmetros de anfitrião, caminho, cabeçalho e consulta com 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
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 redirect [pathredirect?] 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 requestHeaderModifier/responseHeaderModifier? 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 weiDestination.serviceNameght

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 como funcionam, consulte a página da API de serviços de rede.

Em cada regra de encaminhamento, pode especificar uma das seguintes ações de encaminhamento:

  • Encaminhe o tráfego para um único serviço (destination.serviceName)
  • Divida o tráfego entre vários serviços (destination.weight)
  • URLs de redirecionamento (redirect)

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 ou respostas (requestHeaderModifier/responseHeaderModifier)
  • 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 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.

Distribua o 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 sua 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 os seguintes documentos:

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, em Configure a gestão avançada de tráfego com o Envoy e Configure a gestão avançada de tráfego com serviços gRPC sem proxy.

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)

Para mais informações sobre o equilíbrio de carga com a Cloud Service Mesh, consulte a vista geral do equilíbrio de carga avançado.

O que se segue?