Eventos
12
min de lectura
18 de julio de 2019

Eventos, Event-Driven Architecture, y Async APIs. ¿Qué pasa con el tenedor?

Ana Paula Borges
Jefe de Tecnología de Innovación de Ventas @Ambev
Diseño de la API siguiendo los conceptos de RESTFull. Desarrollo de API en JavaScript, Java. Desarrollo de Microservicios en Java. Desarrollo de integraciones en IIB Broker. Modelado de servicios para el protocolo SOAP. Desarrollo de sistemas en Graphql.
Más sobre el autor

Un evento es cada una de las acciones que provocan un cambio de estado sistémico. Según Gartner, en 2020, el conocimiento de la situación en tiempo real y a través de eventos será una característica esencial para el 80 % de las soluciones empresariales digitales, y el 80 % de los nuevos ecosistemas empresariales requerirán soporte para el procesamiento de eventos.

Los temas sobre Eventos, Event-Driven Architecture, y APIs Async son cada vez más populares, pero ¿por qué? ¿Y de qué se trata?

Cuando trabajamos con asuntos basados en eventos, lo que nos importa es un evento que sea significativo para las actividades de la organización, como la solicitud de un cliente, la realización de una transacción de pago, entre otros. Llamamos a este evento un acontecimiento empresarial.

Event-Driven Architecture -o EDA, como lo conocen los amigos más cercanos- es un estándar de arquitectura que promueve la producción, la detección, el consumo y la reacción a los eventos empresariales.

EDA es una forma de realizar la comunicación entre sistemas que consiste principalmente en operaciones asíncronas, además de permitir aplicaciones más escalables y generar menos acoplamiento entre servicios, permitiendo así una arquitectura altamente flexible.

Es un modelo que no depende del tamaño de su arquitectura, es decir, puede adaptarse a sistemas de cualquier tamaño. Hay tres componentes importantes de EDA:

  • Generador(es) de eventos;  
  • Mediador o intermediario;
  • Consumidores de eventos.

Los generadores de eventos son los responsables de provocar el evento. Puede ser, por ejemplo, una plataforma de datos de clientes que, cuando el cliente cambia de dirección, se encarga de generar el evento que transmitirá esta acción a los consumidores. Los consumidores de eventos son las partes interesadas en el evento.

Tomemos, por ejemplo, el caso de un seguro de automóvil. Si un cliente se traslada a otra dirección, el interesado es el servicio de cotización, ya que un cambio en la ubicación del cliente podría afectar a la tarifa del seguro.

El mediador o broker se encarga de recibir el evento y transmitirlo a los consumidores. Es importante que entiendas bien tu propia necesidad y la combines con una de las topologías EDA, mediador o broker, porque establecer correctamente el intermediario del evento es esencial para implementar con éxito un EDA. ¿Sabes cuándo utilizar el mediador y cuándo el broker? Averigüémoslo juntos!

Topologías EDA

Mediador

El mediador se utiliza principalmente cuando es necesario realizar una manipulación u orquestación en el procesamiento de eventos. En esta topología, hay cuatro tipos de componentes principales: la cola, el mediador, los canales y los procesadores (todos relacionados con los eventos). El flujo de eventos comienza cuando el cliente envía un mensaje a la cola, que se encarga de transportar el evento al mediador. El mediador recibe el evento inicial y realiza su orquestación enviando eventos asíncronos adicionales a los canales para realizar cada paso del proceso.

Los procesadores, que escuchan en los canales, reciben el evento del mediador y realizan una lógica de negocio específica para procesarlo.

Hay dos tipos de eventos en esta topología, el evento inicial y el evento de procesamiento. Llamamos evento inicial al evento original que fue recibido por el mediador, mientras que los eventos de procesamiento son aquellos que son generados por el mediador y recibidos por los procesadores. Hay que tener en cuenta que el mediador de eventos no realiza ninguna lógica de negocio, sólo conoce los pasos necesarios para procesar el evento.

Y es importante tener en cuenta que, independientemente de su granularidad, el procesador de eventos debe ser responsable de ejecutar una única tarea de negocio, y no puede depender de otros procesadores para completar su tarea.

Somos bastante teóricos, ¿no? ¿Qué tal un ejemplo de uso?

Imaginemos el escenario que mencionamos antes, de una compañía de seguros: cuando el cliente cambia de dirección, es necesario recalcular la prima del seguro, porque puede haber cambiado a un lugar más peligroso, o incluso más tranquilo, lo que influye directamente en las tarifas que paga el asegurado. En este caso, podemos implementar una solución con EDA, como se muestra en la figura siguiente:

En este ejemplo, está el servicio de atención al cliente, que es el responsable de cambiar los datos y lanzar el evento de cambio de dirección a la cola, tras lo cual el servicio de atención al cliente sigue su flujo normal. El mediador de eventos puede ser notificado de que ha llegado un evento, o incluso comprobar la cola para obtener nueva información, todo depende de cómo se decida implementarlo. El mediador, que conoce el flujo que debe seguir el evento, notificará primero al servicio de cotización, que a su vez recalculará la tarifa de la prima del seguro y devolverá el evento procesado al mediador.

El mediador comprobará si se ha producido un cambio de cotización y, en caso afirmativo, el servicio de notificación es el siguiente en recibir el evento y se encargará de notificar al cliente el cambio de tarifa del seguro. Si el valor no se ha modificado, el flujo de eventos termina ahí mismo. El mediador puede implementarse, por ejemplo, con Apache Camel o Spring Integration.

Agente de bolsa

Cuando tenemos un flujo de eventos simple, en el que no necesitamos realizar una orquestación de eventos, utilizamos la topología de broker, que no tiene un mediador de eventos central. Puede ser centralizado y cuenta con los canales que se utilizan en el flujo, que pueden seguir el modelo de colas o temas de mensajes, o incluso una combinación de ambos. Los principales componentes de la topología broker son el broker y los procesadores.

Los brokers soportan la comunicación multi-channel , y cada canal recibe un identificador, y se recomienda como buena práctica enviar sólo un tipo de mensaje a este canal. Ahora, pensando en el mismo ejemplo que mencionamos anteriormente, veamos cómo funcionan las cosas si implementamos la topología del broker:

Al igual que con el mediador, el servicio de atención al cliente publicará el evento de cambio de dirección en la cola, pero en este escenario, no tenemos el mediador para orquestar el evento. El servicio de cotización recibirá el evento a través de la cola, lo que puede hacerse mediante una estrategia pull o push, y realizará el procesamiento.

Si la tarifa de la prima ha cambiado, el servicio de cotización publicará otro evento en la cola de notificaciones, que indicará que el servicio de notificación debe enviar la notificación X al cliente Y. Si la tarifa del seguro no ha cambiado, el servicio de cotización terminará el procesamiento sin activar ningún evento. Para esta solución, podemos utilizar ActiveMQ, Pub/Sub de Google, por ejemplo.

Ahora que hemos visto las topologías, veamos algunos escenarios que se ajustan a una solución utilizando EDA...

Según el libro de W. Roy Schulte Procesamiento de eventoshay tres escenarios principales: la difusión de información, que es cuando tenemos en cuenta la necesidad de mantener la consistencia de los datos entre las diferentes aplicaciones y el evento principal no necesita pasar por cambios de datos antes de llegar a los procesadores; el conocimiento de la situación, cuando normalmente tenemos que analizar eventos de diferentes fuentes para generar una nueva notificación para uno o más procesadores; y la integración de aplicaciones, en la que debemos considerar los enfoques que generarán el mínimo acoplamiento entre las aplicaciones que estarán involucradas en la integración. Cada escenario requerirá una forma diferente de implementación de la arquitectura.

¿Y cuáles son los principios fundamentales de esta arquitectura?

  • Informa de la actualidad: las notificaciones deben informar siempre de un incidente.
  • Envía notificaciones: las notificaciones deben ser enviadas desde el generador de eventos a los procesadores, no al revés.
  • Responde inmediatamente: el procesador siempre debe actuar inmediatamente después de recibir la notificación, incluso si la acción significa no hacer nada.
  • Lacomunicación fluye sólo en una dirección: las notificaciones deben seguir el estilo "dispara y olvida", por el cual el generador enviará la notificación y seguirá su flujo normalmente, sin esperar el procesamiento del evento por el procesador. La preocupación por que los procesadores reciban la notificación con éxito pasa a ser responsabilidad de la cola o del mediador.
  • Está libre de órdenes: una notificación informa de la ocurrencia de un evento. No debe decir qué debe hacer el procesador que recibirá el evento; cada procesador debe saber qué hacer con el evento.

Muy bien, Ana. Has estado hablando y hablando de ello, pero ¿qué debo hacer ahora?

En primer lugar, debes entender tus necesidades; no porque este tema haya sido exagerado debes cambiar toda tu arquitectura para implementarlo. Entonces, ¿has analizado las cosas y has detectado una carencia? Entonces, elijamos la mejor arquitectura para ello.

Una solución sincrónica podría resolver su problema. Hemos comprobado y nos damos cuenta de que EDA se ajusta perfectamente al problema? Vamos a elegir el patrón que mejor se adapte a su escenario.

¿Quieres conocer los patrones?

Esté atento a nuestro blog, porque pronto (¡de verdad!) tendremos un artículo sobre ello.

Y por último, ¡manos a la obra! Es necesario realizar pruebas de concepto y poner en práctica la propia solución.

¿Y sabes qué es lo mejor? Que no tienes que hacerlo por tu cuenta. Ponte en contacto con nosotros, tenemos un equipo de expertos dispuestos a ayudarte.

¡Gracias por leer!