Visão geral do Cloud Service Mesh com serviços gRPC sem proxy

Neste guia, fornecemos uma visão geral da arquitetura da Cloud Service Mesh com serviços do gRPC sem proxy, incluindo casos de uso e padrões de arquitetura.

O plano de controle gerenciado do Cloud Service Mesh permite roteamento global, balanceamento de carga e failover regional para casos de uso de malha de serviço e balanceamento de carga. Isso inclui implantações que incorporam proxies sidecar e proxies de gateway. O suporte do Cloud Service Mesh a aplicativos gRPC sem proxy oferece uma modelo de implantação adicional no qual os aplicativos gRPC podem participar e da malha de serviço sem precisar de um proxy sidecar.

Em um exemplo típico, um cliente gRPC estabelece uma conexão com um servidor gRPC que hospeda sua lógica de back-end. O Cloud Service Mesh oferece aos seus clientes gRPC informações sobre quais servidores contatar, como balancear a carga de solicitações para múltiplas instâncias de um servidor, e o que fazer com as solicitações se um servidor não estiver em execução.

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

Como o Cloud Service Mesh funciona com aplicativos gRPC

O Cloud Service Mesh configura os clientes do gRPC com uma versão do gRPC compatível, da mesma forma que os proxies sidecar, como o Envoy, estão configurados. No entanto, Os aplicativos gRPC sem proxy conectados diretamente ao Cloud Service Mesh não precisam proxies sidecar. Em vez disso, o Cloud Service Mesh usa APIs xDS de código aberto para configurar aplicativos gRPC diretamente. Esses aplicativos gRPC atuam como clientes xDS, conectando-se ao plano de controle global do Cloud Service Mesh. Após a conexão, os aplicativos gRPC recebem configuração dinâmica do plano de controle, o que permite a descoberta de endpoints, o balanceamento de carga, o failover regional e as verificações de integridade. Com essa abordagem, é possível ativar recursos adicionais do Cloud Service Mesh de implantação do Google Cloud.

Na primeira ilustração, a malha de serviço é ativada usando um proxy sidecar.

Malha de serviço ativada usando um proxy sidecar.
A malha de serviço ativada com um proxy sidecar (clique para ampliar)

Para configurar um proxy sidecar, o Cloud Service Mesh usa as APIs xDS. Clientes e se comunicam com o servidor pelo proxy sidecar.

Na segunda ilustração, a malha de serviço é ativada sem um proxy sidecar com o uso de um cliente gRPC sem proxy.

Malha de serviço ativada usando gRPC sem proxy.
Uma malha de serviço ativada usando o gRPC sem proxy (clique para ampliar)

Se você estiver implantando apenas serviços gRPC configurados pelo Cloud Service Mesh, será possível criar uma malha de serviço sem implantar nenhum proxy. Isso facilita a implantação de recursos de malha de serviço nos aplicativos gRPC.

Resolução de nome

Para implantações sem proxy, a resolução de nomes funciona das seguintes maneiras:

  1. Defina xds como o esquema de resolução de nomes no canal do cliente gRPC ao se conectar a um serviço. O URI de destino é formatado como xds:///hostname:port. Quando a porta não é especificada, o valor padrão é 80, por exemplo, no URI de destino xds:///example.hostname.
  2. O cliente gRPC resolve o hostname:port no URI de destino enviando um serviço de descoberta de listeners (LDS, na sigla em inglês) para o Cloud Service Mesh.
  3. O Cloud Service Mesh pesquisa as regras de encaminhamento configuradas que têm uma porta correspondente. Em seguida, ele procura o mapa de URL correspondente para uma regra de host que corresponda a hostname:port. Ele retorna a configuração de roteamento associada ao cliente gRPC.

As regras de host que você configura no Cloud Service Mesh precisam ser exclusivas em todos os mapas de URL. Por exemplo, example.hostname, example.hostname:80 e example.hostname:8080 são regras diferentes.

Resolução de nome com diferentes tipos de implantação

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

O cliente gRPC usa o esquema de resolução de nomes xds para se conectar a um serviço. permitindo que o cliente receba a configuração de serviço do Cloud Service Mesh. O cliente gRPC se comunica diretamente com o servidor gRPC.

É possível combinar padrões de implantação de proxy sidecar e sem proxy para aumentar a flexibilidade. Isso é muito útil quando sua organização e rede oferecem suporte a várias equipes com diferentes requisitos de recursos, necessidades operacionais e versões de gRPC.

Na ilustração a seguir, os clientes gRPC e sem proxy com um proxy de arquivo secundário se comunicam com um servidor gRPC. Os clientes gRPC com proxies sidecar usam o esquema de resolução de nomes dns.

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 com arquivo secundário (clique para ampliar)

Casos de uso

Os casos de uso a seguir ajudam você a entender quando usar a Cloud Service Mesh com aplicativos gRPC sem proxy. A implantação pode incluir aplicativos gRPC sem proxy, aplicativos gRPC com proxies sidecar ou um mix de ambos.

Eficiência de recursos em uma malha de serviço de grande escala

Se a malha de serviço incluir centenas ou milhares de clientes e back-ends, você poderá descobrir que o consumo total de recursos da execução de proxies de arquivo secundário começa a aumentar. Quando você usa aplicativos gRPC sem proxy, não é necessário introduzir proxies de arquivo secundário na implantação. Uma abordagem sem proxy pode resultar em ganhos de eficiência.

Aplicativos gRPC de alto desempenho

Em alguns casos de uso, cada milésimo de segundo de latência da solicitação e da resposta é importante. Nesse caso, é possível que a latência seja reduzida ao usar um aplicativo gRPC sem proxy, em vez de passar todas as solicitações por um proxy de arquivo secundário do lado do cliente e, possivelmente, um proxy de arquivo secundário do lado do servidor.

Malha de serviço para ambientes em que não é possível implantar proxies secundários

Em alguns ambientes, talvez não seja possível executar um proxy secundário como um processo adicional junto com o aplicativo cliente ou servidor. Talvez não seja possível configurar a pilha de rede de uma máquina para interceptar e redirecionar solicitações, por exemplo, usando iptables. Nesse caso, é possível usar a Cloud Service Mesh com aplicativos gRPC sem proxy para apresentar os recursos de malha de serviço aos seus aplicativos gRPC.

Malha de serviço heterogênea

Como os aplicativos gRPC sem proxy e o Envoy se comunicam com a Cloud Service Mesh, a malha de serviço pode incluir os dois modelos de implantação. A inclusão de ambos os modelos permite que você satisfaça as necessidades operacionais, de desempenho e de recursos, específicas de diferentes aplicativos e equipes de desenvolvimento.

Migrar de malha de serviço com proxies para malha sem proxies

Se você já tiver um aplicativo gRPC com um proxy sidecar configurado pela Cloud Service Mesh, poderá fazer a transição para um aplicativo gRPC sem proxy.

Quando um cliente gRPC é implantado com um proxy de arquivo secundário, ele usa o DNS para resolver o nome do host ao qual está se conectando. O proxy sidecar intercepta para fornecer recursos da malha de serviço.

Para definir se um cliente gRPC usa a rota sem proxy ou a rota de proxy sidecar para se comunicar com um servidor gRPC, basta modificar o esquema de resolução de nome que ele usa. Os clientes sem proxy usam o esquema de resolução de nome xds, enquanto proxies secundários usam o esquema de resolução de nome dns. Alguns clientes do gRPC podem até mesmo usar a rota sem proxy ao se comunicar com um servidor gRPC, mas usam a rota de proxy sidecar ao se comunicar com outro servidor gRPC. Assim, é possível migrar gradualmente para uma implantação sem proxy.

Para migrar de uma malha de serviço com proxies para uma malha sem proxies, crie um novo serviço do Cloud Service Mesh para uso do cliente gRPC sem proxy. É possível usar as mesmas APIs para configurar o Cloud Service Mesh para os serviços novas versões.

Malha de serviço com um cliente gRPC que se comunica com diferentes serviços usando mecanismos sem proxy e baseados em proxy.
Malha de serviço com um cliente gRPC que se comunica com diferentes serviços usando mecanismos sem proxy e baseados em proxy (clique para ampliar)

Arquitetura e recursos

O modelo de dados de configuração para serviços gRPC sem proxy estende a Modelo de configuração do Cloud Service Mesh, com algumas adições e limitações descritas neste guia. Algumas dessas limitações são temporárias, porque o gRPC sem proxy ainda não é compatível com todos os recursos do Envoy e outros são inerentes ao uso de RPCs. Por exemplo, os redirecionamentos HTTP que usam gRPC não são compatíveis. Para ajudar você a entender o modelo de configuração deste guia, recomendamos que você se familiarize com o Cloud Service Mesh conceitos e configuração.

O diagrama a seguir mostra os recursos que você precisa configurar para aplicativos gRPC sem proxy.

Recursos compatíveis com gRPC sem proxy para balanceamento de carga.
Recursos compatíveis com gRPC sem proxy para balanceamento de carga (clique para ampliar)

Verificações de integridade

Uma verificação de integridade do gRPC pode verificar o status de um serviço gRPC em execução em uma instância de máquina virtual (VM) de back-end ou em um grupo de endpoints de rede (NEG).

Se uma verificação de integridade do gRPC não puder ser usada porque o servidor gRPC não implementa o protocolo de verificação de integridade do gRPC (em inglês), use uma verificação de integridade TCP. Não use uma verificação de integridade HTTP, HTTPS ou HTTP/2.

Para mais informações, consulte Verificação de integridade do gRPC e Sinalização adicional para verificações de integridade do gRPC.

Serviço de back-end

O serviço de back-end define como um cliente gRPC se comunica com um servidor gRPC. Ao criar um serviço de back-end para gRPC, defina o campo de protocolo como GRPC.

  • Um serviço de back-end configurado com um protocolo definido como GRPC também pode ser acessado por aplicativos gRPC por meio de um proxy sidecar. Nessa situação, o cliente gRPC não pode usar o esquema de resolução de nome xds.

  • Em todas as implantações do Cloud Service Mesh, o esquema de balanceamento de carga do serviço de back-end precisa ser INTERNAL_SELF_MANAGED.

Back-ends

Os back-ends hospedam as instâncias do servidor de gRPC. É possível usar grupos de instâncias gerenciadas ou não gerenciadas no Compute Engine e NEGs zonais no Google Kubernetes Engine como back-ends para hospedar as instâncias do servidor gRPC.

A seguir