• Introducción

• Limitaciones sistemas actuales

• Ventajas EDA

• Casos de uso

Introducción

La arquitectura dirigida por eventos es un patrón de arquitectura que utiliza notificaciones de eventos como principal mecanismo para comunicar información entre distintas aplicaciones. Este patrón esta bien definido y esta establecido desde hace mucho tiempo, sin embargo ha llegado a la estandarización de otras practicas similares de comunicación como son SOA o REST. 

La Arquitectura Dirigida por Eventos encaja de manera natural en aplicaciones modernas distribuidas, como pueden ser aplicaciones basadas en microservicios o arquitecturas sin servidor. El correcto funcionamiento de esta arquitectura depende principalmente de las habilidades y practicas usadas para el diseño que de tecnologías especificas.

Esta arquitectura no viene a sustituir otras usadas anteriormente, como puede ser la comunicación mediante llamadas API Rest, sino a convivir con ellas. Por lo que el desarrollador siempre deberá combinar EDA con  otros paradigmas de comunicación.

En la siguiente imagen podemos ver la EDA frente a una arquitectura basada en comunicación REST.

Open

Limitaciones sistemas actuales

• El cliente debe esperar a la respuesta para cada petición. 

• Las peticiones pueden tener éxito o fallar de varias formas, se deben tener en cuenta los distintos escenarios.

• El servicio debe estar disponible en el momento de la invocación.

• El cliente dicta que servicio procesa cada solicitud.

Ventajas EDA

• El consumidor no necesita conocer al generador (endpoint, Ip, etc), con conocer la estructura del evento generado y el id al que suscribirse es suficiente. De esta manera si por alguna razón se actualiza el consumidor cambiando sus endpoint o la propia IP no será necesario ningún cambio en los servicios consumidores.

• Limitación falta disponibilidad: Por lo general, en otras arquitecturas de comunicación, una petición espera una respuesta, ya sea de confirmación o con la información solicitada. En EDA no se requiere esta confirmación, un servicio generador lanza un evento y no espera la confirmación de los servicios que consuman ese evento. Por otro lado, el consumidor podrá procesar este evento cuando no este ocupado ya que el evento permanecerá en el bróker.
  
  
  
  

  Open

  

• Saturación: Se evita la saturación de los servicios generadores en los casos que hay una gran demanda por parte se aplicaciones consumidoras.

• Extracción de datos. Los clientes deben solicitar la información a los servicios generadores. Esto no produce problemas si los datos son persistentes, pero no es eficiente si los datos consultados son de un proceso continuo, como puede ser un sensor, (…)

• Proceso de cambios y extensión. En otras arquitecturas de comunicación cuando se produce un cambio como puede ser añadir, modificar o eliminar un microservicio, es posible que también se deban producir cambios en el resto de los servicios. Esto no sucede en EDA, debido a la abstracción de los microservicios, los productores o consumidores de eventos se pueden agregar a un sistema sin cambiar ningún proceso explícito.
  
  
  

• Control de estado: Los eventos por definición son un cambio en el estado, esto hace que de una manera más o menos automática podamos conocer el estado de un servicio con un vistazo a la lista de eventos.
  
  
  

• Sincronización de datos: En una arquitectura basada en microservicios es posible que se necesiten replicas de información de otros servicios para ser usadas como caché o para optimizar las consultas. Mantener estas replicas en un sistema tradicional basado en peticiones puede ser altamente ineficiente, en cambio el patrón controlado por eventos permite que los cambios de datos dentro de un servicio se publiquen al resto de servicios interesados, que pueden actualizar sus propias réplicas en función de los eventos. Esto es un eventualmente proceso consistente asumiendo que no se pierden eventos.