Introducción a las arquitecturas basadas en eventos

Todos los desarrolladores, arquitectos y gerentes de producto están acostumbrados a las API REST y al paradigma síncrono de la comunicación. Hace una solicitud y espera la respuesta. Así es exactamente como funciona la web. Ingresa una URL (por ejemplo, google.com) en la barra de direcciones de su navegador favorito y envía una solicitud al servidor. A continuación, el servidor envía la respuesta con el contenido del sitio web. La web es la mayor implementación de una API REST.

Sin embargo, hay ciertas situaciones en las que realmente no necesita una respuesta del servidor. Al menos nada más y nada menos que la confirmación de que se ha recibido la solicitud. Esto también se llama «dispara y olvídate» , y es realmente útil cuando solo quieres comunicarte o informar que «algo sucedió». Es decir, no está solicitando ni pidiendo nada, por lo que no necesita una respuesta. Ejemplos de esto son:

• Un usuario acaba de registrarse.
• Tienes un nuevo seguidor.
• Tu nevera se está vaciando.

Junto con el evento, es posible que también desee enviar información adicional . Por ejemplo:

• Un usuario que acaba de registrarse: aquí está la información del usuario (por ejemplo, nombre, correo electrónico, edad, etc.)
• Tiene un nuevo seguidor: aquí están los detalles del seguidor (por ejemplo, nombre de usuario, nombre, imagen, etc.)
• Tu refrigerador se está vaciando: aquí está el porcentaje de «vacío» (p. Ej., 23%)

Esta información adicional a menudo se denomina carga útil de evento o carga útil de mensaje .

Conceptos básicos

En la mayoría de los casos, las arquitecturas controladas por eventos (EDA) están centradas en el intermediario, como en el diagrama anterior. En él puedes encontrar algunos conceptos nuevos, así que vamos a repasarlos ahora.

Agente de mensajes
Un intermediario de mensajes (o «intermediario» ) es una pieza de infraestructura que se encarga de recibir mensajes y entregarlos a quienes han mostrado interés. A menudo almacenan mensajes hasta que se entregan, lo que hace que los EDA sean muy resistentes a las fallas. Ejemplos de corredores son RabbitMQ , Apache Kafka , Solace , etc.

Editor / suscriptor
Un editor (también conocido como productor ) es una aplicación que envía mensajes al corredor .
Un suscriptor (también conocido como consumidor ) es una aplicación que se conecta al corredor , manifiesta interés en cierto tipo de mensajes y deja la conexión abierta para que el corredor pueda enviarles mensajes.

Mensaje
Un mensaje es una pieza de información que los editores envían al corredor y que reciben todos los suscriptores interesados. El contenido del mensaje puede ser cualquier cosa, pero con frecuencia se catalogan como eventos y comandos . Como vimos anteriormente, los eventos comunican un hecho que ocurrió. En cambio, los comandos se parecen mucho a las solicitudes en las API REST: les dicen a los suscriptores «haz esto». Técnicamente hablando, los eventos y los comandos son los mismos. La única diferencia está en su semántica.

Canales
Un detalle que puede pasar desapercibido del diagrama anterior es la existencia de canales . Todos los corredores admiten la comunicación a través de múltiples canales. Sin embargo, la industria no tiene un término común, por lo que puede encontrarlos como temas , claves de enrutamiento , tipos de eventos y probablemente otros que me faltan.

Por lo general, se les asigna un nombre o identificador (p. Ej., user_signed_up) y a menudo es una buena práctica enviar un solo tipo de mensaje a través de ellos. Piense en los canales de televisión o radio: la BBC solo emite su información a través de un canal asignado. Si las emisoras (editoras) no respetaran esa regla, usted (el suscriptor) solo vería y oiría las interferencias.

¿Por qué «impulsado por eventos» y no «impulsado por mensajes»?

Encontrará que ambos se usan indistintamente, aunque no son exactamente iguales. Incluso encontrará «basado en mensajes» y «basado en eventos» . En la práctica, es probable que todos se refieran a lo mismo. En teoría, «impulsado por mensajes» es el término más genérico, lo que significa que puede usar eventos y comandos, mientras que impulsado por eventos significa que se trata puramente de eventos. Sin embargo, ese no es siempre el caso, como explica Martin Fowler en su charla «los muchos significados de la arquitectura impulsada por eventos» :

AsyncAPI

Hemos visto qué es una arquitectura impulsada por eventos, cómo funciona y cuáles son sus componentes. AsyncAPI trata de definir y documentar cada uno de estos componentes.

AsyncAPI es una iniciativa de código abierto que busca mejorar el estado actual de las arquitecturas impulsadas por eventos (EDA). Nuestro objetivo a largo plazo es hacer que trabajar con EDA sea tan fácil como trabajar con API REST. Eso va desde la documentación hasta la generación de código, desde el descubrimiento hasta la gestión de eventos. La mayoría de los procesos que aplica a sus API REST hoy en día también serían aplicables a sus API asincrónicas / controladas por eventos.

Para que esto suceda, el primer paso ha sido crear una especificación que permita a los desarrolladores, arquitectos y gerentes de producto definir las interfaces de una API asíncrona. Al igual que OpenAPI (fka Swagger) lo hace para las API REST.

La especificación AsyncAPI sienta las bases para un mayor y mejor ecosistema de herramientas para EDA . Recientemente lanzamos la especificación 2.0.0 de AsyncAPI, la versión más fuerte hasta la fecha, que sostendrá las arquitecturas impulsadas por eventos del mañana.

Si está buscando una solución para automatizar y formalizar la documentación o la generación de código de sus (micro) servicios basados ​​en eventos, está en el lugar correcto. Del mismo modo, si su objetivo es establecer estándares sólidos para sus eventos y mejorar la gobernanza de sus API asincrónicas, bienvenido a su nuevo hogar.