¿Qué es el concepto "controlado por eventos" y cómo de rápido es el concepto "en tiempo real"?
Si pensamos sobre ello, podemos identificar numerosos escenarios controlados por eventos. Muchas de ellos requieren una reacción en tiempo real.
¿Qué queremos decir con "en tiempo real"?
Una reacción en tiempo real puede considerarse una respuesta inmediata. Piense por ejemplo en un encargado de cobros de una cafetería que le pregunta qué va a tomar.
Este espera una respuesta instantánea, o al menos una respuesta muy rápida. De lo contrario, es posible que vuelva a formular la pregunta o piense que es un maleducado. En este caso, una respuesta rápida no solo es lo requerido, sino lo adecuado. El tiempo de respuesta puede variar ligeramente, pero todavía se ve como "en tiempo real". Por tanto, devolver un saludo debe ocurrir rápidamente, pero es correcto pensar brevemente en el pedido para responder a la pregunta del cajero.
Si traduce esta situación a los sistemas de software, lo que más le interesa son los tiempos: el tiempo de respuesta, el tiempo de finalización, el tiempo de acceso, los tiempos de inicio, etc. El usuario o la aplicación de acceso definen esos intervalos.
Nota:
En las situaciones en tiempo real, las tareas de los sistemas realizan su función dentro de las fechas límite establecidas.
Siempre debe tener en cuenta lo que ocurre en el sistema. Por lo tanto, asegúrese de no olvidar lo obvio, que es el registro, la supervisión y la medición de los tiempos.
Importante
Asegúrese de especificar las fechas límite y los tiempos de antemano, y configurar una solución de supervisión sin bloqueo para la comprobación.
En resumen, estamos de acuerdo en que el tiempo real significa muy rápido, en un instante. La rapidez exacta la especifica el escenario determinado.
Aplicaciones controladas por eventos
Si piensa en un evento de clic, piensa en otra cosa. Las aplicaciones controladas por eventos usan el principio enviar y olvidar. El evento se envía o se dispara hacia el siguiente sistema, que puede ser otro servicio, un centro de eventos, una secuencia o un agente de mensajes como Kafka. No esperamos necesariamente una respuesta del siguiente elemento del sistema. El acoplamiento suelto se logra por el precio de la coherencia eventual, que se debe tener en cuenta en otro nivel.
Para identificar la naturaleza de las aplicaciones controladas por eventos, echemos un vistazo a los principales patrones de arquitectura con el ejemplo de un cliente, llamado Alex, que pide un café y un capuchino.
Notificación de evento
La notificación de eventos es, como su nombre indica, la notificación de un suceso o evento específico. Cada evento se ve de forma independiente. El ejemplo de un cliente, llamado Alex, que pide un café y un capuchino puede tener el siguiente aspecto:
1. Evento: Alex compra un café.
2. Evento: Alex pide un capuchino.
Un camarero tendría que escuchar atentamente todos los eventos para obtener todo el pedido de Alex. Pero dos camareros también podrían preparar y servir las bebidas de forma independiente.
Transferencia de estado transportado por eventos
Con la transferencia del estado transportado por eventos, toda la información necesaria se almacena en un único evento. Esto resulta útil si se pierde un evento o el servicio no está escuchando todos los eventos. En nuestro ejemplo, los eventos tendrían el siguiente aspecto:
1. Evento: Alex compra un café.
2. Evento: Alex pide, además del café, un capuchino.
Con un camarero, escuchar solo el segundo evento podría ser suficiente. Con dos camareros, el segundo tendría que mirar al primero. Podrían servir juntos el pedido, pero el proceso sería más largo que si lo hicieran completamente desacoplados.
Aprovisionamiento de eventos
Con el aprovisionamiento de eventos, entra en escena el almacenamiento de eventos. Como puede ver, los eventos son los mismos que en el primer ejemplo. Sin embargo, el barista es importante en este concepto en el momento en el que recibe un evento y piensa en todos los eventos correspondientes para obtener el estado actual de todos los pedidos que ha hecho Alex.
Al recibir el segundo pedido, el camarero sabe que el pedido de Alex consta de un café (porque recuerda el primer pedido) y un capuchino (porque es lo que acaba de pedir). No es tan fácil trabajar en paralelo con un segundo camarero.
Cuando agregamos un cajero para recibir los pedidos y servir las bebidas, los baristas pueden trabajar de forma independiente para preparar las bebidas. No necesitan saber nada sobre los clientes. El encargado de cobros es lo que se denomina el almacenamiento de eventos, que conserva los eventos, en ese escenario. El aprovisionamiento de eventos agrega otro nivel de complejidad, pero también agrega desacoplamiento.
1. Evento: Alex compra un café.
Cajero: (Primer) pedido (para Alex): Café
2. Evento: Alex pide un capuchino.
Cajero: (Segundo) pedido (para Alex): Capuchino
Datos de telemetría, eventos en tiempo real
También hay otros ejemplos que se pueden considerar. Imagínese un escenario como el funcionamiento de un sistema de refrigeración, por ejemplo, para la fabricación de alimentos o medicamentos. Necesita el control constante de la temperatura y de otros datos pertinentes del sistema. Conocer los datos de telemetría y controlarlos automáticamente es fundamental para una operación correcta. La medición de la telemetría cada dos segundos y el envío de esta al sistema de control donde los datos se analizan, procesan y controlan se consideran un sistema controlado por eventos. Además, los datos se deben procesar en tiempo real, ya que es fundamental reaccionar rápidamente para evitar consecuencias trágicas para la empresa.