Enjoy A New Student Discount All 55,000 Courses on sale for Only $12.99

Ends in 05h 23m 49s

Java17 – Probando el trabajo con RabbitMQ

Aunque supongo que muchos estáis acostumbrados a trabajar con brokers de mensajería como RabbitMQ o Kafka, supongo que para muchos, será novedad, y es por eso que he pensado escribir este articulo

Un programador Java Spring, trabaja en servidor, y normalmente se va a encargar de realizar todas las funciones necesarias para finalizar una petición de cliente, pero, habrá veces que requerirá conectar con servicios externos para alguna opción.

Para esas conexiones, puede que podamos realizarlos a un servidor RestFull, pero puede que necesitemos mucha mas disponibilidad de la que nos ofrecería ese tipo de comunicaciones, y, es entonces donde un broker de mensajería nos puede ayudar

Planteemos el problema

Nuestra aplicación es un CRUD con un cliente remoto desarrollado con lo que sea, nuestro trabajo es dar de alta un cliente en la base de datos, y además, solicitar a un servidor remoto que el nombre y el correo electrónico lo registre en otra base de datos

Este servidor remoto, debido al trafico previsto, en lugar de presentar un entorno API, se ha decidido quedar detrás de un broker de mensajería.

Porque?

Si utilizamos una API, deberemos garantizar que podemos hacer todas las transacciones, y si se produce un cuello de botella tendremos que buscar soluciones para quedar a la espera y reintentar la comunicación, a la vez que el aplicativo propio quedara detenido esperando lograr la conexión

Si vemos problemas continuos, deberemos escalar la aplicación, para lo que necesitaremos buscar soluciones para decidir a que servidor nos conectamos…

Puede que nos hayamos enfrentado ya a todos esos problemas, pero ahora os presento una solucion que resuelve la mayoría de todos esos inconvenientes.

La solucion pasa por desacoplar la aplicación encargada del CRUD y la aplicación que debe guardar los mensajes por medio de un broker de mensajería como, por ejemplo, RabbitMQ. Veamos como funcionaria:

  • Nuestra aplicación CRUD envía un mensaje con los datos y la palabra clave a un servidor RabbitMQ
  • El servidor analiza la palabra, y, en funcion de ella, decide enviar el mensaje a una o varias colas
  • El segundo servidor (sea 1 o 25) se suscribe a la cola, y así, cada vez que llega un mensaje, lo recibe y procesa

Si aumenta el trafico del segundo servidor, solo deberemos añadir mas servidores que se conecten a la misma cola, y el trabajo se lo irán repartiendo

Si nosotros, en el servidor CRUD necesitamos saber algo de ese envío, lo haremos a través de la programación por eventos; nos suscribiremos a una cola, y el servidor remoto, cuando termine su trabajo, nos enviará la información necesaria, en ese momento, la procesaremos y listo.

Aunque en la realidad, esto se puede complicar mucho, también es cierto que podemos pensar para esta introducción en un programa sencillo que nos ofrezca una idea clara de como podría funcionar todo esto

Planteando la solución

1 – El servidor Rabbit

Para nuestra prueba, podemos descargarnos e instalar un servidor RabbitMQ perfectamente configurado, y fácil de instalar en un docker,

Para instalar docker, podemos acudir a https://docs.docker.com/desktop/install/windows-install/

Ahora, ya  te puedes descargar la imagen desde https://hub.docker.com/_/rabbitmq, o puedes hacerlo directamente, en la consola de Power Shell tecleando

docker pull rabbitmq:3-management

Cuando quieras arrancar el servidor, solo tendrás que dar esta orden en el Power Shell

docker run -d -p 15672:15672 -p 5672:5672 --name servidorRabbit rabbitmq:3-management

Nuestro servidor utiliza dos puertos; el 15672 para una interficie web, y el 5672 para recibir los mensajes

2 – La configuracion de RabbitMQ

Aunque la configuración la podríamos hacer en Java, quizás sea mas sencillo y claro, realizarla de forma manual a través de la interfaz web que nos facilita RabbitMq

3 – El «Consumer»

En este caso, es la aplicación que se va a suscribir para recibir los mensajes y que deberá simular que grama la información en la Base de datos, y que lo vemos en el tercer articulo de la serie

4 – El «Producer» (Fecha publicación 18/5/2023)

Se trata del programa que va a enviar mensajes, en nuestro caso, es un mdulo escrito con Spring AMQP y que desarrollamos en el siguiente articulo

Conclusión

Veréis que el ejercicio que planteo es muy sencillo, pero espero que os permita tener una idea clara de las posibilidades que ofrece un broker de mensajería como RabbitMQ

Deja un comentario

/*Si te ha gustado el artículo
no dudes en compartirlo*/

Facebook
Twitter
LinkedIn

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies

Ver mi IP

Ver ip de mi máquina
tipo valor
Ip: 35.172.230.21
Proxy: 35.172.230.21
Remote host: ec2-35-172-230-21.compute-1.amazonaws.com
Remote port: 48382
** 35.172.230.21, 172.71.194.177