Visão geral do gerenciamento de tráfego avançado
Este documento é destinado a administradores e serviços de malha ou plataforma desenvolvedores que têm um nível intermediário a avançado de familiaridade Conceitos do Cloud Service Mesh e da malha de serviço e quem determina e configura o tráfego é gerenciado em uma implantação do Cloud Service Mesh.
O Cloud Service Mesh oferece recursos avançados de gerenciamento de tráfego que oferecem controle granular sobre como o tráfego é processado. O Cloud Service Mesh é compatível com os seguintes casos de uso:
- Roteamento de tráfego detalhado de solicitações para um ou mais serviços.
- Divisão de tráfego com base no peso para distribuir o tráfego entre vários serviços.
- Políticas de espelhamento de tráfego que enviam solicitações para um serviço de depuração e
cópias para outro. O espelhamento de tráfego não é compatível com o
TCPRoute
. ou o recursoTLSRoute
. - Distribuição de tráfego ajustada pelos back-ends de um serviço para melhorar a carga se equilibrarem.
Esses recursos avançados de gerenciamento de tráfego permitem que você alcance seus objetivos de disponibilidade e desempenho. Um dos benefícios de usar Para esses casos de uso, é possível atualizar o modo como o tráfego é gerenciado sem precisar modificar o código do aplicativo.
O gerenciamento de tráfego em uma malha de serviço do Cloud Service Mesh depende do seguinte recursos:
- O recurso
Mesh
, que identifica a malha de serviço e representa a responsável por encaminhar o tráfego e aplicar políticas. O recursoMesh
também identifica a porta de interceptação de tráfego. Gateway
, que identifica proxies do meio e representa os que detecta em uma lista de pares endereço IP:porta, encaminha tráfego e aplica políticas.Route
, que pode ser um de vários tipos e que contém de roteamento de tráfego para a malha.Route
recurso identifica nomes de host e portas que os clientes podem usar para rotear tráfego para o back-end serviços. Confira a seguir os tipos de recursosRoute
:HTTPRoute
, que está disponível apenas em malhas que usam proxies Envoy. Quando você usar o recursoHTTPRoute
para configurar os proxies Envoy para enviar solicitações, todos os recursos descritos neste documento estão disponíveis.TCPRoute
, que está disponível apenas em malhas que usam proxies Envoy.TLSRoute
, que está disponível apenas em malhas que usam proxies Envoy.GRPCRoute
, que está disponível em malhas usando proxies sidecar do Envoy e sem proxy. Quando você usa serviços ou aplicativos gRPC sem proxy o Cloud Service Mesh, alguns dos recursos descritos neste não estão disponíveis.
- Serviço de back-end, a que os recursos
Route
estão associados.
Configuração
Para configurar o gerenciamento de tráfego avançado, use as mesmas Route
e
os recursos dos serviços de back-end usados ao configurar o Cloud Service Mesh.
O Cloud Service Mesh, por sua vez, configura proxies Envoy e gRPC sem proxy.
para aplicar as políticas de gerenciamento de tráfego avançadas que você
para cima.
Em geral, você faz o seguinte:
- Configurar um recurso
Mesh
para identificar a malha de serviço. Configure recursos
Route
para realizar as ações abaixo, com base no características da solicitação de saída:Selecione o serviço de back-end para onde as solicitações são roteadas.
Opcionalmente, realize outras ações.
Configure o serviço (back-end) para controlar como o tráfego é distribuído para back-ends e endpoints depois que um serviço de destino é selecionado.
Roteamento de tráfego e ações
No Cloud Service Mesh, o tráfego é roteado com base nos valores do recurso Mesh
,
Route
e de serviço de back-end. Todo o gerenciamento de tráfego avançado
recursos relacionados a roteamento e ações são configurados com o Route
objetos.
As seções a seguir descrevem os recursos avançados de gerenciamento de tráfego que
que podem ser configuradas nos objetos Route
.
Processamento de solicitações
Quando um cliente envia uma solicitação, ela é tratada conforme descrito nas etapas a seguir:
A solicitação corresponde a um recurso
Route
específico da seguinte maneira:- Se você usa o Envoy:
- O cabeçalho do host na solicitação HTTP corresponde ao
hostnames
em cada recursoHTTPRoute
ouGRPCRoute
para selecionar oRoute
para a solicitação. ApenasHTTPRoute
eGRPCRoute
recursos têm o campohostnames
. - O endereço IP corresponde ao roteamento do tráfego TCP usando
TCPPRoute
. - O SNI e o ALPN são usados para a passagem TLS com
TLSRoute
. - Os recursos
HTTPRoute
eGRPCRoute
associados a umMesh
ou umGateway
precisa ter nomes de host exclusivos. Se você tentar anexar vários rotas que tenham nomes de host conflitantes, a configuração será rejeitada. - Da mesma forma, o campo
IP:Port
doTCPRoute
precisa ser exclusivo ou o é rejeitada. - Da mesma forma, o SNI e o ALPN precisam ser exclusivos para
TLSRoute
. - Se houver nomes de host sobrepostos, como
a.example.com
e*.example.com
, a solicitação corresponde à rota mais específica.
- O cabeçalho do host na solicitação HTTP corresponde ao
- Se você estiver usando o gRPC sem proxy:
- Os clientes gRPC sem proxy usam o esquema de resolução de nomes
xds
. Eles Resolver ohostname[:port]
no URI de destino enviando uma solicitação para o Cloud Service Mesh. - Apenas a porta de um recurso
GRPCRoute
é comparada à porta no URI de destino (por exemplo,xds:///example.hostname:8080
). O URI de destino precisa corresponder exatamente a string no campohostnames
daGRPCRoute
.
- Os clientes gRPC sem proxy usam o esquema de resolução de nomes
- Se você usa o Envoy:
O recurso
Route
pode conter mais informações e regras de roteamento.Depois que o serviço de back-end de destino é selecionado, o tráfego é distribuído entre os back-ends ou endpoints desse serviço de back-end, de acordo com a configuração do recurso do serviço de back-end.
A segunda etapa é descrita na seção a seguir, Roteamento simples com base no host e no caminho. A terceira etapa é discutida em Roteamento e ações avançados.
Roteamento simples com base no host e no caminho
O Cloud Service Mesh oferece suporte a um esquema de roteamento simplificado e a outros esquema avançado. No esquema simples, você especifica um host e, opcionalmente, um caminho. O host e o caminho da solicitação são avaliados para determinar o serviço de back-end para onde a solicitação será encaminhada.
- O host da solicitação é a parte do nome de domínio de um URL. Por exemplo,
a parte do host do URL
http://example.com/video/
éexample.com
. - O caminho da solicitação é a parte do URL que segue o nome do host. Por exemplo,
a parte do caminho do URL
http://example.com/video/
é/video
.
Você configura o roteamento simples com base no host e no caminho no mapa de regras de roteamento, que consiste no seguinte:
Mesh
global- Um
HTTPRoute
ou umGRPCRoute
A maior parte da configuração é feita no HTTPRoute
. Depois de criar o
mapa de regras de roteamento inicial, você só precisa modificar o recurso HTTPRoute
.
A regra mais simples é uma regra padrão, em que você especifica apenas uma regra de host curinga
(*
) e uma correspondência de caminho com um serviço padrão. Depois de criar
a regra padrão, é possível adicionar outras regras para especificar diferentes hosts e
caminhos. As solicitações de saída são avaliadas de acordo com essas regras, da seguinte maneira:
Se o host de uma solicitação (como
example.com
) corresponde ao nome do host doHTTPRoute
:- A
RouteRule
é avaliada em seguida. ORouteRule
especifica como fazer a correspondência e como roteá-lo quando há correspondência. - Cada
RouteRule
contém uma ou mais correspondências de rota que foram avaliadas no caminho da solicitação. - Se uma correspondência for encontrada, a solicitação será encaminhada para o serviço especificado em
o
RouteAction
.
- A
Para mais informações sobre os campos de recurso do HTTPRoute
e como eles funcionam,
consulte a documentação da API de serviço de rede.
Roteamento avançado e ações
Se você quiser fazer mais do que encaminhar uma solicitação com base no host e no caminho dela, poderá configurar regras avançadas para rotear solicitações e realizar ações.
De modo geral, o roteamento avançado e as ações funcionam da seguinte maneira:
- Assim como no roteamento simples, o host da solicitação é comparado ao host
que você configura em
HTTPRoute
ouGRPCRoute
. Se um pedido host corresponder ao nome do host,HTTPRoute
ouGRPCRoute
será avaliado. - Depois que uma rota for selecionada, você poderá aplicar ações.
Roteamento avançado
O roteamento avançado é semelhante ao roteamento simples descrito antes, mas é possível especificar outras condições de correspondência. Por exemplo, é possível especificar que uma regra corresponderá ao cabeçalho de uma solicitação se o nome do cabeçalho corresponder exatamente ou apenas parcialmente, por exemplo, com base no prefixo ou no sufixo. A correspondência pode ser feita com base na avaliação do nome do cabeçalho com uma expressão regular ou em outros critérios, como a verificação da presença de um cabeçalho.
Para mais condições de correspondência e detalhes para headerMatches
e
queryParameterMatches
, consulte a página
API REST network services
.
Ao combinar os parâmetros de host, caminho, cabeçalho e consulta com correspondência você pode criar regras altamente expressivas que se encaixam no seu tráfego exato de gerenciamento de projetos. Veja mais detalhes na tabela a seguir.
Aplicativo baseado em HTTP | Aplicativo baseado em gRPC | |
---|---|---|
Hosts HTTP versus hosts gRPC | O host é a parte do nome de domínio do URL que o aplicativo chama. Por exemplo, a parte do host do URL
|
O host é o nome que um cliente usa no URI do canal para se conectar a um serviço específico. Por exemplo, a parte do host do URI do canal
|
Caminhos HTTP versus caminhos gRPC | O caminho é a parte do URL que segue o nome do host. Por exemplo, a parte do caminho do URL |
O caminho está no cabeçalho Por exemplo, se você chamar o método |
Outros cabeçalhos gRPC (metadados) | O gRPC é compatível com o envio de metadados entre o cliente gRPC e o servidor gRPC para fornecer outras informações sobre uma chamada RPC. Esses metadados estão na forma de pares de chave-valor, transferidos como cabeçalhos na solicitação HTTP/2. |
Ações
O Cloud Service Mesh permite especificar ações que o Envoy envia proxies ou que os aplicativos gRPC sem proxy realizam ao processar uma solicitação. As ações a seguir pode ser configurado com o Cloud Service Mesh.
Ação | Nome do campo da API | Descrição |
---|---|---|
Redirecionamentos | redirect |
Retorna um código de resposta 3xx configurável. Ele também define o
cabeçalho de resposta Location com o URI apropriado,
substituindo o host e o caminho, conforme especificado na ação de redirecionamento.
|
Regravações de URL | urlRewrite |
Regrava a parte do nome do host e do caminho do URL ou ambas, antes de enviar uma solicitação ao serviço de back-end seleccionado. |
Transformações de cabeçalho | requestHeaderModifier/responseHeaderModifier |
Adiciona e remove cabeçalhos antes de enviar uma solicitação ao serviço de back-end. Também é possível adicionar ou remover cabeçalhos de resposta depois de receber uma resposta do serviço de back-end. |
Espelhamento do tráfego | requestMirrorPolicy |
Além de encaminhar a solicitação ao serviço de back-end selecionado, envia outra idêntica ao serviço de back-end de espelhamento configurado, de forma autônoma. O balanceador de carga não espera uma resposta do back-end a que envia a solicitação espelhada. O espelhamento é útil para testar uma nova versão de um serviço de back-end. Ele pode ser usado também para depurar erros de produção em uma versão de depuração do serviço de back-end, mas não em uma versão de produção. |
Divisão de tráfego baseada no peso | weiDestination.serviceNameght |
Permite que o tráfego de uma regra correspondente seja distribuído a vários serviços de back-end, de maneira proporcional a um peso definido pelo usuário e atribuído ao serviço de back-end individual. Esse recurso é útil para configurar implantações em estágios ou testes A/B. Por exemplo, a ação de rota pode ser configurada para que 99% do tráfego seja enviado a um serviço que executa uma versão estável de umaplicativo. Já 1% do tráfego é enviado a um serviço separado que executa uma versão mais recente desse aplicativo. |
Novas tentativas | retryPolicy |
Configura as condições em que o balanceador de carga faz novas tentativas das solicitações com falha, quanto tempo o balanceador aguarda antes de tentar novamente e o número máximo de novas tentativas permitidas. |
Tempo limite | timeout |
Especifica o tempo limite da rota selecionada. Ele é calculado com base no momento entre o processamento total da solicitação e da resposta. O tempo limite inclui todas as novas tentativas. |
Injeção de falha | faultInjectionPolicy |
Insere erros ao atender às solicitações para simular falhas, incluindo alta latência, sobrecarga, de serviço, falhas de serviço e particionamento de rede. Esse recurso é útil para testar a resiliência de um serviço a falhas simuladas. |
Políticas de segurança | corsPolicy |
As políticas de compartilhamento de recursos entre origens (CORS, na sigla em inglês) processam as configurações para aplicar solicitações CORS. |
Para mais informações sobre ações e como elas funcionam, consulte a API de serviços de rede.
Em cada regra de rota, você pode especificar uma das seguintes ações:
- Encaminhar o tráfego para um único serviço (
destination.serviceName
) - Dividir o tráfego entre vários serviços (
destination.weight
) - URLs de redirecionamento (
redirect
)
Além disso, é possível combinar qualquer uma das ações de rota mencionadas anteriormente a uma ou mais destas, chamadas de ações de complemento no Console do Cloud:
- Manipular cabeçalhos de solicitação ou resposta (
requestHeaderModifier/responseHeaderModifier
) - Espelhar tráfego (
requestMirrorPolicy
) - Reescrever o host, o caminho ou ambos do URL (
urlRewrite
) - Tentar novamente solicitações com falha (
retryPolicy
) - Definir tempo limite (
timeout
). - Inserir falhas em um percentual do tráfego (
faultInjectionPolicy
). - Adicionar política de CORS (
corsPolicy
).
Como as ações são associadas a regras específicas, o proxy Envoy ou aplicativo gRPC sem proxy pode aplicar diferentes ações com base na solicitação que que ele gerencia.
Distribuir o tráfego entre os back-ends de um serviço
Conforme mencionado em Processamento de solicitações, quando um cliente gerencia uma solicitação de saída, primeiro ele seleciona um serviço de destino. Depois disso, ele precisa descobrir qual back-end ou endpoint deve receber a solicitação.
No diagrama anterior, Regra foi simplificada. Em geral, Regra é uma regra de host, uma correspondência de caminho e uma ou mais regras de caminho ou rota. O serviço de destino é o Serviço de back-end. Backend 1, …, e Backend n recebem e processam a solicitação. Esses back-ends podem ser instâncias de máquina virtual (VM) do Compute Engine que hospedam no código do aplicativo do lado do servidor.
Por padrão, o cliente que gerencia a solicitação envia solicitações para o back-end íntegro mais próximo que tenha capacidade. Para evitar a sobrecarga de um back-end específico, ele usa o algoritmo de balanceamento de carga round-robin para balancear solicitações subsequentes em outros back-ends do serviço de destino. Em alguns casos, convém ter um controle mais refinado sobre esse comportamento.
Balanceamento de carga, afinidade da sessão e proteção de back-ends
É possível 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 endpoints de rede (NEG, na sigla em inglês) ou um grupo de instâncias gerenciadas (MIG, na sigla em inglês) é selecionado após a seleção de um serviço de destino. É possível configurar o modo de balanceamento para distribuir a carga com base em conexões simultâneas e taxa de solicitação. |
Política de balanceamento de carga | localityLbPolicy |
Define o algoritmo de balanceamento de carga usado para distribuir o tráfego entre back-ends em um NEG ou MIG. Para otimizar o desempenho, é possível escolher entre vários algoritmos, como "round robin" ou "menor solicitação". |
Afinidade da sessão | sessionAffinity |
Fornece uma tentativa de melhor esforço para enviar solicitações de um cliente específico ao mesmo back-end enquanto ele estiver íntegro e tiver capacidade. O Cloud Service Mesh oferece suporte a quatro opções afinidade da sessão: baseado em cookies, cabeçalhos HTTP e afinidade de cookie gerado (que o Cloud Service Mesh gera por conta própria). |
Hash consistente | consistentHash |
Fornece afinidade de sessão suave com base em cabeçalhos HTTP, cookies ou outras propriedades. |
Disjuntores | circuitBreakers |
Define limites máximos no volume de conexões e solicitações por conexão para um serviço de back-end. |
Detecção de outlier | outlierDetection |
Especifica os critérios para (1) remover back-ends não íntegros ou endpoints de MIGs ou NEGs e (2) adicionar um back-end ou endpoint de volta quando ele é considerado íntegro o suficiente para receber tráfego novamente. A verificação de integridade associada ao serviço determina se um back-end ou endpoint é considerado íntegro. |
Para mais informações sobre diferentes opções de distribuição de tráfego e como eles funcionam, consulte os seguintes documentos:
Exemplos de casos de uso
O gerenciamento de tráfego avançado atende a muitos casos de uso. Nesta seção, você verá alguns exemplos detalhados.
Você pode encontrar mais exemplos, inclusive exemplos de código, em Configurar o gerenciamento de tráfego avançado com o Envoy e Configurar o gerenciamento de tráfego avançado com serviços gRPC sem proxy.
Roteamento de tráfego detalhado para personalização
Você pode rotear o tráfego para um serviço com base nos parâmetros da solicitação. Por exemplo,
é possível usar esse serviço para fornecer uma experiência mais personalizada para
usuários do Android. No diagrama a seguir, o Cloud Service Mesh configura
sua malha de serviço para enviar solicitações com o cabeçalho user-agent:Android
para sua
Android em vez de ao serviço genérico.
user-agent
definido como Android
(clique para ampliar)Divisão de tráfego baseada em peso para implantações mais seguras
A implantação de uma nova versão de um serviço de produção atual pode ser arriscada. Mesmo depois que os testes forem aprovados em um ambiente de teste, talvez você não queira encaminhar imediatamente todos os usuários para a nova versão.
O Cloud Service Mesh permite definir divisões de tráfego baseadas em peso para distribuir o tráfego entre vários serviços. Por exemplo, é possível enviar 1% do tráfego para a nova versão do seu serviço, monitorar se tudo funciona e aumentar gradualmente a proporção de tráfego para o novo serviço.
Espelhamento de tráfego para depuração
Ao depurar um problema, pode ser útil enviar cópias do tráfego de produção para um serviço de depuração. O Cloud Service Mesh permite que você configure solicitações políticas de espelhamento para que as solicitações sejam enviadas a um serviço e cópias desses as solicitações são enviadas para outro serviço.
Balanceamento de carga ajustado para desempenho
Dependendo das características do seu aplicativo, você pode melhorar o desempenho e a disponibilidade ajustando o modo como o tráfego é distribuído entre os back-ends de um serviço. Com o Cloud Service Mesh, é possível aplicar algoritmos avançados de balanceamento de carga para distribuir o tráfego conforme a às suas necessidades.
O diagrama a seguir, em contraste com os diagramas anteriores, mostra um serviço de backend de destino (Serviço de produção) e os back-ends dele (Máquina virtual 1, Máquina virtual 2, Máquina Virtual 3). Com o gerenciamento de tráfego avançado, é possível 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.
Para mais informações sobre o balanceamento de carga com o Cloud Service Mesh, consulte Visão geral do balanceamento de carga avançado.
A seguir
- Para direcionar o tráfego de fora da malha para a malha, consulte Tráfego de entrada para a malha.