1. Comunicación sincrónica

La comunicación sincrónica implica una interacción en tiempo real donde un servicio envía una solicitud a otro y pausa su operación hasta que se recibe una respuesta. Las API REST y gRPC son protocolos comunes que se utilizan para facilitar este tipo de comunicación.

1.1 API REST

Una API RESTful (Transferencia de Estado Representacional) es uno de los métodos más comunes para que los servicios se comuniquen entre sí en un sistema de microservicios. REST utiliza formatos HTTP/HTTPS y JSON o XML para el intercambio de datos.

Normalmente, los servicios interactúan entre sí invocando directamente la API de otro servicio.

Ejemplo de solicitud y respuesta:

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"
}

Ejemplo de código fuente

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();
    }
}

Ventajas:

Fácil de implementar e integrar con varios lenguajes y herramientas.

Puede utilizar fácilmente herramientas de prueba y seguimiento.

Desventajas:

Puede no ser eficiente para requisitos de alta velocidad debido a su naturaleza sincrónica.

Puede encontrar dificultades para manejar errores o desconexiones de red.

1,2 gRPC

gRPC, que significa llamada a procedimiento remoto de Google, es un marco RPC universal de código abierto y de alto rendimiento. Utiliza HTTP/2 para una transferencia de datos eficiente y generalmente se basa en Protocol Buffers, un mecanismo extensible, neutral en cuanto al lenguaje y la plataforma para serializar datos estructurados, para definir la estructura de los datos que se envían y reciben.

Ejemplo, definición 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 el servicio de administración de usuarios, debe implementar un servidor gRPC que cumpla con la definición de servicio proporcionada en el archivo .proto. Esto incluye la creación de la lógica del lado del servidor necesaria para manejar las solicitudes entrantes de gRPC y generar respuestas adecuadas.

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();
    }
}

Ventajas:

Alto rendimiento y eficiencia del ancho de banda gracias al uso de HTTP/2 y Protocol Buffers.

Admite múltiples lenguajes de programación y tiene buena escalabilidad.

Desventajas:

Requiere una capa de traducción si los servicios no son compatibles con gRPC.

Puede ser más complejo de implementar y administrar.

2. Comunicación asincrónica

La comunicación asincrónica se refiere al proceso en el que un servicio envía una solicitud a otro servicio sin bloquear su propia operación para esperar una respuesta. Esto se logra comúnmente a través de colas de mensajes o sistemas de publicación/suscripción.

1. Colas de mensajes

Los sistemas de cola de mensajes, como RabbitMQ y Apache ActiveMQ, facilitan la comunicación asincrónica entre servicios.

Ventajas:

Escalabilidad y tolerancia a fallas mejoradas: el sistema puede manejar mejor cargas de trabajo mayores y es menos susceptible a fallas.

Carga reducida en los servicios: al desacoplar el envío y la recepción de solicitudes, los servicios principales pueden centrarse en procesar tareas sin verse abrumados por solicitudes constantes.

Desventajas:

Puede requerir un esfuerzo adicional para administrar y mantener: los sistemas basados ​​en colas pueden ser más complejos y requerir más recursos para funcionar.

Dificultad para gestionar los pedidos y garantizar la entrega de mensajes: garantizar que las solicitudes se procesen en el orden correcto y que no se pierda ningún mensaje puede ser un desafío técnico.

2.2. Sistema de pub/sub

Un sistema Pub/Sub (Publicación/Suscripción), como Apache Kafka o Google Pub/Sub, permite que los servicios publiquen mensajes y se suscriban a temas.

Ventajas:

Admite flujos de datos a gran escala y de alto rendimiento.

Reduce las dependencias entre servicios.

Desventajas:

Requiere una capa más compleja para gestionar y monitorear temas y mensajes.

Puede ser un desafío manejar los problemas de pedidos y confiabilidad de los mensajes".

Si estás interesado, puedes leer mis artículos anteriores sobre el tema pub/sub.

Cola de mensajes fallidos en un Message Broker parte 1

Cola de mensajes fallidos en un Message Broker parte 2

Preocupaciones de coherencia y confiabilidad dentro del sistema Message Broker

3. Comunicación basada en eventos

La comunicación basada en eventos es cuando un servicio emite un evento y otros servicios responden o toman acciones en función de esos eventos.

3.1. Eventos sincrónicos

Los eventos sincrónicos ocurren cuando un servicio emite un evento y espera una respuesta de otros servicios.

Ventajas:

Fácil de controlar y monitorear el proceso de procesamiento de eventos.

Desventajas:

Puede causar cuellos de botella si los servicios de respuesta son lentos o encuentran errores

3.2. Eventos asincrónicos

Los eventos asincrónicos ocurren cuando un servicio emite un evento y no necesita esperar una respuesta inmediata.

Ventajas:

Reduce el tiempo de espera y mejora la escalabilidad.

Ayuda a que los servicios funcionen de forma más independiente y reduce las dependencias mutuas.

Desventajas:

Requiere mecanismos adicionales para garantizar que los eventos se procesen de manera correcta y oportuna.

Dificultad para garantizar el orden y manejar eventos duplicados.

4. Conclusión

La elección del método de comunicación entre servicios en un sistema de microservicios depende de factores como los requisitos de rendimiento, la confiabilidad y la complejidad del sistema. Cada método tiene sus propias ventajas y desventajas, y comprender estos métodos le ayudará a crear un sistema de microservicios más eficiente y flexible. Considere cuidadosamente los requisitos de su sistema para elegir el método de comunicación más adecuado.