Event Driven Architecture se ha convertido en una opción muy popular en el último tiempo para desarrollar sistemas distribuidos altamente escalables. EDA, Event Driven y Arquitectura dirigida por eventos hacen alusión a lo mismo y espero poder explicarlo en palabras simples en este post. Dirigido para todos aquellos que se están iniciando en el mundo de la arquitectura de software o en sistemas distribuidos, o bien para todos los que quieran reforzar sus conocimientos y/o contribuir. ¡Aquí vamos!
¿Qué es Event Driven Architecture?
Event Driven Architecture es un estilo de arquitectura de software en el cual sus componentes se comunican entre sí a través de eventos. Se caracteriza principalmente por ser de naturaleza asíncrona y distribuida, lo cual la convierte en una arquitectura altamente escalable capaz de manejar alta concurrencia y disponibilidad.
Evento:
Un evento no es mas que una señal o notificación que indica que algo importante ha ocurrido en el sistema como por ejemplo, que un cliente ha sido creado.
Componentes de una Arquitectura Dirigida por Eventos
En la imagen anterior podemos identificar 4 componentes, los cuales me gustaría explicar con el mismo ejemplo ya mencionado (Cliente creado).
Producer
Es el componente que inicia todo. En nuestro ejemplo, el productor es el componente encargado de la creación de clientes. Imaginemos un microservicio específico para manejar esta tarea. Una vez que este microservicio crea un nuevo cliente en una base de datos, emite un evento indicando que la acción se ha completado exitosamente.
Mensaje
Es la información que enviara el productor como parte del evento. En nuestro caso, el mensaje podría contener detalles relevantes sobre el cliente recientemente creado, como su _id, su nombre o su email.
Este mensaje puede ser representado de muchas maneras, para este ejemplo lo representaremos como un objeto JSON.
{
"_id": 1,
"subject":"customer-created",
"message":{
"customerId": 969,
"name":"John Doe",
"email":"jhon.doe@email.com"
}
}
Canal (Channel)
Es el medio que permite que se transmitan los eventos/mensajes. Es una capa de persistencia la cual permite almacenar transitoriamente los mensajes. Podría ser una cola de mensajes, un bus de eventos o cualquier otro mecanismo de comunicación asíncrona que permita la entrega confiable de eventos a los receptores.
Aquí aparecen tecnologías como Apache Kafka o RabbitMQ, que actúan como intermediarios para gestionar la comunicación asíncrona entre los microservicios.
Receptor o consumidor (Consumer)
Son los microservicios o componentes que reaccionan a un evento específico emitido por un productor. En nuestro ejemplo, podrían existir microservicios encargados de acciones posteriores a la creación los clientes, como enviar un correo electrónico de confirmación o integrar estos mismos, a un sistema ERP como SAP.
En resumen, la arquitectura dirigida por eventos se fundamenta en estos cuatro componentes: el productor, el mensaje, el canal y el consumidor. Estos elementos colaboran conjuntamente para facilitar la comunicación entre los distintos servicios de un sistema distribuido. Es importante destacar que al trabajar con comunicación asincrónica, cada mensaje puede procesarse de manera independiente. Podrías incluso tener tus consumidores inactivos por mantenimiento, y una vez que los reactives podrían retomar el procesamiento de los eventos sin interrupciones en el sistema.
Escalamiento y Orquestación en Arquitectura Dirigida por Eventos
En esta arquitectura, cada consumidor debería ser capaz de poder exponer sus métricas como el tiempo de respuesta, la cantidad de mensajes por procesar, la cantidad de solicitudes procesadas, la utilización de recursos, entre otros aspectos relevantes.
Si trabajamos con un orquestador, este podría analizar dichas métricas y tomar algunas decisiones. Por ejemplo, si el consumidor encargado de enviar correos electrónicos experimenta una alta demanda producto de un gran número de clientes recientemente creados, el orquestador puede escalar automáticamente el número de instancias de este para asegurar que los correos electrónicos se envíen de manera oportuna y eficiente.
De igual manera, si el servicio escalado experimenta una baja en la demanda, el orquestador puede manejar el escalamiento horizontal hacia abajo y liberar así los recursos que se hayan tomdo de la infraestructura.
Hoy en día existen múltiples tecnologías que nos permiten orquestar microservicios y contenedores como Kubernetes, Nomad, Docker Swarm que ofrecen una infraestructura robusta para desplegar y escalar aplicaciones basadas en microservicios.
Conclusión
Si estás pensando en implementar un sistema distribuido, en tiempo real y altamente escalable, definitivamente deberías considerar implementar una arquitectura dirigida por eventos para aprovechar todos las ventajas que esta te ofrece.
Muchas gracias si llegaste hasta aquí. ¡Gracias por leer!
Top comments (0)