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
Relacionado
Descubre más desde Recursos para formacion
Suscríbete y recibe las últimas entradas en tu correo electrónico.