Header Ads Widget

Ticker

6/recent/ticker-posts

¿Cuál es la diferencia entre los agentes de eventos y las colas de mensajes?


 Anteriormente hemos hablado de una amplia gama de temas relacionados con los mensajes y eventos de API: desde las pautas de integración actuales hasta los protocolos para arquitecturas de API controladas por eventos , la idea de aprovechar estos sistemas para automatizar y agilizar la comunicación ha sido de gran interés. A continuación, veremos dos estilos dentro de este amplio dominio: Agentes de eventos y Colas de mensajes. Compararemos los dos tipos, veremos casos de uso y consideraremos algunos beneficios y desventajas de cada enfoque.

¿Qué es un agente de eventos?

Para comprender qué es un agente de eventos, es útil comprender qué es un evento y cómo funciona dentro de la arquitectura dirigida por eventos . En su forma más simple, un evento es cualquier acción que produce un cambio de estado. Este cambio de estado puede ser simple o complejo, pero tan pronto como se cambia el estado, cuenta como un evento. En el enfoque de Arquitectura basada en eventos, los consumidores se "suscriben" a estos eventos y reciben notificaciones cuando ocurren. Esto contrasta con el modelo tradicional de servidor-cliente, en el que un cliente solicita activamente actualizaciones sobre un conjunto de información. En otras palabras, es un sistema de "empujar", no de "tirar".

En esta arquitectura, hay tres actores. El Productor del Evento es la entidad que se encarga de la generación del Evento; esta suele ser la propia API. A continuación, está el mediador o corredor; cuando este Evento se envía al Consumidor, se distribuye de manera ordenada a consumidores específicos (Mediador) o se transmite por igual a todas las partes interesadas (Broker). Finalmente, el último actor, el Consumidor, recibe estos eventos y los procesa para el propósito que desee.

Este es el orden básico de las cosas, pero incluso entonces, hay diferentes tipos de corredores. Algunos corredores pueden proporcionar inscripciones de suscripción simples, mientras que otros pueden enviar eventos a un registro en función de atributos definidos previamente. En última instancia, el paradigma sigue siendo el mismo: ocurre un evento, se envía al corredor y luego a las partes interesadas.

Pros

La principal ventaja de un agente de eventos es que crea una canalización de información directa entre el generador de eventos y las partes interesadas. Esto significa que cuando ocurre un cambio de estado, esas partes pueden saber casi de inmediato que sucedió. Esto es especialmente útil para funciones lógicas. Por ejemplo, si queremos detectar cuando un paquete ha entrado en una instalación de producción, podemos usar una API en una plataforma ponderada para simplemente emitir un cambio de estado de evento a todas las partes interesadas, actualizando al gerente de la oficina, el asistente de producción, el motor de recepción. , etc., que ha llegado un paquete (o, al menos, que el estado de la almohadilla ha cambiado).

También se pueden lograr funciones más complejas con Event Brokers encadenados. Por ejemplo, si usamos un intermediario de eventos basado en registros, podemos "reproducir" estos eventos como parte de un registro histórico. Esto puede ser útil en el otro lado de nuestro ejemplo de entrega de paquetes, donde la empresa de envío puede detectar que un paquete fue escaneado desde la parte trasera del camión, lo que desencadenó un evento de "entrega" para salir al sistema de envío. Desde aquí, el registro se puede auditar al final del día para "reproducir" esas entregas en comparación con la recepción de paquetes verificada por el consumidor.

Contras

Si bien los Agentes de eventos encadenados pueden realizar funciones más complicadas, definitivamente existe un problema a escala. Suponga que un cambio de evento es el determinante de enviar información al usuario. En ese caso, estamos algo limitados en lo que se puede lograr. Por ejemplo, ¿qué sucede si no queremos que el usuario sepa que algún estado ha cambiado hasta que verifiquemos que se solicitó el cambio en un almacén de datos, que se hizo correctamente, que se hizo dentro de la política y que se ha comprometido con el servidor de producción? Para hacer esto, necesitaríamos una serie de mediadores de eventos mezclados con nuestros Agentes de Eventos, y tendríamos que cronometrar estos eventos a través de un flujo de datos relativamente complejo.

¿Qué es una cola de mensajes?

Los agentes de eventos resuelven un problema simple: ¿cómo informamos a un consumidor sobre un cambio de estado? Las colas de mensajes resuelven el mismo tipo de problema pero de una manera diferente. La idea simple de una cola de mensajes es que, en lugar de que un consumidor se suscriba a una actualización de eventos, los elementos o servicios individuales pueden tener una cola de mensajes que contenga una variedad de llamadas ordenadas secuencialmente y enviadas a todas las partes interesadas.

En esencia, en lugar de que un evento dé como resultado un servicio que le grite a un grupo de partes interesadas “¡sucedió algo!”, Una cola de mensajes toma un evento o salida que requiere procesamiento adicional y lo agrega a una cola larga. Más adelante, los consumidores o procesadores adicionales pueden mirar la cola y sacar el mensaje de la línea para reprocesar, mantener o agregar a sus propios procesos.

Las colas de mensajes pueden utilizar patrones intrincados para abordar sus mensajes en un esfuerzo por dirigir correctamente los cambios de estado en el sistema. El enrutamiento basado en temas puede ayudar a abordar los cambios de estado a las partes relevantes sin que esas partes realmente soliciten los datos. Alternativamente, las relaciones pub-sub pueden ayudar a las partes a suscribirse a áreas generales de interés, que luego pueden usarse como categorías para esos mensajes.

Pros

Desacoplar el paradigma de "remitente y receptor" inherente a algo como un agente de eventos puede permitir interacciones significativamente más personalizadas. No todos los destinatarios saben a quién preguntar por sus eventos o mensajes, y no todos los remitentes querrán mantener una lista continua de todas las partes interesadas. Esto es especialmente importante en los mensajes, ya que los mensajes suelen ser piezas de datos que requieren procesamiento o contextualización adicional.

Quizás la mayor ventaja de adoptar un modelo de Message Queue es que permite mayores niveles de comunicación asincrónica . Cuando tiene varios corredores encadenados, termina teniendo una línea de espera para el manejo de datos: los consumidores tienen que esperar a que alguien haga algo antes de procesar sus propios datos. Bajo este modelo, eso ya no es un problema: los procesadores pueden tomar datos de la cola y hacer lo que necesitan hacer con ellos cuando noten que están disponibles.

Contras

Con una mayor complejidad viene una mayor dificultad para hacer cosas simples. También puede ser demasiado complicado para la tarea en cuestión. Por ejemplo, si está manejando un solo generador de mensajes y una sola parte interesada, realmente no necesita una cola. Si la parte interesada solo va a realizar una función y devolverla al creador del mensaje, entonces realmente se trata de un sistema de eventos simple. El uso de Message Queue para una función simple podría introducir una complejidad significativa con poca ganancia, lo que podría afectar la usabilidad y la eficiencia.

Desafortunadamente, los sistemas extremadamente complejos también pueden sufrir problemas con el enfoque de Message Queue. Si bien una cola de mensajes, hasta cierto punto, tiende a ayudar, cuando se introducen más mensajes y las interacciones son más complejas, la naturaleza asincrónica y almacenada en búfer de la cola de mensajes puede hacer que demasiados mensajes vean demasiados mensajes. entidades. En última instancia, en tal caso, un sistema centrado en microservicios con un enfoque combinado de Event Brokers y Message Queues tiene más sentido.

¿Cuál es la mejor opción?

Al igual que con cualquier cosa en el espacio de la API, su implementación particular determinará si un agente de eventos o una cola de mensajes son adecuados para su escenario. Cada uno de estos paradigmas tiene algunos casos de uso específicos en los que tienen más sentido.

Los Agentes de eventos se utilizan mejor cuando la relación entre el generador de eventos y las partes interesadas es relativamente simple, o cuando el Evento no da como resultado un procesamiento asincrónico adicional. Si su API simplemente necesita saber cuándo ha cambiado un estado para actualizar otra API o iniciar otro proceso, no es necesario complicar demasiado el sistema y agregar gastos generales adicionales.

Por otro lado, si está viendo un flujo de datos que requiere transformación como resultado de un evento, es decir, un evento requiere transformación encapsulada como un mensaje, tiene más sentido que estos mensajes pasen por una cola. De esta forma, los interesados ​​pueden actuar cuando tenga sentido, tirando de forma asincrónica cuando corresponda.

Uso de agentes de eventos y colas de mensajes

Otro nivel de este problema probablemente nos dé la respuesta más fácil a la pregunta de "cuál es la mejor opción": ambas lo son. Estos no son conceptos mutuamente excluyentes y, en muchos casos, pueden tener sentido dentro de la misma arquitectura como elementos mutuamente cooperativos.

Para llevar más allá nuestro ejemplo de envío, imagine que escaneamos un paquete tal como se recibió en función del felpudo ponderado. Desde aquí, es posible que deseemos enviar un evento para informar al gerente de la oficina que ha llegado un paquete, pero también podemos enviar un mensaje notificando a la API que se notificó al gerente y que el paquete está esperando ser recogido. Es posible que la API de cadena de custodia desee esperar hasta que el tapete emita un nuevo evento de que el paquete ha sido recogido para crear un registro de custodia para notificar a varios otros sistemas que controlan el inventario. Los eventos simples ocurren en cada una de estas etapas, pero también lo hacen los eventos y los paquetes de datos que necesitan procesamiento adicional, a menudo de manera retardada y, a menudo, en varios sistemas.

En pocas palabras, Event Brokers y Message Queues son dos caras de la misma moneda y deben verse como elementos de apoyo en una solución cohesiva, en lugar de como opciones en competencia.

Conclusión

¿Qué opinas de este resumen? ¿Perdimos algunos puntos importantes? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios