Desacoplamento de microsserviços com gRPC

O gRPC pode fazer solicitações assíncronas, mas ainda é um padrão de RPC e, portanto, é principalmente para quando você não se importa com a resposta, não para implementar sistemas de mensagem (sub / pub).

O que eu faço é, se eu precisar de RPC, eu uso gRPC para comunicação e ProtocolBuffers para serializar os dados, e quando eu precisar de mensagens eu uso o AMQP, também com ProtocolBuffers.

Faz sentido ter o gRPC armazenando em buffer os dados por meio de um sistema de mensagens se você precisar escaloná-los, ter roteamento entre servidores ou se desejar recursos como mensagens off-line e também notificação de recebimento de mensagens.

Meu conselho é diagramar os cenários de comunicação no papel, e deve ficar claro qual tipo de serviço você precisa.

Além disso, observe que o uso de gRPC é principalmente turn-key e o AMQP não é; geralmente sistemas de mensagens exigirão que você escreva muito código. Se você não está realmente escalando muito, então pode ser uma quantidade excessiva de trabalho. Além disso, acho que é raro você querer os dois; o padrão RPC é principalmente um subconjunto do padrão de mensagens. Se você for superar o RPC, use as mensagens do IMO inicial.

gRPC e filas | corretores não são mutuamente exclusivos. Não é como se tivéssemos que escolher um ou outro. Podemos escolher um, ambos ou nenhum. Também poderíamos usar um servidor SMTP como uma fila ou um arquivo de texto simples.

Eles podem se complementar, pois satisfazem propósitos diferentes.

Desacoplar

Pense em um pipeline em que cada estágio é um processo (serviço).

[Process A] < ----- > [Process B]

^{As setas denotam cardinalidade e dependência.}

O diagrama mostra dois serviços que são cliente e servidor ao mesmo tempo. A é cliente e servidor de B . E vice versa. Tal IPC envolve serviços prestando atenção uns aos outros, independentemente do protocolo de comunicação (HTTP 1/2, web sockets, sockets, etc.).

Agora, coloque uma fila ou intermediário entre

[Process A]  <----- > [Queue|Broker] <------> [Process B]

Filas e corretores quebram a cardinalidade entre os serviços, daí a dependência. Eles não precisam mais estar cientes um do outro. Poderíamos até descartar as interfaces públicas dos serviços, já que elas não seriam mais necessárias. Sem interface pública, sem acoplamento.

Adotando recursos

Filas e corretores são geralmente projetados para serem eficientes / confiáveis / consistentes / escaláveis / resilientes em relação à E / S e podemos fornecer à nossa arquitetura esses recursos implementando um ou outro. Por exemplo, o gRPC é um mecanismo de transporte para casos de uso de streaming de solicitação / resposta e (não persistente). Se não pudermos pagar mensagens perdidas, provavelmente teremos que procurar alternativas ou componentes arquitetônicos complementares. Filas e corretores podem fazer o trabalho. A persistência não é o único recurso a fornecer ao nosso IPC. Para mencionar alguns

• Consistência e persistência de mensagens
• Captura e envio em lote
• Tratamento de erros
• Failover
• Repetir
• Escalabilidade
• Modularidade ou compartimentalização (com corretores ou filas dedicados)
• Compatibilidade com vários protocolos prontos para uso
• Rastreabilidade de tráfego
• Monitoramento de tráfego
• Ferramentaria

Links relacionados

Eu encontrei postagem no blog , que mergulha um pouco mais no assunto.

Vale mencionar a postagem no blog do Nginx sobre implementações do Microservice e do IPC .

Sim, o pedido irá diretamente para o servidor.

O gRPC permite que um desenvolvedor gere interfaces para os vários serviços. Os clientes só precisam depender da interface e não de uma implementação.

normalmente interfaces podem ser projetadas para serem compatíveis com versões anteriores. Assim, quando um serviço é alterado, uma nova funcionalidade é adicionada à interface e nenhuma funcionalidade é removida. Portanto, os clientes antigos podem conversar com versões mais novas da interface, enquanto novos clientes podem acessar os novos recursos. Depois que todos os clientes forem atualizados, as antigas partes obsoletas da interface poderão ser removidas.