Arquitectura basada en eventos

La arquitectura orientada a eventos ( EDA ) es un paradigma de arquitectura de software que se centra en la producción y detección de eventos . Las arquitecturas orientadas a eventos son de naturaleza evolutiva y ofrecen un alto grado de tolerancia a fallos , rendimiento y escalabilidad . Sin embargo, son complejas y, por naturaleza, difíciles de probar . Las EDA son adecuadas para cargas de trabajo complejas y dinámicas. ^{[ 1 ]}

Un evento puede definirse como "un cambio significativo de estado ". ^{[ 2 ]} Por ejemplo, cuando un consumidor compra un automóvil, el estado del automóvil cambia de "en venta" a "vendido". La arquitectura del sistema de un concesionario de automóviles puede tratar este cambio de estado como un evento cuya ocurrencia puede ser comunicada a otras aplicaciones dentro de la arquitectura. Desde una perspectiva formal, lo que se produce, publica, propaga, detecta o consume es un mensaje (típicamente asíncrono) llamado notificación de evento, y no el evento en sí, que es el cambio de estado que desencadenó la emisión del mensaje. Los eventos no viajan, simplemente ocurren. Sin embargo, el término evento se usa a menudo metonímicamente para denotar el mensaje de notificación en sí, lo que puede generar cierta confusión. Esto se debe a que las arquitecturas orientadas a eventos a menudo se diseñan sobre arquitecturas orientadas a mensajes , donde dicho patrón de comunicación requiere que una de las entradas sea solo texto, el mensaje, para diferenciar cómo debe manejarse cada comunicación.

Este patrón arquitectónico se puede aplicar al diseño e implementación de aplicaciones y sistemas que transmiten eventos entre componentes y servicios de software débilmente acoplados . Un sistema orientado a eventos generalmente consta de emisores (o agentes) de eventos, consumidores (o sumideros) de eventos y canales de eventos. Los emisores tienen la responsabilidad de detectar, recopilar y transferir eventos. Un emisor de eventos desconoce quiénes son los consumidores del evento, ni siquiera sabe si existe alguno, y en caso de existir, desconoce cómo se utiliza o procesa el evento. Los sumideros tienen la responsabilidad de aplicar una reacción tan pronto como se presenta un evento. La reacción puede o no ser proporcionada completamente por el propio sumidero. Por ejemplo, el sumidero podría tener la responsabilidad de filtrar, transformar y reenviar el evento a otro componente, o podría proporcionar una reacción autónoma a dicho evento. Los canales de eventos son conductos a través de los cuales los eventos se transmiten desde los emisores de eventos a los consumidores de eventos. El conocimiento de la distribución correcta de los eventos reside exclusivamente dentro del canal de eventos. La implementación física de los canales de eventos puede basarse en componentes tradicionales como el middleware orientado a mensajes o la comunicación punto a punto, que podrían requerir un marco ejecutivo transaccional más apropiado .

Construir sistemas en torno a una arquitectura basada en eventos simplifica la escalabilidad horizontal en modelos de computación distribuida y los hace más resistentes a fallos. Esto se debe a que el estado de la aplicación se puede copiar en múltiples instantáneas paralelas para lograr alta disponibilidad. ^{[ 3 ]} Se pueden iniciar nuevos eventos en cualquier lugar, pero, lo que es más importante, se propagan por la red de almacenes de datos, actualizando cada uno a medida que llegan. Agregar nodos adicionales también se vuelve trivial: simplemente se puede tomar una copia del estado de la aplicación, alimentarla con un flujo de eventos y ejecutarla. ^{[ 4 ]}

La arquitectura basada en eventos puede complementar la arquitectura orientada a servicios (SOA) porque los servicios pueden activarse mediante disparadores que se activan en eventos entrantes. ^{[ 5 ] [ 6 ]} Este paradigma es particularmente útil cuando el sumidero no proporciona ningún ejecutivo autocontenido .

SOA 2.0 lleva las implicaciones de las arquitecturas SOA y EDA a un nivel más rico y robusto, aprovechando relaciones causales previamente desconocidas para formar un nuevo patrón de eventos. Este nuevo patrón de inteligencia empresarial activa un procesamiento autónomo, ya sea humano o automatizado, que aporta un valor exponencial a la empresa al incorporar información de valor añadido al patrón reconocido, algo que antes era imposible.

La arquitectura basada en eventos tiene dos topologías principales. En la topología de "broker", los componentes transmiten eventos a todo el sistema sin necesidad de un orquestador. Esta topología ofrece mayor rendimiento y escalabilidad. En la topología de "mediator", existe un orquestador central que controla el flujo de trabajo de los eventos. Esta topología proporciona un mejor control y capacidades de gestión de errores. También se puede utilizar un modelo híbrido que combine ambas topologías. ^{[ 1 ]}

En EDA existen diferentes tipos de eventos , y las opiniones sobre su clasificación pueden variar. Según Yan Cui, existen dos categorías clave de eventos: ^{[ 7 ]}

Un evento puede constar de dos partes: la cabecera y el cuerpo, también conocido como carga útil. La cabecera puede incluir información como el nombre del evento, la marca de tiempo y el tipo de evento. La carga útil proporciona los detalles del cambio de estado detectado. El cuerpo del evento no debe confundirse con el patrón o la lógica que se aplica en respuesta a la ocurrencia del evento.

Hay dos métodos principales para estructurar las cargas útiles de eventos en arquitecturas orientadas a eventos: ^{[ 1 ]}

1. Todos los atributos necesarios pueden incluirse en la carga útil: Este método mejora la velocidad y la escalabilidad , pero puede generar problemas de consistencia de datos debido a la presencia de múltiples sistemas de registro . Además, puede introducir problemas de acoplamiento de sellos y ancho de banda a gran escala. ^{[ 1 ]}
2. Este método implica incluir solo claves o identificadores, lo que permite a los consumidores obtener los datos necesarios de fuentes de datos externas, como bases de datos . Si bien este enfoque es menos escalable y más lento debido a la necesidad de realizar consultas a la base de datos, minimiza el uso de ancho de banda y reduce los problemas de acoplamiento. ^{[ 1 ]}

Estos métodos representan dos extremos de un espectro, en lugar de opciones binarias. Los arquitectos deben dimensionar cuidadosamente las cargas útiles de los eventos para satisfacer las necesidades específicas de los consumidores de eventos. ^{[ 1 ]}

• El "antipatrón de tiempo de espera", acuñado por Mark Richards, describe los desafíos de establecer valores de tiempo de espera en sistemas distribuidos. Los tiempos de espera cortos pueden provocar que las solicitudes legítimas fallen prematuramente, lo que conlleva soluciones alternativas complejas, mientras que los tiempos de espera largos pueden resultar en respuestas de error lentas y una mala experiencia de usuario. El patrón de disyuntor puede abordar estos problemas mediante la monitorización del estado del servicio a través de mecanismos como latidos, "transacciones sintéticas" o monitorización del uso en tiempo real. Este enfoque permite una detección de fallos más rápida y mejora la experiencia general del usuario en arquitecturas distribuidas. ^{[ 8 ]}

En las arquitecturas basadas en eventos, la evolución de los eventos plantea desafíos, como la gestión de esquemas de eventos inconsistentes entre servicios y la garantía de compatibilidad durante las actualizaciones graduales del sistema. Las estrategias de evolución de eventos en arquitecturas basadas en eventos (EDA) pueden asegurar que los sistemas puedan manejar cambios en los eventos sin interrupciones. Estas estrategias pueden incluir eventos de versionado, como el versionado semántico o la evolución del esquema, para mantener la compatibilidad hacia atrás y hacia adelante . Los adaptadores pueden traducir eventos entre formatos antiguos y nuevos, asegurando un procesamiento consistente en todos los componentes. Estas técnicas pueden permitir que los sistemas evolucionen manteniendo la compatibilidad y la fiabilidad en entornos distribuidos complejos. ^{[ 9 ]}

Una arquitectura orientada a eventos puede construirse sobre cuatro capas lógicas, comenzando con la detección de un evento (es decir, un estado o hecho temporal significativo), procediendo a la creación de su representación técnica en forma de una estructura de eventos y terminando con un conjunto no vacío de reacciones a ese evento. ^{[ 10 ]}

There are three general styles of event processing: simple, stream, and complex. The three styles are often used together in a mature event-driven architecture.^[10]

Una arquitectura orientada a eventos es extremadamente poco acoplada y está bien distribuida. La gran distribución de esta arquitectura se debe a que un evento puede ser casi cualquier cosa y ocurrir en casi cualquier lugar. La arquitectura es extremadamente poco acoplada porque el evento en sí no conoce las consecuencias de su causa. Por ejemplo, si tenemos un sistema de alarma que registra información cuando se abre la puerta principal, la puerta en sí no sabe que el sistema de alarma agregará información cuando se abra, solo que la puerta se ha abierto. ^{[ 10 ]}

Las transacciones síncronas en EDA se pueden lograr mediante el uso del paradigma de solicitud-respuesta y se pueden implementar de dos maneras: ^{[ 1 ]}

• Se crean dos colas separadas : una para las solicitudes y otra para las respuestas. El productor del evento debe esperar hasta recibir la respuesta.
• Crear una cola efímera dedicada para cada solicitud.

La arquitectura basada en eventos es susceptible a las falacias de la computación distribuida , una serie de conceptos erróneos que pueden conducir a problemas significativos en el desarrollo y despliegue de software. ^{[ 1 ]}

Encontrar el equilibrio adecuado en la cantidad de eventos puede ser bastante difícil. Generar demasiados eventos detallados puede sobrecargar el sistema, dificultando el análisis efectivo del flujo general de eventos. Este desafío se vuelve aún mayor cuando se requieren reversiones. Por el contrario, si los eventos se consolidan en exceso, esto puede generar procesamiento y respuestas innecesarias por parte de los consumidores de eventos. Para lograr un equilibrio óptimo, Mark Richards recomienda considerar el impacto de cada evento y si los consumidores necesitan revisar las cargas útiles de los eventos para determinar sus acciones. Por ejemplo, en un escenario de verificación de cumplimiento, puede ser suficiente publicar solo dos tipos de eventos: conformes y no conformes. Este método garantiza que cada evento sea procesado únicamente por los consumidores relevantes, reduciendo la carga de trabajo innecesaria. ^{[ 1 ]}

Uno de los desafíos de usar una arquitectura basada en eventos es el manejo de errores. Una forma de abordar este problema es usar un procesador de manejo de errores independiente. Así, cuando el consumidor de eventos experimenta un error, envía de forma inmediata y asíncrona el evento erróneo al procesador de manejo de errores y continúa. El procesador de manejo de errores intenta corregir el error y envía el evento de vuelta al canal original. Pero si el procesador de manejo de errores falla, puede enviar el evento erróneo a un administrador para una inspección más detallada. Tenga en cuenta que si usa un procesador de manejo de errores, los eventos erróneos se procesarán fuera de secuencia cuando se vuelvan a enviar. ^{[ 1 ]}

Otro desafío de usar la arquitectura basada en eventos es la pérdida de datos . Si alguno de los componentes falla antes de procesar correctamente el evento y entregarlo al siguiente componente, el evento se pierde y nunca llega a su destino final. Para minimizar la posibilidad de pérdida de datos, se pueden persistir los eventos en tránsito y eliminarlos/desencolarlos solo cuando el siguiente componente haya confirmado su recepción. Estas características se conocen generalmente como "modo de confirmación del cliente" y "compatibilidad con el último participante". ^{[ 1 ]}

• Programación basada en eventos
• Servicio de mensajería basado en procesos
• Arquitectura orientada a servicios
• SOA basada en eventos
• Arquitectura basada en el espacio
• Procesamiento de eventos complejos
• Procesamiento de flujos de eventos
• Sociedad Técnica de Procesamiento de Eventos
• Arquitectura de eventos por etapas (SEDA)
• Patrón del reactor
• Operación periférica autónoma

• Artículo que define las diferencias entre EDA y SOA: Cómo EDA amplía SOA y por qué es importante, por Jack van Hoof.
• Ejemplo práctico de cómo fluyen los eventos empresariales en una arquitectura SOA: SOA, EDA y CEP: una combinación ganadora según Udi Dahan.
• Artículo que describe el concepto de datos de eventos: Analítica para hackers: cómo abordar los datos de eventos, por Michelle Wetzler. (Archivo web)

• Aplicaciones basadas en eventos: costos, beneficios y enfoques de diseño. Archivado el 23/10/2013 en Wayback Machine.
• Edición del 5.º aniversario: Panorama general de la arquitectura basada en eventos, Brenda M. Michelson
• Procesamiento de eventos complejos y arquitectura orientada a servicios