Vista geral do Cloud Service Mesh com serviços gRPC sem proxy

Este guia oferece uma vista geral da arquitetura da Cloud Service Mesh com serviços gRPC sem proxy, incluindo exemplos de utilização e padrões de arquitetura.

O plano de controlo gerido do Cloud Service Mesh permite o encaminhamento global, o balanceamento de carga e a comutação por falha regional para casos de utilização de balanceamento de carga e service mesh. Isto inclui implementações que incorporam proxies sidecar e proxies de gateway. O suporte da Cloud Service Mesh para aplicações gRPC sem proxy oferece um modelo de implementação adicional no qual as aplicações gRPC podem participar numa service mesh sem precisar de um proxy sidecar.

Num exemplo típico, um cliente gRPC estabelece uma ligação com um servidor gRPC que aloja a lógica do seu back-end. A malha de serviços na nuvem dá aos seus clientes gRPC informações sobre os servidores a contactar, como equilibrar a carga de pedidos para várias instâncias de um servidor e o que fazer com os pedidos se um servidor não estiver em execução.

Para uma vista geral completa de como funciona o Cloud Service Mesh, consulte a vista geral do Cloud Service Mesh.

Como funciona o Cloud Service Mesh com aplicações gRPC

O Cloud Service Mesh configura clientes gRPC com uma versão gRPC suportada, de forma semelhante à configuração de proxies sidecar, como o Envoy. No entanto, as aplicações gRPC sem proxy ligadas diretamente ao Cloud Service Mesh não precisam de proxies sidecar. Em alternativa, o Cloud Service Mesh usa APIs xDS de código aberto para configurar diretamente as aplicações gRPC. Estas aplicações gRPC atuam como clientes xDS, estabelecendo ligação ao plano de controlo global do Cloud Service Mesh. Depois de se ligarem, as aplicações gRPC recebem configuração dinâmica do plano de controlo, o que permite a deteção de pontos finais, o balanceamento de carga, a comutação por falha regional e as verificações de funcionamento. Esta abordagem permite padrões de implementação adicionais da Cloud Service Mesh.

Na primeira ilustração, uma malha de serviços é ativada através de um proxy sidecar.

Uma malha de serviços ativada através da utilização de um proxy sidecar.
Uma malha de serviços ativada através de um proxy sidecar (clique para aumentar)

Para configurar um proxy sidecar, a Cloud Service Mesh usa APIs xDS. Os clientes comunicam com o servidor através do proxy sidecar.

Na segunda ilustração, uma malha de serviços é ativada sem um proxy sidecar através da utilização de um cliente gRPC sem proxy.

Uma malha de serviços ativada através do gRPC sem proxy.
Uma malha de serviços ativada através do gRPC sem proxy (clique para aumentar)

Se estiver a implementar apenas serviços gRPC que o Cloud Service Mesh configura, pode criar uma malha de serviços sem implementar proxies. Isto facilita a disponibilização de capacidades de malha de serviços às suas aplicações gRPC.

Resolução de nomes

A resolução de nomes funciona para implementações sem proxy das seguintes formas:

  1. Define xds como o esquema de resolução de nomes no canal do cliente gRPC quando se liga a um serviço. O URI de destino está formatado como xds:///hostname:port. Quando a porta não é especificada, o valor predefinido é 80. Por exemplo, no URI de destino xds:///example.hostname.
  2. O cliente gRPC resolve o hostname:port no URI de destino enviando um pedido do serviço de deteção de ouvintes (LDS) para a Cloud Service Mesh.
  3. O Cloud Service Mesh procura as regras de encaminhamento configuradas que têm uma porta correspondente. Em seguida, procura o mapa de URL correspondente para uma regra de anfitrião que corresponda a hostname:port. Devolve a configuração de encaminhamento associada ao cliente gRPC.

As regras de anfitrião que configurar no Cloud Service Mesh têm de ser únicas em todos os mapas de URLs. Por exemplo, example.hostname, example.hostname:80 e example.hostname:8080 são regras diferentes.

Resolução de nomes com diferentes tipos de implementação

O esquema de resolução de nomes é diferente para implementações sem proxy e implementações que usam proxies Envoy.

O cliente gRPC usa o esquema de resolução de nomes xds para se ligar a um serviço, o que permite ao cliente receber a configuração do serviço a partir da Cloud Service Mesh. Em seguida, o cliente gRPC comunica diretamente com o servidor gRPC.

Pode combinar padrões de implementação sem proxy e de proxy sidecar para aumentar a flexibilidade. A combinação de padrões é especialmente útil quando a sua organização e rede suportam várias equipas com diferentes requisitos de funcionalidades, necessidades operacionais e versões gRPC.

Na ilustração seguinte, os clientes gRPC sem proxy e os clientes gRPC com um proxy sidecar comunicam com um servidor gRPC. Os clientes gRPC com proxies sidecar usam o esquema de resolução de nomes dns.

Uma malha de serviços composta por clientes gRPC sem proxy e clientes gRPC com proxies sidecar.
Uma malha de serviços composta por clientes gRPC sem proxy e clientes gRPC com proxies sidecar (clique para aumentar)

Exemplos de utilização

Os seguintes exemplos de utilização ajudam a compreender quando pode querer usar a Cloud Service Mesh com aplicações gRPC sem proxy. A sua implementação pode incluir aplicações gRPC sem proxy, aplicações gRPC com proxies sidecar ou uma combinação de ambos.

Eficiência dos recursos numa malha de serviços em grande escala

Se a sua malha de serviços incluir centenas ou milhares de clientes e backends, pode constatar que o consumo total de recursos da execução de proxies sidecar começa a aumentar. Quando usa aplicações gRPC sem proxy, não precisa de introduzir proxies sidecar na sua implementação. Uma abordagem sem proxy pode resultar em ganhos de eficiência.

Aplicações gRPC de alto desempenho

Para alguns exemplos de utilização, cada milissegundo de latência de pedido e resposta é importante. Nesse caso, pode verificar uma latência reduzida quando usa uma aplicação gRPC sem proxy, em vez de transmitir cada pedido através de um proxy sidecar do lado do cliente e, potencialmente, um proxy sidecar do lado do servidor.

Service mesh para ambientes onde não pode implementar proxies sidecar

Em alguns ambientes, pode não conseguir executar um proxy sidecar como um processo adicional juntamente com a aplicação cliente ou servidor. Em alternativa, pode não conseguir configurar a pilha de rede de uma máquina para interceção e redirecionamento de pedidos, por exemplo, através de iptables. Neste caso, pode usar o Cloud Service Mesh com aplicações gRPC sem proxy para introduzir capacidades de service mesh nas suas aplicações gRPC.

Malha de serviço heterogénea

Uma vez que as aplicações gRPC sem proxy e o Envoy comunicam com a Cloud Service Mesh, a sua service mesh pode incluir ambos os modelos de implementação. A inclusão de ambos os modelos permite-lhe satisfazer as necessidades operacionais, de desempenho e de funcionalidades específicas de diferentes aplicações e diferentes equipas de programação.

Migre de uma malha de serviços com proxies para uma malha sem proxies

Se já tiver uma aplicação gRPC com um proxy sidecar com o Cloud Service Mesh configurado, pode fazer a transição para uma aplicação gRPC sem proxy.

Quando um cliente gRPC é implementado com um proxy sidecar, usa o DNS para resolver o nome do anfitrião ao qual está a ligar-se. O proxy complementar interceta o tráfego para fornecer capacidades de malha de serviço.

Pode definir se um cliente gRPC usa a rota sem proxy ou a rota de proxy sidecar para comunicar com um servidor gRPC modificando o esquema de resolução de nomes que usa. Os clientes sem proxy usam o esquema de resolução de nomes xds, enquanto os proxies sidecar usam o esquema de resolução de nomes dns. Alguns clientes gRPC podem até usar a rota sem proxy quando comunicam com um servidor gRPC, mas usam a rota de proxy sidecar quando comunicam com outro servidor gRPC. Isto permite-lhe migrar gradualmente para uma implementação sem proxy.

Para migrar de uma malha de serviços com proxies para uma malha sem proxies, tem de criar um novo serviço da Cloud Service Mesh que o seu cliente gRPC sem proxy usa. Pode usar as mesmas APIs para configurar a Cloud Service Mesh para as versões existentes e novas.

Service mesh com um cliente gRPC que comunica com diferentes serviços através de mecanismos sem proxy e baseados em proxy.
Malha de serviços com um cliente gRPC que comunica com diferentes serviços através de mecanismos sem proxy e baseados em proxy (clique para aumentar)

Arquitetura e recursos

O modelo de dados de configuração para serviços gRPC sem proxy expande o modelo de configuração do Cloud Service Mesh, com algumas adições e limitações descritas neste guia. Algumas destas limitações são temporárias, uma vez que o gRPC sem proxy não suporta todas as funcionalidades do Envoy, e outras são inerentes à utilização de RPCs. Por exemplo, os redirecionamentos HTTP que usam gRPC não são suportados. Para ajudar a compreender o modelo de configuração neste guia, recomendamos que se familiarize com os conceitos e a configuração do Cloud Service Mesh.

O diagrama seguinte mostra os recursos que tem de configurar para aplicações gRPC sem proxy.

Recursos suportados no gRPC sem proxy para o equilíbrio de carga.
Recursos suportados no gRPC sem proxy para o equilíbrio de carga (clique para aumentar)

Verificações de funcionamento

Uma verificação de estado do gRPC pode verificar o estado de um serviço gRPC que está a ser executado numa instância de máquina virtual (VM) de back-end ou num grupo de pontos finais de rede (NEG).

Se não for possível usar uma verificação de estado gRPC porque o seu servidor gRPC não implementa o protocolo de verificação de estado gRPC, use uma verificação de estado TCP. Não use uma verificação de estado HTTP, HTTPS ou HTTP/2.

Para mais informações, consulte os artigos Verificação de estado do gRPC e Indicador adicional para verificações de estado do gRPC.

Serviço de back-end

O serviço de back-end define a forma como um cliente gRPC comunica com um servidor gRPC. Quando cria um serviço de back-end para gRPC, defina o campo de protocolo como GRPC.

  • Também é possível aceder a um serviço de back-end configurado com um protocolo definido como GRPC através de um proxy sidecar. Nessa situação, o cliente gRPC não pode usar o esquema de resolução de nomes xds.

  • Em todas as implementações da Cloud Service Mesh, o esquema de equilíbrio de carga para o serviço de back-end tem de ser INTERNAL_SELF_MANAGED.

Back-ends

Os back-ends alojam as instâncias do servidor gRPC. Pode usar grupos de instâncias geridos ou não geridos no Compute Engine e NEGs zonais no Google Kubernetes Engine como back-ends para alojar as suas instâncias de servidor gRPC.

O que se segue?