1. Comunicação Síncrona

A comunicação síncrona envolve uma interação em tempo real onde um serviço envia uma solicitação para outro e pausa sua operação até que uma resposta seja recebida. APIs REST e gRPC são protocolos comuns usados ​​para facilitar esse tipo de comunicação.

1.1 API RESTful

Uma API RESTful (Representational State Transfer) é um dos métodos mais comuns para os serviços se comunicarem entre si em um sistema de microsserviços. REST utiliza formatos HTTP/HTTPS e JSON ou XML para troca de dados.

Normalmente, os serviços interagem entre si invocando diretamente a API de outro serviço.

Exemplo de solicitação e resposta:

GET /users/12345 HTTP/1.1
Host: api.userservice.com
Accept: application/json
Authorization: Bearer your-access-token

{
  "userId": "12345",
  "name": "Michel J",
  "email": "[email protected]",
  "address": "Mountain View, Santa Clara, California"
}

Exemplo de código-fonte

import org.springframework.web.client.RestTemplate;
import org.springframework.http.ResponseEntity;

public class OrderService {

    private final RestTemplate restTemplate = new RestTemplate();
    private final String userServiceUrl = "https://api.userservice.com/users/";

    public User getUserById(String userId) {
        String url = userServiceUrl   userId;
        ResponseEntity response = restTemplate.getForEntity(url, User.class);
        return response.getBody();
    }
}

Vantagens:

Fácil de implantar e integrar com várias linguagens e ferramentas.

Pode usar facilmente ferramentas de teste e monitoramento.

Desvantagens:

Pode não ser eficiente para requisitos de alta velocidade devido à sua natureza síncrona.

Pode encontrar dificuldades no tratamento de erros ou desconexões de rede.

1,2 gRPC

gRPC, que significa Google Remote Procedure Call, é uma estrutura RPC universal de código aberto e de alto desempenho. Ele utiliza HTTP/2 para transferência de dados eficiente e normalmente depende de buffers de protocolo, um mecanismo extensível de linguagem neutra, plataforma neutra para serializar dados estruturados, para definir a estrutura dos dados que estão sendo enviados e recebidos.

Exemplo, definição de buffers de protocolo

syntax = "proto3";

package userservice;

// Define message User
message User {
    string userId = 1;
    string name = 2;
    string email = 3;
    string address = 4;
}

// Define service UserService
service UserService {
    rpc GetUserById (UserIdRequest) returns (User);
}

// Define message UserIdRequest
message UserIdRequest {
    string userId = 1;
}

Para o serviço de gerenciamento de usuários, você deve implementar um servidor gRPC que siga a definição de serviço fornecida no arquivo .proto. Isso inclui a criação da lógica necessária no lado do servidor para lidar com solicitações gRPC recebidas e gerar respostas apropriadas.

import io.grpc.stub.StreamObserver;
import userservice.User;
import userservice.UserIdRequest;
import userservice.UserServiceGrpc;

public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {

    @Override
    public void getUserById(UserIdRequest request, StreamObserver responseObserver) {
        // Assuming you have a database to retrieve user information.
        User user = User.newBuilder()
                .setUserId(request.getUserId())
                .setName("Michel J")
                .setEmail("[email protected]")
                .setAddress("Mountain View, Santa Clara, California")
                .build();

        responseObserver.onNext(user);
        responseObserver.onCompleted();
    }
}

import io.grpc.Server;
import io.grpc.ServerBuilder;

public class UserServer {
    public static void main(String[] args) throws Exception {
        Server server = ServerBuilder.forPort(9090)
                .addService(new UserServiceImpl())
                .build()
                .start();

        System.out.println("Server started on port 9090");
        server.awaitTermination();
    }
}

Vantagens:

Alto desempenho e eficiência de largura de banda devido ao uso de HTTP/2 e buffers de protocolo.

Suporta várias linguagens de programação e possui boa escalabilidade.

Desvantagens:

Requer uma camada de tradução se os serviços não suportarem gRPC.

Pode ser mais complexo de implantar e gerenciar.

2. Comunicação Assíncrona

Comunicação assíncrona refere-se ao processo de um serviço enviar uma solicitação a outro serviço sem bloquear sua própria operação para aguardar uma resposta. Isso geralmente é obtido por meio de filas de mensagens ou sistemas de publicação/assinatura.

1. Filas de mensagens

Sistemas de enfileiramento de mensagens, como RabbitMQ e Apache ActiveMQ, facilitam a comunicação assíncrona entre serviços.

Vantagens:

Escalabilidade e tolerância a falhas aprimoradas: o sistema pode lidar melhor com cargas de trabalho maiores e é menos suscetível a falhas.

Carga reduzida nos serviços: Ao desacoplar o envio e o recebimento de solicitações, os serviços principais podem se concentrar no processamento de tarefas sem serem sobrecarregados por solicitações constantes.

Desvantagens:

Pode exigir esforço adicional para gerenciar e manter: Os sistemas baseados em filas podem ser mais complexos e exigir mais recursos para operar.

Dificuldade em lidar com pedidos e garantir a entrega de mensagens: Garantir que as solicitações sejam processadas na ordem correta e que nenhuma mensagem seja perdida pode ser um desafio técnico.

2.2. Sistema Pub/Sub

Um sistema Pub/Sub (Publicar/Assinar), como Apache Kafka ou Google Pub/Sub, permite que serviços publiquem mensagens e assinem tópicos.

Vantagens:

Suporta fluxos de dados em grande escala e alto rendimento.

Reduz dependências entre serviços.

Desvantagens:

Requer uma camada mais complexa para gerenciar e monitorar tópicos e mensagens.

Pode ser um desafio lidar com problemas de ordem e confiabilidade com mensagens."

Se você estiver interessado, pode ler meus artigos anteriores sobre o tópico pub/sub.

Dead Letter Queue em um Message Broker parte 1

Dead Letter Queue em um Message Broker parte 2

Preocupações de consistência e confiabilidade no sistema Message Broker

3. Comunicação baseada em eventos

A comunicação orientada a eventos ocorre quando um serviço emite um evento e outros serviços respondem ou executam ações com base nesses eventos.

3.1. Eventos Síncronos

Eventos síncronos ocorrem quando um serviço emite um evento e aguarda uma resposta de outros serviços.

Vantagens:

Fácil de controlar e monitorar o processo de processamento de eventos.

Desvantagens:

Pode causar gargalos se os serviços de resposta forem lentos ou encontrarem erros

3.2. Eventos Assíncronos

Eventos assíncronos ocorrem quando um serviço emite um evento e não precisa esperar por uma resposta imediata.

Vantagens:

Reduz o tempo de espera e melhora a escalabilidade.

Ajuda os serviços a operar de forma mais independente e reduz dependências mútuas.

Desvantagens:

Requer mecanismos adicionais para garantir que os eventos sejam processados ​​corretamente e em tempo hábil.

Dificuldade em garantir a ordem e lidar com eventos duplicados.

4. Conclusão

A escolha do método de comunicação entre serviços em um sistema de microsserviços depende de fatores como requisitos de desempenho, confiabilidade e complexidade do sistema. Cada método tem suas próprias vantagens e desvantagens, e a compreensão desses métodos o ajudará a construir um sistema de microsserviços mais eficiente e flexível. Considere cuidadosamente os requisitos do seu sistema para escolher o método de comunicação mais adequado.