¿Qué es la arquitectura dirigida por eventos? Modelos, ejemplos y usos.

Las empresas dependen de diversas tecnologías y herramientas para operar su negocio de manera efectiva.

Aún así, estas pueden volverse rápidamente obsoletas, lo que lleva a una degradación del rendimiento, aumento de costos y exposición a riesgos, y amenazas de seguridad. No es difícil ver cómo las arquitecturas monolíticas y anticuadas a menudo son un cuello de botella para la modernización de su negocio.

Una forma de mejorar la agilidad y escalabilidad de su infraestructura de TI es emplear una arquitectura orientada a eventos. En una arquitectura orientada a eventos, los sistemas se construyen en torno a eventos, que son mensajes que indican que algo ha sucedido. Esto hace posible construir sistemas que reaccionen rápidamente a los cambios en su entorno, haciéndolos más ágiles y adaptables.

La mayoría de los sistemas orientados a eventos utilizan software de colas de mensajes para comunicarse entre sistemas dispares y permitir la comunicación en tiempo real en una sola capa.

El patrón de proceso de arquitectura orientada a eventos reemplaza el diseño convencional de "solicitud/respuesta" en el que los servicios tenían que esperar una respuesta antes de proceder a la siguiente actividad. También ofrece información en tiempo real sobre el comportamiento del usuario, los procesos empresariales y las operaciones.

Los eventos gobiernan el flujo de la arquitectura orientada a eventos, que está destinada a reaccionar a eventos o realizar operaciones en respuesta a un evento.

¿Qué significa ser orientado a eventos?

Los eventos son instancias de acciones. Ocurren cuando algo sucede dentro o fuera de su negocio. Estas actividades pueden incluir una compra de un consumidor, una actualización de inventario en un almacén, un intento de violación de datos o un cambio de estado de una aplicación.

Dado que muchos eventos son sensibles al tiempo o críticos para las operaciones comerciales, las empresas quieren diseñar sus infraestructuras en torno a la recopilación y respuesta a tales eventos. Se dice que el negocio es orientado a eventos cuando los eventos hacen que un negocio responda. En la era moderna, los eventos son procesados por sistemas de TI que recopilan, analizan y reaccionan a eventos basados en lógica preestablecida.

Las arquitecturas orientadas a eventos también se llaman arquitecturas asincrónicas colaborativas porque dependen de la mensajería asincrónica entre las diferentes partes de un sistema con respuestas en tiempo real. Ahora, sistemas como bancos y telemetría están moviéndose al modelo centrado en eventos, donde comienzan a recopilar datos en tránsito y reaccionar a ellos basados en eventos.

Veamos un ejemplo bancario de arquitectura orientada a eventos. El pago ocurre en una ubicación específica. En ese caso, la arquitectura orientada a eventos responde a esa solicitud más rápida y precisamente que el enfoque tradicional de solicitud/respuesta, que requiere que espere una respuesta antes de continuar con su transacción.

Esto agrega una funcionalidad rica, como alertas de fraude y capas de seguridad que ayudan a proteger a los clientes de los ciberladrones.

Importancia de los sistemas orientados a eventos

El alto rendimiento, la escalabilidad y la agilidad son características clave de los líderes digitales de hoy, muchos de los cuales han adoptado microservicios y arquitectura orientada a eventos.

Las infraestructuras de TI monolíticas dependen de la comunicación sincrónica en la que dos programas interactúan directamente, más comúnmente a través de interfaces de programación de aplicaciones (APIs). Por otro lado, la comunicación asincrónica es orientada a eventos, permitiendo que varias aplicaciones interactúen simultáneamente y rápidamente en tiempo real. EDA es a menudo el método más efectivo para habilitar la interacción de aplicaciones orientadas a eventos asincrónicos.

Las empresas que utilizan arquitectura orientada a eventos pueden disfrutar de los beneficios de una comunicación en tiempo real escalable y robusta utilizando colas de mensajes. Muchos proyectos estratégicos pueden beneficiarse de esto, incluyendo el internet de las cosas (IoT), el comercio electrónico, la integración de datos entre sistemas, y la detección de fraudes financieros y en el borde.

Arquitectura orientada a eventos vs. arquitectura tradicional

Las arquitecturas orientadas a eventos y tradicionales difieren fundamentalmente en los enfoques de comunicación y diseño del sistema. EDA se basa en la comunicación asincrónica, donde los eventos desencadenan interacciones entre componentes débilmente acoplados, permitiendo una capacidad de respuesta en tiempo real y alta escalabilidad. Esto lo hace ideal para sistemas complejos y distribuidos como IoT, análisis en tiempo real y detección de fraudes financieros.

En contraste, la arquitectura tradicional sigue un modelo de solicitud-respuesta que involucra interacción directa entre componentes estrechamente acoplados. Aunque es más fácil de implementar para flujos de trabajo sencillos como sistemas transaccionales, las arquitecturas sincrónicas a menudo luchan con la latencia y la escalabilidad en entornos distribuidos.

Elegir entre estos enfoques depende de los requisitos del sistema. EDA es preferida para sistemas dinámicos, escalables y resilientes, mientras que las arquitecturas tradicionales son adecuadas para aplicaciones con patrones de comunicación más simples y predecibles.

¿Cómo funciona la arquitectura orientada a eventos?

Un patrón de arquitectura orientada a eventos ayuda a desarrollar y desplegar aplicaciones y sistemas que transfieren eventos entre componentes y servicios del sistema débilmente acoplados. Una infraestructura orientada a eventos tiene tres componentes principales:

1. Productores de eventos, también conocidos como emisores de eventos y agentes
2. Consumidores de eventos o sumideros
3. Corredor o canal

Un productor de eventos monitorea o detecta un evento y lo convierte en un mensaje. Después de detectar un evento, el productor envía el mensaje al consumidor a través de canales de eventos. El productor no conoce a los consumidores del evento y nunca sabrá el resultado del evento.

Los consumidores de eventos son responsables de desencadenar una respuesta cuando ocurre un evento. Un consumidor de eventos puede o no proporcionar una respuesta completa. Por ejemplo, el consumidor podría ser responsable de filtrar, procesar y retransmitir el evento al siguiente componente (generalmente plataformas de transmisión de eventos) u ofrecer una respuesta autónoma a un evento.

La plataforma de procesamiento de eventos determina la respuesta adecuada a un evento y transmite la actividad aguas abajo a los consumidores relevantes, donde el resultado del evento es visible.

La arquitectura orientada a eventos promueve el desacoplamiento de aplicaciones a través de un corredor de eventos, similar a un corredor de mensajes, que enruta eventos de productores a consumidores. Estos corredores pueden implementarse utilizando middleware orientado a mensajes, asegurando que las aplicaciones y dispositivos no necesiten conocer la fuente o el destino de los datos. Aunque el desacoplamiento plantea desafíos, mejora significativamente la flexibilidad y escalabilidad.

En EDA, los eventos se envían sin esperar una respuesta aparte de un reconocimiento del corredor de eventos. Este desacoplamiento asegura que los transmisores y receptores operen de manera independiente.

Las conexiones directas entre productores y consumidores pueden evitar la necesidad de un corredor, como un productor interactuando directamente con una base de datos para almacenar eventos para análisis. Sin embargo, en la mayoría de las configuraciones, múltiples emisores de eventos generan varios eventos, con uno o más sumideros procesándolos.

Modelos de arquitectura orientada a eventos

Un patrón de EDA especifica cómo interactúan entre sí los productores, consumidores y corredores de eventos. Existen dos patrones principales de arquitectura orientada a eventos: publicador/suscriptor y transmisión de eventos.

Arquitectura de publicador/suscriptor

Esta arquitectura basada en colas de mensajes depende de suscripciones a flujos de eventos para la comunicación. El enrutador de eventos en una arquitectura de publicador/suscriptor (el modelo pub/sub) registra las suscripciones de los clientes a los canales de eventos. Este modelo envía notificaciones a los suscriptores que deben ser alertados cuando ocurre un evento o se publica.

Dado que los eventos no pueden ser reproducidos, un consumidor que se suscribe después de que un evento ha ocurrido no puede acceder a él más tarde. A partir de ese momento, el consumidor recibe eventos nuevos. ActiveMQ y RabbitMQ son dos corredores bien conocidos para el modelo pub/sub.

Arquitectura de transmisión de eventos

La transmisión de eventos trasciende el modelo basado en suscripciones. Esta técnica almacena eventos en un registro al que todos los consumidores pueden acceder para descubrir eventos importantes. Los consumidores pueden leer desde cualquier área del flujo y reproducir eventos anteriores.

Apache Kafka es una solución de procesamiento de flujos bien conocida. Muchas empresas eligen Kafka porque es una solución establecida y robusta. Como una plataforma de procesamiento de flujos de nivel industrial, Kafka tiene una amplia base de usuarios, una comunidad de apoyo y un conjunto de herramientas avanzadas.

Otras plataformas proporcionan una mezcla de procesamiento de flujos y pub/sub o su solución distinta. Pulsar, un producto reciente de Apache, es una plataforma de mensajería pub/sub de código abierto y rica en funciones que facilita tanto flujos como colas de eventos, todo con una velocidad excepcionalmente alta.

NATS es un sistema de mensajería pub/sub que utiliza "colocación sintética". NATS, o sistema de transporte autónomo neural, está diseñado para entregar comunicaciones cortas y frecuentes. Ofrece un excelente rendimiento y latencia reducida. Sin embargo, NATS considera aceptable cierta fuga de datos, priorizando el rendimiento sobre las promesas de entrega.

Ejemplo de arquitectura orientada a eventos

A continuación se muestra un ejemplo de un enfoque orientado a eventos para un sitio de comercio electrónico. Esta arquitectura permite que el sitio web responda a actualizaciones de varias fuentes durante una alta demanda sin interrumpir el sistema o sobreaprovisionar recursos.

Considere cómo un minorista en línea puede usar una arquitectura orientada a eventos como ejemplo. Los clientes están a punto de finalizar su compra en línea, e ingresar su información de pago en una plataforma de comercio electrónico es una acción frecuente y crucial. La interfaz de usuario (UI) genera el evento "Pago Enviado" con la información de la tarjeta de crédito, y el enrutador de eventos sabe dirigir la notificación del evento al servicio de pago basado en los metadatos del evento.

Después de recibir la notificación, el servicio de pago procesa el evento y crea un nuevo evento "Pago Procesado" que indica el éxito o fracaso de la operación.

El enrutador de eventos devuelve información a la UI, mostrando el estado del consumidor y pidiéndole que tome acciones predefinidas. Por ejemplo, si un pago falla, la UI puede reabrir el formulario para corregir los detalles. Pero si el pago es exitoso, la UI proporciona la información final del pedido y la fecha estimada de entrega.

Ni el sitio frontal ni los servicios de fondo son conscientes de la existencia de sus equivalentes. Se suscriben a los eventos "Pago Enviado" y "Pago Procesado", que el enrutador de eventos mantiene.

Casos de uso de la arquitectura orientada a eventos

Las empresas se apoyan en EDA para crear sistemas que satisfagan una variedad de casos de uso. Los más populares pueden incluir:

• Monitoreo en tiempo real: Los sistemas pueden crear eventos a medida que sus estados cambian, permitiendo a las empresas buscar irregularidades y comportamientos sospechosos.
• Replicación de datos: Un solo evento puede ser utilizado por numerosos servicios que requieren replicación de datos en sus bases de datos.
• Redundancia: Si un servicio no está disponible, los eventos pueden ser almacenados en el enrutador hasta que el servicio esté listo para consumir el evento.
• Procesamiento en paralelo: Un solo evento puede iniciar múltiples procesos y ejecutarse de manera asincrónica.
• Interoperabilidad: Los eventos pueden ser almacenados y distribuidos independientemente del lenguaje en el que se construyen las aplicaciones.
• Microservicios: EDA se integra frecuentemente con microservicios para transferir datos entre procesos desacoplados a gran escala de manera efectiva.

Beneficios de una arquitectura orientada a eventos

EDA simplifica el desarrollo de una empresa de un sistema flexible que responde a los cambios y toma decisiones en tiempo real. Veamos algunas formas en que una arquitectura orientada a eventos se hace útil.

• Desacoplamiento: Los servicios ya no tienen que ser conscientes de la existencia de otros sistemas para interactuar. Deben ser conscientes de los eventos, pero el corredor distribuye los eventos apropiados a los sistemas correctos. Esto produce microservicios muy desacoplados que son fáciles de adaptar, probar y desplegar.
• Inmutabilidad: Dado que los eventos no pueden ser modificados después de haber sido generados, nadie tiene que preocuparse de que alguien más cambie su contenido más tarde.
• Reducción de gastos: Las arquitecturas orientadas a eventos son basadas en "push", por lo que todo ocurre tan pronto como el evento aparece en el corredor. Los usuarios no tienen que pagar por sondeos continuos para verificar un evento. Esto lleva a un menor uso del ancho de banda de la red, menor consumo de CPU y menos SSL/TLS handshakes.
• Tolerancia a fallos: Si un consumidor deja de operar abruptamente o falla al procesar un evento, el corredor de eventos no lo considera procesado exitosamente. El evento no se pierde; más bien, es re-consumido por otra instancia de consumidor o procesado nuevamente cuando el consumidor está disponible.
• Tiempo real: Un diseño orientado a eventos proporciona una visibilidad en tiempo real sin igual de todo lo que ocurre en el sistema. La capacidad de consumir este conocimiento, derivar conocimientos a medida que ocurren y automatizar la toma de decisiones es tan simple como agregar consumidores a eventos actuales. Agregar características en tiempo real a arquitecturas alternativas es factible pero implica un esfuerzo adicional, nuevas herramientas y cambios en los componentes existentes.
• Escalabilidad: Un solo evento puede ser aprovechado para activar numerosas acciones para varios consumidores, permitiendo la ejecución de trabajos en paralelo y un mejor rendimiento. No tiene que alterar la lógica para cada servicio o sistema, por lo que puede ajustar fácilmente la pila tecnológica para cumplir con nuevos requisitos o necesidades.
• Recuperación: Cuando emplea un corredor de eventos que proporciona flujos de eventos continuos y resilientes, puede "reproducir" eventos pasados para restaurar trabajos perdidos o reconstruir la configuración del sistema.

Desafíos de una arquitectura orientada a eventos

Ahora que hemos cubierto todas las ventajas de la infraestructura orientada a eventos, examinemos sus limitaciones. Algunos de estos compromisos existen en enfoques de diseño alternativos, como desarrollar microservicios REST, pero se acentúan en un diseño orientado a eventos.

• Complejidad: El desacoplamiento elimina la necesidad de rastreo de dependencias y otros impedimentos para un modelo de microservicios. La carga de servicios independientes es que se vuelve más difícil comprender el progreso de los eventos a través de muchas aplicaciones, en comparación con la dependencia directa, donde las relaciones son más claras.
• Flujos sincrónicos: Debido a que los eventos son asincrónicos, este paradigma lucha por soportar actividades sincrónicas cuando el resultado de las acciones debe ser enviado dentro del mismo alcance de solicitud-respuesta.
• Diseño de eventos: Diseñar eventos es difícil. Dado que cada consumidor puede suscribirse al evento, tiene que ser reutilizable, lo que sacrifica la personalización. Al mismo tiempo, el diseño no puede ser tan general que el propósito se vuelva oscuro.
• Evolución de eventos: A medida que los sistemas se desarrollan con el tiempo, los eventos deben mantenerse al día para acomodar las características cambiantes del sistema. Actualizar eventos sin afectar a otros microservicios puede ser complicado, particularmente en un escenario distribuido donde los equipos no están en contacto con las personas que procesan los eventos que crean.

Escale su infraestructura para el éxito

Las arquitecturas orientadas a eventos apilan servicios en una sola capa de transacción. Este enfoque permite a las empresas detectar problemas, responder rápidamente a las resoluciones y apoyar procesos empresariales dinámicos más rápido.

Datos, datos por todas partes. Obtenga software de procesamiento de flujos de eventos para ayudarle a entender y procesar datos empresariales en tránsito.

El artículo fue publicado originalmente en 2022. Ha sido actualizado con nueva información.