Diferentes formas de establecer comunicación entre Spring Microservices

Si está trabajando con un proyecto Spring Boot que involucra múltiples microservicios, es posible que haya sentido la necesidad de comunicarse desde el microservicio m1 al microservicio m2. Según los casos de uso empresarial, esta comunicación puede ser de tipo síncrono o asíncrono. Antes de cavar sumergirse más. Entendamos primero el caso de uso. Hay dos microservicios:

1. Servicio de restaurante: responsable de mantener los artículos que se sirven en un restaurante, procesar pedidos, etc.
2. Usuario-Servicio: Responsable de mantener los detalles del usuario.

Ahora supongamos que un usuario visita la página de un restaurante, selecciona alguna cocina de su elección y hace clic en el botón «Realizar pedido». Cuando esta solicitud llega al servicio de restaurante, el servicio querrá validar los detalles del usuario antes de procesar este pedido. Pero nuestros detalles de usuario se encuentran bajo el servicio de usuario. De ahí surge la necesidad de comunicar del servicio-restaurante al servicio-usuario. La comunicación síncrona de m2 desde m1 es como llamar a una API de m2 directamente desde m1.

Vía sincrónica

Cuando hablamos de comunicación sincrónica , podría haber dos formas:

1. Plantilla de descanso
2. Fingir

Plantilla de descanso

REST Template es la forma más fácil de establecer una comunicación síncrona de m1 a m2. RestTemplate es una clase disponible en spring.framework.web.client que actúa como un cliente síncrono para realizar requests HTTP. En el siguiente ejemplo, hemos utilizado   el método getForEntity que acepta la URL completa del servicio de usuario que queremos invocar, seguido del nombre de la clase Data-Object que se supone que devolverá esa URL y un mapa. Si el ID de usuario proporcionado no es válido, la llamada a la API arrojaría una excepción personalizada que estamos entregando en el lado del servicio de restaurante.

HashMap<String, Long> params = new HashMap<>();
params.put("userId", orderDetails.getUserId());
try {
    ResponseEntity<User> response
        = new RestTemplate().getForEntity(
            "http://localhost:8080/users/{userId}",
            User.class, params);
}
catch (Exception ex) {
    throw new InvalidUserIdException(
        "User Id " + orderDetails.getUserId()
        + " Not Found");
}

Fingir

Fingir requiere una configuración adicional en ambos servicios si desea utilizar este método. Este enfoque utiliza interfaces estándar de Java. Las ventajas adicionales de usar fingir sobre la plantilla de descanso es que no puede codificar su URL aquí. El ID de cliente de Eureka también se puede utilizar con fines de detección de servidores para establecer la comunicación.

Vía asíncrona

Una posible forma asincrónica de establecer comunicación es mediante un intermediario de mensajes. Entendamos primero el caso de uso.

Teniendo en cuenta los microservicios discutidos anteriormente, supongamos que un usuario ha realizado su pedido. Ahora el pedido pasaría por varias etapas, como Aceptado, Preparación iniciada, Listo para recoger, Entregado . Suponiendo que el servicio de restaurante actualice todas las etapas del pedido, queremos notificar al servicio de usuario cada vez que se actualice el estado del pedido. Ahora, esto se puede lograr de cualquier manera, pero la forma asíncrona sería más conveniente aquí.

• Message-Broker: Se comporta como un servicio intermediario entre m1 y m2. Cuando m1 tiene que comunicarse con m2, m1 enviaría un mensaje al intermediario en lugar de enviarlo directamente a m2. Según el tipo de intermediario (ActiveMQ y Kafka son dos intermediarios de mensajes populares pero tienen diferentes enfoques de comunicación), el mensaje se transmitirá al oyente de m2 y se tomarán las medidas correspondientes. Aquí m1 sería conocido como productor mientras que m2 sería conocido como consumidor.