Continuando con el post anterior, hoy les traigo la arquitectura guiada por eventos.
Las arquitecturas guiadas por eventos son asincrónicas, lo cual es un detalle importante a tener en cuenta. Esto quiere decir que, al momento de ejecutar una acción, el sistema no reaccionará de manera inmediata, sino que lo hará en un tiempo que no podemos predecir.
Esto, si bien para algunos sistemas puede ser un problema, para otros es un gran beneficio, pero lo vamos a ver más adelante.
¿Qué es?
Comencemos entonces primero a saber en qué se basa esta arquitectura.
Prácticamente, como bien menciona su nombre, esta arquitectura se basa en eventos, pero ¿qué es un evento? Un evento puede describirse como cualquier acción que se genere en el sistema; por ejemplo, el alta de un usuario puede ser un evento, o la venta de un producto puede ser otro evento.
De esta manera cuando se genera un evento, este es informado a quienes corresponda para que ejecuten las acciones de las cuales son responsables. Por ejemplo, ante un evento de venta de un producto alguien debería generar una factura, otro debería enviar un email al cliente comunicando la compra, otro reservar el stock para que cliente tenga el producto, etc.
De esta manera lo que propone la arquitectura es que, mediante eventos, cualquier sistema pueda escucharlo y ejecutar la acción de la cual es responsable independientemente de otros sistemas.
Elementos
Primero debemos entender que cada evento contiene un “mensaje”. Un mensaje es la información del evento en sí, que es transmitida de un elemento a otro.
Este mensaje es transmitido mediante canales, por ejemplo, un evento de venta transmitirá un mensaje con la información de la venta a través de un canal “venta”.
Existen tres grandes elementos que componen esta arquitectura:
Generador de eventos
Es en encargado de generar el evento y enviárselo al Motor de Eventos.
Motor de eventos
Es el encargado de recibir los eventos, gestionarlos y distribuirlos a los clientes. Los eventos pueden ser encolados para atenderlos de a uno evitando sobrecargar el sistema.
Cliente
Recibe el evento enviado por el motor de eventos, ejecuta la función para la cual fue creado y realiza las operaciones correspondientes.
Ejemplo práctico
Veamos entonces un ejemplo práctico para entender un poco más de que estamos hablando.
Volviendo al ejemplo que nombramos anteriormente, supongamos que tenemos un sistema de venta de productos y todo lo que con el conlleva.
Primero tenemos nuestro generador de eventos que es el sistema encargado de la venta, el cual generara un evento con un mensaje que lleve toda la información relacionada con la venta (cliente, domicilio, producto, etc) y a través de un canal que denominamos “venta”. Este mensaje es recibido por el motor de eventos. Por ejemplo, uno muy utilizado es ActiveMQ, que es un broker de mensajería open source.
El motor de eventos emitirá el evento a los sistemas que estén escuchando en el canal “venta” como puede ser el sistema de facturación, que generará una factura por la compra, el sistema de stock que reservará el stock para la venta, etc.
Lo bueno de esta arquitectura es que yo podría agregar un nuevo sistema que forme parte de la venta y esto no afectaría a ninguno de los sistemas existentes. Por ejemplo, podría agregar un sistema de envíos a la escucha de nuevas ventas, pero todo mi sistema ya existente no se enteró de este agregado.
VENTAJAS
- Es simple de implementar ya que existen muchas herramientas que facilitan su desarrollo.
- Es fácil agregar nuevos sistemas sin tener que modificar los que ya existe.
- Al ser asincrónico permite un gran volumen de carga ya que cada sistema atenderá el evento a medida que este pueda.
- Permite una gran modularizarían
DESVENTAJAS
- Puede ser difícil saber que pasará ante un evento.
- No hay garantía que el cliente reaccione al evento
- No hay mucho soporte a recuperación en caso de falla parcial del sistema
- Al ser una arquitectura asincrónica una acción no recibe una respuesta inmediata que todo haya salido correctamente o incorrectamente.
Resumen
Esta es una idea básica de cómo funciona la arquitectura guiada por eventos. Existen distintas variantes a la hora del procesamiento de los eventos (procesamiento por flujo de evento o procesamiento complejo de eventos), pero la base es la que mencionamos en el post.
Espero que les sirva a la hora de diseñar su sistema y envíanos tus comentarios si esta información te resulto útil o quisieras dejarnos algún feedback.