¿Qué es la arquitectura basada en eventos (EDA)?
La arquitectura basada en eventos (EDA) es un patrón de arquitectura moderna diseñado a partir de servicios pequeños y desacoplados que publican, consumen o enrutan eventos.
Un evento representa un cambio de estado o una actualización. Por ejemplo, un artículo que se coloca en un carro de la compra, un archivo que se carga en un sistema de almacenamiento o un pedido preparado para el envío. Los eventos pueden portar el estado (como el nombre del artículo, el precio o la cantidad en un pedido) o, simplemente, contener identificadores (por ejemplo, “se ha enviado el pedido número 8942”) necesarios para buscar la información relacionada.
Al contrario que los modelos controlados por solicitudes tradicionales, la EDA favorece el acoplamiento flexible entre los servicios del productor y el consumidor. Esto hace que sea más fácil escalar, actualizar y desplegar de manera independiente componentes individuales de un sistema.
¿Por qué es importante una arquitectura desacoplada?
Muchas organizaciones encuentran que las aplicaciones, bases de datos y tecnologías monolíticas tienen un impacto negativo en la innovación y la mejora de la experiencia del usuario. Las aplicaciones y bases de datos heredadas reducen sus opciones para adoptar marcos tecnológicos modernos y limitan su competitividad e innovación. Sin embargo, cuando moderniza las aplicaciones y sus almacenes de datos, se vuelven más fáciles de escalar y más rápidos de desarrollar.
Una estrategia de datos desacoplados mejora la tolerancia a fallas y la resiliencia, lo que ayuda a acelerar el tiempo de comercialización (TTM) para las nuevas características de su aplicación.
Para obtener más información sobre las ventajas de modernizar aplicaciones monolíticas, consulte Enabling data persistence in microservices (Habilitación de la persistencia de datos en microservicios) en Recomendaciones de AWS.
¿Cuáles son los beneficios de la arquitectura basada en eventos (EDA)?
La arquitectura basada en eventos (EDA) promueve un acoplamiento flexible entre los componentes de un sistema, lo que conduce a una mayor agilidad. Los microservicios pueden escalar de forma independiente, fallar sin afectar a otros servicios y reducir la complejidad de los flujos de trabajo. Los eventos se pueden enrutar, almacenar en búfer y registrar de manera flexible con fines de auditoría. Los flujos de eventos basados en push pueden operar en tiempo real, lo que reduce los costos asociados con la creación y el funcionamiento del código que sondea continuamente los sistemas en busca de cambios.
Escalado y errores por separado
Al desacoplar los servicios, los componentes de una arquitectura basada en eventos pueden escalar y fallar de forma independiente, lo que aumenta la resiliencia de una aplicación. Esto se vuelve cada vez más importante a medida que crece el número de integraciones entre servicios. Si un servicio falla, el resto puede seguir funcionando.
La arquitectura basada en eventos también puede facilitar el diseño de sistemas casi en tiempo real, lo que ayuda a las organizaciones a alejarse del procesamiento basado en lotes. Los eventos se generan cuando cambia el estado de una aplicación. A medida que los eventos escalan verticalmente, también puede hacerlo la capa que procesa los eventos.
Los eventos generalmente se publican en servicios de mensajería que se comportan como un búfer elástico entre microservicios y ayudan a manejar la escala. Los eventos también pueden enviarse a un servicio de enrutador que puede filtrar y enrutar mensajes según el contenido del evento. Como resultado, las aplicaciones basadas en eventos pueden ser más escalables y ofrecer una mayor redundancia que las aplicaciones monolíticas.
Desarrollar con agilidad
Con la arquitectura basada en eventos y los enrutadores de eventos, los desarrolladores ya no necesitan escribir código personalizado para sondear, filtrar y enrutar eventos. Un enrutador de eventos filtra y envía automáticamente eventos a los consumidores. El enrutador también elimina la necesidad de una gran coordinación entre los servicios del productor y el consumidor, lo que aumenta la agilidad del desarrollador.
La arquitectura impulsada por eventos se basa en inserción, lo que significa que todo sucede bajo demanda a medida que los eventos se envían al enrutador y a los sistemas posteriores, sin necesidad de informar a los servicios dependientes. Debido a esto, la infraestructura y los recursos pueden escalar verticalmente y hacia abajo con el volumen de eventos, lo que reduce los costos para procesar las cargas de trabajo y operar las aplicaciones desplegadas.
Creación de sistemas extensibles
La arquitectura basada en eventos también es altamente extensible. Otros equipos pueden ampliar características y agregar funcionalidad sin repercutir en los microservicios existentes. Al publicar eventos, una aplicación puede integrarse con los sistemas existentes y las aplicaciones futuras pueden integrarse fácilmente como consumidores de eventos, sin cambiar la solución existente.
Los productores de eventos no tienen conocimiento de los consumidores de eventos, por lo que extender el sistema tiene menos fricción y las nuevas funciones o integraciones no agregan dependencias que ralentizan el desarrollo futuro.
Reducción de la complejidad
Los microservicios permiten a los desarrolladores y arquitectos descomponer flujos de trabajo complejos. Por ejemplo, pueden desglosar un monolito de comercio electrónico en aceptación de pedidos y procesos de pago con servicios separados de inventario, cumplimiento y contabilidad.
Una carga de trabajo que puede ser compleja de gestionar y orquestar en un monolito se convierte en una serie de servicios sencillos y desacoplados que se gestionan de forma independiente y se comunican de forma asíncrona a través de mensajes de eventos.
Un enfoque basado en eventos hace posible ensamblar y orquestar servicios que procesan datos a diferentes velocidades. En el siguiente ejemplo, un microservicio de aceptación de pedidos interactúa con un sistema de procesamiento de pagos a través de una cola.
En el ejemplo, el servicio de aceptación de pedidos puede almacenar grandes volúmenes de pedidos entrantes almacenando los mensajes en una cola.
El servicio de procesamiento de pagos, que suele ser más lento debido a la complejidad del manejo de los pagos, puede tomar un flujo constante de mensajes de la cola. El servicio de pago cambia entre varios estados del sistema debido a la lógica de reintento y gestión de errores. El servicio de flujo de trabajo organiza y administra los pasos de pago en función del estado del sistema y, finalmente, produce más eventos de interés para los servicios de inventario, cumplimiento y contabilidad.
Auditaría sencilla
Un enrutador de eventos en una arquitectura basada en eventos actúa como una ubicación centralizada para auditar su aplicación y definir políticas. Estas políticas pueden restringir quién puede publicar y suscribirse a un enrutador, así como también controlar qué usuarios y recursos tienen permiso para acceder a sus datos. También puede cifrar sus eventos tanto en tránsito como en reposo.
Reducción de costos
Las EDA se basan en la inserción, por lo que todo sucede bajo demanda a medida que el evento se presenta en el enrutador. De este modo, no tiene que pagar por el sondeo continuo para comprobar si hay un evento. Esto significa menos consumo de ancho de banda de la red, menos utilización de CPU, menos capacidad de flota inactiva y menos protocolos de enlace SSL/TLS.
¿Cómo funciona una arquitectura basada en eventos (EDA)?
A continuación se muestra un ejemplo de una arquitectura basada en eventos (EDA) para un sitio de comercio electrónico:
%20for%20an%20ecommerce%20site.88b2240905b1b6addd672871b98bcb17bd44d701.jpg)
Este sitio de ejemplo muestra tres componentes principales de productores de eventos y los eventos que producen. En este escenario, un enrutador de eventos ingiere y filtra los eventos, luego envía uno o más eventos a los consumidores de eventos.
La arquitectura basada en eventos permite que el sitio reaccione a los cambios de una variedad de fuentes durante los momentos de máxima demanda, sin bloquear la aplicación ni aprovisionar recursos en exceso.
¿Qué tipos de cargas de trabajo se adaptan a la arquitectura basada en eventos (EDA)?
Las arquitecturas basadas en eventos (EDA) pueden proporcionar una forma eficaz de satisfacer las demandas de cargas de trabajo altamente escalables y de alta disponibilidad. EDA también se aplica bien a las cargas de trabajo con patrones de tráfico impredecibles o “con picos”.
¿Cómo mejora la arquitectura basada en eventos (EDA) las aplicaciones?
La arquitectura basada en eventos (EDA) promueve un acoplamiento flexible entre los componentes, lo que la convierte en un buen enfoque para crear aplicaciones distribuidas modernas.
Los productores de eventos desconocen, no se preocupan ni se sienten abrumados por ninguna actividad de los consumidores intermedios de los eventos que producen. Los eventos en sí mismos representan un cambio de estado y pueden o no contener datos. Los eventos no son conscientes de las consecuencias de su existencia. Los consumidores escuchan y procesan eventos de interés. Puede traer nuevos consumidores en línea para proporcionar nuevas funciones sin interrumpir los flujos de trabajo existentes.
Las EDA promueven la descomposición de sistemas monolíticos en modelos de dominio más pequeños. Los desarrolladores pueden ponerse al día con menos carga cognitiva y volverse productivos más rápido. Cuando las funciones críticas están desacopladas, también hay menos riesgo de desplegar actualizaciones y nuevas características.
¿Cuáles son algunos casos de uso comunes de la arquitectura basada en eventos (EDA)?
Comunicación de microservicios para backends web y móviles
Los sitios web minoristas o de medios y entretenimiento a menudo deben escalar verticalmente para gestionar un tráfico impredecible. Los clientes visitan un sitio web de comercio electrónico y realizan un pedido. El evento de pedido se envía a un enrutador de eventos. Todos los microservicios posteriores pueden recoger el evento de pedido para su procesamiento. Los ejemplos de acciones pueden incluir: enviar el pedido, autorizar el pago y enviar los detalles del pedido a un proveedor de envío.
Debido a que cada uno de los microservicios puede escalar verticalmente y fallar de forma independiente, el proceso puede escalar durante los períodos de pedidos máximos sin puntos únicos de falla.
Automatización del flujo de trabajo empresarial
Muchos flujos de trabajo empresariales, como las transacciones de servicios financieros, requieren repetir los mismos pasos. Puede iniciar y automatizar esos pasos con la arquitectura basada en eventos (EDA).
Por ejemplo, cuando un cliente solicita una nueva cuenta en un banco, el banco debe realizar unas comprobaciones de datos (documento de identidad, dirección, etc.). Algunas cuentas también requerirán una etapa de aprobación humana. Puede orquestar todos estos pasos a través de un servicio de flujo de trabajo que ejecuta los pasos automáticamente cuando se reciben nuevas solicitudes de cuenta.
También puede agregar un flujo de trabajo para procesar los datos de la aplicación del cliente de forma asíncrona con el machine learning para extraer datos relevantes, lo que podría ahorrar horas de recopilación y validación manual de datos.
Integración de aplicaciones de SaaS
Uno de los principales desafíos para los entornos de software como servicio (SaaS) es la falta de visibilidad de la actividad y los datos del usuario. Para desbloquear datos en silos, las arquitecturas basadas en eventos pueden ingerir eventos de aplicaciones SaaS o enviar eventos a sus aplicaciones SaaS. Por ejemplo, puede crear middleware para ingerir datos de pedidos de socios entrantes y enviar los pedidos directamente a una aplicación de procesamiento de pedidos interna.
Infraestructura y automatización
Al ejecutar cargas de trabajo intensivas en cómputo (como análisis financieros, investigación genómica o transcodificación de medios), puede hacer que los recursos de cómputo respondan escalando para un procesamiento altamente paralelo y luego reduciendo una vez que se completa el trabajo.
Por ejemplo, en industrias altamente reguladas, las empresas con una EDA pueden activar los recursos de postura de seguridad en respuesta a un incidente o tomar medidas correctivas cada vez que una política de seguridad envía un evento de alerta.
¿Cuándo debería usar arquitecturas basadas en eventos (EDA)?
Las arquitecturas basadas en eventos (EDA) son ideales para mejorar la agilidad y moverse con rapidez. Se encuentran habitualmente en las aplicaciones modernas que utilizan microservicios o en cualquier aplicación que tenga componentes desacoplados.
Integración de sistemas heterogéneos
Si tiene sistemas que se ejecutan en diferentes pilas, puede usar una EDA para compartir información entre ellos sin acoplamiento. El enrutador de eventos establece la indirección y la interoperabilidad entre los sistemas, para que puedan intercambiar mensajes y datos sin dejar de ser independientes.
Replicación de datos entre cuentas y regiones
Puede utilizar una EDA para coordinar sistemas entre equipos que operan y despliegan en diferentes cuentas y regiones de AWS. Al utilizar un enrutador de eventos para transferir datos entre sistemas, puede desarrollar, escalar y desplegar servicios independientemente de otros equipos.
Monitoreo del estado de los recursos y alertas
En lugar de verificar continuamente sus recursos, puede usar una EDA para monitorear y recibir alertas sobre anomalías, cambios y actualizaciones. Estos recursos pueden incluir buckets de almacenamiento, tablas de bases de datos, funciones sin servidor, nodos de computación, etc.
Procesamiento en paralelo y distribución ramificada
Si tiene muchos sistemas que deben operar en respuesta a un evento, puede usar una EDA para desplegar el evento sin tener que escribir código personalizado para enviar a cada consumidor. El enrutador envía el evento a los sistemas, cada uno de los cuales puede procesar el evento en paralelo con un propósito diferente.
¿Cuáles son los patrones comunes de la arquitectura basada en eventos (EDA)?
Muchas funciones cortas
Cree muchas funciones cortas en lugar de pocas más grandes. Hacer funciones altamente especializadas para su carga de trabajo significa hacerlas concisas, lo que generalmente reduce el tiempo de procesamiento. Cada función debe manejar el evento pasado a la función, sin conocimiento ni expectativas del flujo de trabajo general o el volumen de transacciones. Esto hace que la función sea independiente del origen del evento con un acoplamiento mínimo a otros servicios.
Procesamiento bajo demanda en lugar de lotes
Muchos sistemas tradicionales están diseñados para ejecutarse periódicamente y procesar lotes de transacciones que se acumulan con el tiempo. Por ejemplo, una aplicación bancaria podría ejecutarse cada hora para procesar transacciones de cajeros automáticos en libros mayores centrales.
En la arquitectura basada en eventos (EDA), el procesamiento personalizado puede responder a cada evento. Esto permite que el servicio escale verticalmente según sea necesario para procesar transacciones casi en tiempo real.
Recuperación de interrupciones
En el caso de una interrupción, se puede invocar automáticamente un servicio para volver a intentar procesar un evento. Debido a que el servicio puede recibir el mismo evento más de una vez, las funciones de diseño deben ser idempotentes. Esto garantiza que el resultado no cambie después de la primera vez que el servicio recibe el evento.
Por ejemplo, si un minorista intenta procesar una tarjeta de crédito dos veces debido a un nuevo intento, el servicio procesa el pago solo en el primer intento. En el reintento, el servicio verifica el estado del pago y descarta el evento.
¿Cuáles son algunos desafíos con la arquitectura basada en eventos (EDA)?
Al adoptar una arquitectura basada en eventos (EDA), es posible que deba repensar cómo ve el diseño de su aplicación.
Latencia variable
A diferencia de las aplicaciones monolíticas, que pueden procesar todo dentro del mismo espacio de memoria en un solo dispositivo, las aplicaciones basadas en eventos se comunican a través de redes. Este diseño introduce latencia variable. Aunque las aplicaciones monolíticas pueden tener una latencia más baja o menos variable, esto generalmente se produce a expensas de la escalabilidad y la disponibilidad.
Los servicios de AWS sin servidor tienen alta disponibilidad, lo que significa que operan en más de una zona de disponibilidad en una región de AWS. En el caso de una interrupción del servicio, los servicios se conmutan automáticamente a zonas de disponibilidad alternativas y vuelven a intentar las transacciones. Como resultado, en lugar de que las transacciones fallen, pueden completarse con éxito pero con una latencia más alta.
Las cargas de trabajo que requieren un rendimiento uniforme de baja latencia no son buenas candidatas para EDA. Dos ejemplos son las aplicaciones comerciales de alta frecuencia en los bancos o la automatización robótica inferior a un milisegundo en los almacenes.
Coherencia eventual
Un evento representa un cambio de estado. Con muchos eventos fluyendo a través de diferentes servicios en una arquitectura en un momento dado, dichas cargas de trabajo a menudo son eventualmente coherentes. Esto hace que sea más complejo procesar transacciones, gestionar duplicados o determinar el estado general exacto de un sistema.
Algunas cargas de trabajo no son adecuadas para EDA debido a la necesidad de propiedades ACID. Sin embargo, muchas cargas de trabajo contienen una combinación de requisitos que eventualmente son coherentes (por ejemplo, pedidos totales en la hora actual) o muy coherentes (por ejemplo, inventario actual). Para aquellas características que necesitan una coherencia de datos sólida, existen patrones de arquitectura para respaldar esto. Por ejemplo:
- DynamoDB puede proporcionar lectura con coherencia fuerte, a veces con una latencia más alta y también puede admitir transacciones para ayudar a mantener la coherencia de datos.
- Puede usar bases de datos relacionales para funciones que necesitan propiedades ACID, aunque cualquier base de datos relacional es menos escalable que un almacén de datos NoSQL.
Devolución de valores a los interlocutores
En muchos casos, las aplicaciones basadas en eventos son asincrónicas. Esto significa que los interlocutores de servicios no esperan solicitudes de otros servicios antes de continuar con otro trabajo. Esta característica fundamental de las EDA permite escalabilidad y flexibilidad; sin embargo, hace que pasar los valores de retorno o los resultados del flujo de trabajo sea más complejo que en los flujos sincrónicos.
En muchos casos, devolver un valor es menos importante que garantizar el éxito o el fracaso del procesamiento del evento. Las características que aseguran el procesamiento de eventos pueden ser más importantes que devolver valores un interlocutor.
Para cargas de trabajo interactivas, como aplicaciones web y móviles, el usuario final generalmente espera recibir un valor de retorno o el estado actual de una transacción. Para estas cargas de trabajo, existen varios patrones de diseño que pueden proporcionar eventos enriquecidos a la persona que llama. Sin embargo, estas implementaciones en una arquitectura basada en eventos son más complejas que usar un valor de retorno asíncrono tradicional. La plataforma a menudo puede mitigar esta complejidad.
Depuración entre servicios y funciones
La depuración de sistemas controlados por eventos es diferente a la depuración de una aplicación monolítica. Al igual que con todas las aplicaciones basadas en microservicios y diferentes sistemas y servicios que pasan eventos, puede ser un desafío registrar y reproducir el estado exacto de múltiples servicios cuando ocurre un error. Debido a que cada invocación de servicio y función tiene archivos de registro separados, puede ser más complicado determinar qué sucedió con un evento específico que provocó un error.
Orquestación
Es común que los flujos de trabajo simples se vuelvan más complejos con el tiempo. En un monolito típico, esto puede resultar en grupos de funciones y servicios más estrechamente acoplados, así como también en excepciones y enrutamiento de gestión de código complejo.
Para realizar un seguimiento del estado del sistema, los flujos de trabajo que implican lógica de bifurcación, diferentes tipos de modelos de error y lógica de reintento suelen utilizar un orquestador. Al crear una aplicación sin servidor basada en eventos, es importante identificar cuándo sucede esto para que pueda migrar esta lógica a una máquina de estado para una orquestación adecuada.
¿Qué servicios de AWS utilizan una arquitectura basada en eventos (EDA)?
Los servicios de AWS suelen producir o consumir eventos, lo que facilita la creación de soluciones con una arquitectura basada en eventos (EDA).
Además, servicios como Amazon EventBridge, Amazon SNS, Amazon SQS y AWS Step Functions incluyen características que ayudan a los clientes a escribir menos código repetitivo y crear EDA más rápido.
Amazon EventBridge
Puede utilizar Amazon EventBridge para crear buses de eventos para aplicaciones basadas en eventos a escala utilizando eventos de aplicaciones SaaS, otros servicios de AWS o aplicaciones personalizadas.
EventBridge aplica reglas para enrutar eventos desde orígenes de eventos a diferentes destinos. Los destinos pueden incluir servicios de AWS como AWS Lambda, Step Functions y Amazon Kinesis, o cualquier punto de conexión HTTP a través de destinos de la API de EventBridge.
Una integración popular para los casos de uso de EDA es Step Functions, en la que los eventos desencadenan flujos de trabajo específicos.
AWS Step Functions
AWS Step Functions incluye Workflow Studio, un diseñador de flujo de trabajo visual de bajo código que los desarrolladores utilizan para orquestar diferentes servicios de AWS. Puede usar Workflow Studio para crear aplicaciones distribuidas, automatizar procesos comerciales y de TI, y crear canalizaciones de datos y machine learning con los servicios de AWS.
Amazon SNS
Recomendamos utilizar Amazon Simple Notification Service (Amazon SNS) para crear aplicaciones que reaccionen a eventos de alto rendimiento y baja latencia publicados por otras aplicaciones, microservicios o servicios de AWS. También puede usar Amazon SNS para aplicaciones que necesitan una distribución muy alta de miles o incluso millones de puntos de conexión.
Amazon SQS
Amazon Simple Queue Service (Amazon SQS) ofrece un servicio de cola alojado seguro, duradero y disponible que puede utilizar para integrar y desacoplar componentes y sistemas de software distribuidos. Amazon SQS ofrece construcciones comunes, como colas de mensajes fallidos y etiquetas de asignación de costos.
Siguientes pasos para la arquitectura basada en eventos de AWS
Obtenga acceso inmediato al nivel Gratuito de AWS.
Comience a crear en la consola de administración de AWS.