Desbloqueando el Potencial de Aplicaciones en Tiempo Real Basadas en Eventos con JavaScript

Hola, mi nombre es Jerdot, y soy un líder técnico en AWS Safegate trabajando en el software de control de Apron que aumenta el rendimiento, la seguridad y la sostenibilidad de los aeropuertos. Hoy voy a hablar sobre la arquitectura dirigida por eventos y algunos de los potenciales de tener sistemas en tiempo real dirigidos por eventos y JavaScript.

Fuera de mi trabajo en AWS Safegate, soy estadounidense, pero me mudé a Suecia hace cuatro años. Mi experiencia es principalmente en sistemas embebidos y desarrollo web. Y fuera de trabajar con computadoras, me gusta la producción musical, jugar a juegos de computadora, y jugar al golf.

Tenemos una agenda completa para hoy, y comenzaremos desde cero con algunos componentes en tiempo real de JavaScript, una pequeña introducción al bucle de eventos de JavaScript, una breve visión general de la arquitectura dirigida por eventos, emisores de eventos, WebSockets, RabbitMQ, MQTT, y luego qué significa llevar todas estas cosas a producción. Comencemos.

Entonces JavaScript. Mucha gente piensa muchas cosas diferentes, que no es bloqueante, y que es async I.O., pero esa no es la naturaleza del JavaScript real. Como lenguaje, es en realidad sincrónico, bloqueante y de un solo hilo. Pero hay diferentes entornos de ejecución que nos permiten hacer cosas asincrónicas que tienen un rendimiento variado en JavaScript, tanto en el navegador como en el servidor.

Hoy me centraré principalmente en Node.js, pero la mayoría de los entornos de ejecución tienen el mismo tipo de herramientas con diferentes nombres y comportamientos ligeramente diferentes. Algunos de los componentes de tiempo de ejecución en Node son el motor V8, LibUV, Crypto. Hay muchas características integradas en C++ para ayudarte a acceder a sistemas de archivos y redes. Y también hay esta amplia biblioteca de JavaScript que te permite usar características de C++ directamente desde JavaScript.

Así que cuando miro Node.js, se ve algo así. Y durante el tiempo de ejecución, tenemos una configuración bastante simple. Tenemos una Memory Deep, donde tenemos todas nuestras variables y funciones declaradas, todo sucediendo allí, y tenemos nuestra pila de llamadas. Las funciones en cola se empujan a la pila de llamadas, y cuando una función devuelve, se saca de la pila de llamadas. Esto es bastante simple, una cola de último en entrar, primero en salir. Veremos algunos ejemplos cortos. Tenemos un código realmente, realmente complicado aquí en la parte superior izquierda. A la derecha, tenemos nuestro tiempo de ejecución, y en la parte inferior izquierda, tenemos una salida de consola. Si comenzamos a recorrer este código, veremos que la primera función entra en la pila de llamadas. Esto se ejecuta, y obtenemos los resultados en la consola. Lo mismo con la segunda declaración. Obtenemos la salida en la consola, y la tercera declaración en la consola. Y nada allí parece extraño, ¿verdad? Lo ejecutamos en orden. Este es un script sincrónico.

¿Qué pasa si intentamos hacer algo asincrónico? Obtenemos nuestra primera declaración de registro de consola, y obtenemos la salida. Tenemos esta declaración de lectura de archivo. Y aquí es donde se pone un poco interesante, es que esto en realidad será empujado a libuv. Y continuaremos con nuestro código sincrónico. Así que iremos primero, y luego tercero. Y luego, después de un tiempo, cuando terminemos de leer nuestro archivo, procesaremos la función de devolución de llamada de esa función de lectura de archivo. Así que terminamos con una salida que fue primero, tercero y segundo. Y podríamos preguntarnos, ya sabes, ¿por qué es eso? Y esto es un poco lo que hace el bucle de eventos.

Y el bucle de eventos es esencialmente solo un patrón de diseño que orquesta la ejecución de código sincrónico y asincrónico. Siempre está ejecutándose en segundo plano de tu proceso de Node.js. Es importante saber que todo tu código sincrónico se ejecuta primero, y realmente no es parte del bucle de eventos.

Echaremos un vistazo un poco más profundo al bucle de eventos. Es un dibujo muy, muy bonito aquí. Puede ser un poco complicado si no lo has visto antes. Pero hay esencialmente seis colas diferentes en cada iteración del bucle de eventos. Y contienen funciones de devolución de llamada que eventualmente se ejecutan en la pila de llamadas normal cuando están listas.

Siempre comenzamos en el medio con una cola de microtareas. Esta contiene dos subcolas, la cola de nextTick y la cola de devolución de llamada de promise. Y cada una de estas subcolas, ejecutamos todas las funciones de processNextTick hasta que estén vacías. Y luego continuamos con todas las funciones nativas de promise hasta que esté vacía. Una vez que hemos procesado ambas subcolas, pasamos a la cola de temporizadores, típicamente conocida como el espacio de temporizadores. Esto ejecuta todas las devoluciones de llamada asociadas con setTimeouts y setEnderable. Y una vez que esa cola está completamente vacía, volvemos al medio, y nuevamente procesamos todas las devoluciones de llamada de nextTick y promise en orden. Podrías empezar a captar la idea. Nos movemos en el sentido de las agujas del reloj alrededor del bucle exterior, y después de cada iteración, volvemos al medio y procesamos las devoluciones de llamada de nextTick y promise.

La cola de IO maneja todos nuestros métodos asíncronos de módulos como FS y HTTP. Procesamos todo esto, y volvemos a la cola de microtareas, y luego continuamos a la cola de verificación donde manejamos todas las devoluciones de llamada asociadas con setImmediate. Una vez más volvemos a la cola de microtareas, procesamos todos nuestros nextTick y promesas, y luego entramos en nuestra fase de cierre. Esto maneja todas las devoluciones de llamada asociadas con el evento close en la tarea asíncrona. En el último paso del bucle, volvemos y una vez más verificamos todos nuestros nextTick y promesas. Y si hay algo aquí, en realidad haremos todo otro ciclo como parte de este bucle de eventos. Pero si la cola de microtareas está completamente vacía, el bucle de eventos técnicamente saldrá.

Espero que esto te haya dado una mejor comprensión de cómo se están implementando y ejecutando estas cosas, y por qué las promesas son realmente tan poderosas dentro de async dash JavaScript.

Ahora que tenemos una comprensión básica de cómo funciona async dash JavaScript, podemos hablar un poco más sobre la arquitectura dirigida por eventos. Esta es solo una definición, y se trata de producir, detectar, consumir y reaccionar a eventos. Está un poco en el nombre, dirigida por eventos. Algunos términos clave a considerar son qué es un evento, y esto es esencialmente solo un cambio de estado dentro de tu aplicación, y es cualquier ocurrencia o acción que pueda desencadenar una respuesta. No siempre es una respuesta a un evento, pero probablemente siempre sea un evento.

Los productores son las cosas que generan los eventos. Los consumidores escuchan y reaccionan a los eventos. Los canales son vías a través de las cuales se transmiten los eventos. Y los procesadores son componentes que manejan la lógica en respuesta a los eventos. Algunos conceptos clave para entender sobre la arquitectura dirigida por eventos es que si algo en tu aplicación cambia, siempre debes generar un evento, ya sea que vaya a ser consumido o no. Los productores envían eventos después de que han ocurrido, no antes, y al productor no le importa lo que sucede después de que se envía el evento. El único trabajo del productor es propagar el cambio al sistema, y no le importa lo que realmente sucede después de eso. No debes diseñar eventos para consumidores particulares ni contener instrucciones específicas porque los eventos son inmutables. Y así, cuando comienzas a construir el sistema, terminas con algo de alto nivel como esto, donde tienes productores que van a algún tipo de middleware de eventos, y luego tienes consumidores en el otro lado que están manejando eventos y tal vez desencadenando nuevos eventos y convirtiéndose en productores ellos mismos, y tienes este tipo de ciclo.

Algunos de los casos de uso para la arquitectura dirigida por eventos son los microservicios. Puede que ya estés haciendo algunas cosas dirigidas por eventos sin siquiera darte cuenta. Los patrones EDA son perfectos para habilitar la comunicación entre diferentes servicios. En lugar de tener puntos a OIDs, puedes distribuir todo. Los sistemas IoT utilizan en gran medida los patrones EDA para manejar datos de numerosos sensores y dispositivos, y muchos sistemas que requieren procesamiento de datos en tiempo real, como el comercio financiero, también utilizan patrones EDA. Para nosotros, proporcionamos una solución que tiene una vista en tiempo real de lo que está sucediendo en el aeropuerto, características como la visualización de todas las aeronaves y vehículos moviéndose en el suelo, controlando, monitoreando y visualizando miles de sensores. Así que nuestra aplicación es a veces un gran lío dirigido por eventos. A través de mi experiencia trabajando en esto, hay muchos pros y contras.

Algunas de las ventajas son el desacoplamiento de componentes. Tus productores y consumidores no necesitan conocerse entre sí. Esto te da mucha flexibilidad ya que puedes añadir nuevos consumidores y servicios sin necesariamente cambiar los datos de los productores, y esto te permite escalar. Puedes añadir nuevos componentes o eliminarlos sin afectar a otros y te permite habilitar algún procesamiento en tiempo real.

Algunos de los inconvenientes. La consistencia de datos puede ser bastante difícil. Al enviar eventos a múltiples consumidores, puede ser realmente desafiante asegurar que todo se procese, especialmente si hay alguna ralentización en un servicio o fallos transitorios. La complejidad también es bastante difícil, especialmente a medida que crece el número de eventos y consumidores. Esto hace que la depuración sea más desafiante debido a la naturaleza asincrónica. Y el orden de los eventos también puede ser bastante complejo si necesitas un orden específico de tus eventos a medida que ocurren.

Así que ahora que hablamos de esto, hablaremos de un par de herramientas y cosas alrededor de EDA que hacen que construir aplicaciones de producción sea mucho más fácil. La primera son los event emitters, que es una biblioteca nativa dentro de JavaScript, y nos centraremos en tres funciones principales. Emits, que te permite emitir un evento. On que te permite escuchar cambios en un cierto evento, y off, que te permite dejar de escuchar cambios en un cierto evento.

Así que si miramos este dibujo simple aquí, tenemos el event emitter A, que emite dos eventos diferentes, uno de tipo X y otro de tipo Y. Y en eventos de tipo X, tenemos dos oyentes que están escuchando cambios para el método X. Y tenemos un oyente C, que está escuchando eventos de tipo Y. Esto es realmente útil para desacoplar diferentes partes de tu aplicación.

Puedes emitir eventos desde una parte de tu aplicación, escucharlos en otras partes. Puedes implementar un manejo de errores robusto escuchando específicamente eventos de error. Y también puedes aprovechar esto para manejar operaciones asíncronas emitiendo eventos cuando las tareas asíncronas se completan. Esto es realmente útil para la comunicación de procesos internos, pero no se expande realmente fuera de un solo proceso.

Para cosas como esa, podrías pensar en WebSockets, que proporcionan una comunicación de dúplex completo sobre una única conexión de larga duración. Esto es mucho mejor en comparación con los ciclos tradicionales de solicitud-respuesta HTTP. Tiene un costo mucho menor en la red y también en su tiempo. Y esto también permite a los servidores enviar actualizaciones directamente a los clientes para que tengan comunicación en tiempo real.

Así que en lugar de decir, oye, dame algunos vuelos, estoy esperando que el servidor responda con 200 OK y tus datos, o tal vez incluso un 500, dependiendo de cómo vayan las cosas. Puedes simplemente obtener los nuevos Sockets, realizar el handshake, y luego tienes esta comunicación bidireccional entre tu cliente y servidor. Y en JavaScript, están disponibles de forma nativa en la biblioteca WebSocket. Pero también hay un paquete NPM popular llamado Socket.io.

Y esto proporciona métodos como onOpen, onMessage, onAir, onClose. Y esto sigue de cerca otros patrones dirigidos por eventos en paquetes.

Una cosa a tener en cuenta es que la gestión de conexiones es súper importante para asegurar que tu aplicación se comporte bien si su conexión se cae o el servicio se reinicia. Esto es algo que tienes que hacer por tu cuenta.

Otra muy buena opción para propagar eventos dentro de tu sistema es RabbitMQ. RabbitMQ es un broker de mensajes de código abierto, por lo que se encarga de enviar mensajes entre diferentes servicios, productores y consumidores. Tiene soporte para muchos protocolos diferentes, pero el principal que se suele usar es MQP. Y esto permite un enrutamiento de mensajes confiable, flexible y escalable.

Algunos términos clave que debes conocer sobre RabbitMQ, si empiezas a investigarlo o alguien te habla sobre su conexión, es una conexión TCP usando el protocolo MTP. Un canal, que es una conexión virtual multiplexada dentro de MQP. Así es como realizas diferentes acciones y puedes tener comunicación multiplexada a través del único socket TCP. Colas, que son componentes básicos para almacenar y gestionar mensajes específicos, e intercambios, que son como un agente de enrutamiento que te permite poner mensajes en una o más colas.

Hay un par de patrones bien conocidos en RabbitMQ. El primero sería publicar y suscribir. Esto encaja muy bien en la arquitectura de administración. Podemos tener un publicador en el lado izquierdo que publica en un intercambio, que es solo un agente de mensajería que te permite enrutar mensajes a diferentes personas. Y los consumidores pueden vincular sus propias colas a este intercambio. Así que cada consumidor que vemos en el lado derecho, consumidor A, consumidor B y consumidor C, puede realmente consumir actualizaciones de este publicador a su propio ritmo y manejarlas a su manera. Así que esto es realmente, realmente poderoso dentro de RabbitMQ. Es una propagación de cambios.

Otra cosa que podrías mirar son las llamadas a procedimientos remotos, donde el servicio A necesita enviar una instrucción al servicio B. En este caso, el servicio B instancia una cola de comandos. El servicio A interactúa con esta cola de comandos enviando un ID de correlación para el mensaje y una cola de respuesta, que es una cola a la que el servicio A debe intentar. Así que cuando el servicio A envía el comando al servicio B o a esta cola de comandos, el servicio B lo procesa y envía la respuesta con el ID de correlación en esta cola de respuesta proporcionada de vuelta al servicio A.

Cuando miramos la combinación de estas cosas dentro de tus microservicios, verás muchas cosas como esta, donde tienes intercambios yendo en cualquier dirección. Tienes este intercambio que está siendo expuesto por el servicio A, donde el cliente A está suscrito a él, y también tienes colas de comandos donde el cliente A puede decir, edita, dame todos los datos de las últimas 24 horas. No es suficiente que solo obtenga las actualizaciones en tiempo real.

Otro broker realmente bueno, que es más ligero, sería MQTT. Esto básicamente es solo un protocolo de mensajería, así que no lo confundas con los brokers en sí mismos. Esto se usa comúnmente en aplicaciones IoT, donde tienes como un ancho de banda bajo o redes poco fiables, o tal vez hay ahorro de energía con tus baterías, no quieres tener una conexión consistente. Y esto opera en un modelo básico de publicación-suscripción, que te permite desacoplar tus productores y consumidores. Algunas de las cosas que escucharás al discutir MQTT son temas, que es solo una cadena jerárquica que actúa como un mecanismo de enrutamiento.

Así que esta es una especie de clave. Tienes publicadores, estas son las personas que envían mensajes al broker, y suscriptores, y ellos leen mensajes del broker. O más bien, el broker envía mensajes al suscriptor. También es importante saber que MQTT tiene una configuración de calidad de servicio realmente buena. Hay tres diferentes, y en el nivel cero, el mensaje se entrega como máximo una vez, y la pérdida es aceptable. En el nivel de calidad de servicio uno, el mensaje se entrega al menos una vez, pero pueden ocurrir duplicados y en el nivel dos, se entrega exactamente una vez y no debería haber duplicados.

Si miramos un ejemplo de cómo se comportan realmente los brokers MQTT, podemos ver en el lado izquierdo tenemos dos publicadores y podemos ver los datos que están publicando y el tema al que están publicando. Así que cuando publican esto, cualquier cliente que esté suscrito a ese tema recibirá automáticamente una actualización. Así que en este caso, el suscriptor en la parte superior derecha está suscrito al tema estado de la pista. Y tan pronto como el publicador en la parte superior izquierda publique un nuevo valor, será automáticamente recibido por el cliente en la parte superior derecha. Así que esto es realmente, realmente agradable. Ahora, si conectamos todas esas cosas de las que hablamos, ya sabes, RabbitMQ, MQTT, event emitters, WebSockets, obtendrás algo como esto, que es solo una cosa hipotética. No es un dibujo de uno de nuestros servicios, pero en el lado izquierdo, tenemos un radar que alimenta un servicio de radar a través de TCP. Y eso puede ser realmente, realmente difícil de distribuir a través de un sistema. Así que tenemos que meter eso en RabbitMQ mediante un intercambio donde podemos tener múltiples servicios como el Servicio A y el Servicio B que están suscritos a estos datos. El Servicio A podría enviar estos datos a otro lugar y el Servicio B está tomando otros datos y el Servicio B crea su propio tipo de intercambio que va a otro servicio y ese servicio está tomando datos de MQTT, y luego lo republicamos, y luego podemos obtenerlo en un WebSocket para enviarlo a otro lugar. Parece realmente complicado, pero de esta manera, podemos desacoplar nuestros servicios y poner mucha de la lógica dentro del middleware. Esto hace que tu código sea extremadamente limpio. Pero como hablamos antes, una de las desventajas con EDA es la complejidad.

Continuando, hay algunas cosas realmente buenas que saber sobre el rendimiento y hacer las cosas correctas con sistemas que están configurados de esta manera. La forma normal que puedes recomendar es usar brokers de mensajes bien conocidos y de alto rendimiento como RabbitMQ o Apache Kafka. Podrías querer investigar diferentes formatos de serialización como Protobuf. Desplegar productores y brokers y todas tus aplicaciones cerca unas de otras en el mismo centro de datos, misma zona de disponibilidad también ayudará mucho. Desplegar manejadores, como vimos antes, JavaScript maneja cosas asíncronas realmente bien, e incluso procesa eventos y lotes si es apropiado. Pero el rendimiento solo llega hasta cierto punto si tu aplicación es inestable. También necesitas pensar en la tolerancia a fallos. Cuantos más datos tengas circulando dentro de tu aplicación, más difícil es hacerla de alta calidad. Siempre ejecuta tu broker en un clúster y asegúrate de que tus datos se consideren replicados. Cancelamos la pérdida de datos de reenvío. Asegúrate de que tus eventos estén almacenados de manera segura.

La mayoría de los brokers puedes configurarlos para que el mensaje se almacene en memoria hasta que el consumidor lo procese con éxito. Desde el lado del consumidor, siempre debes poder manejar los mismos eventos múltiples veces con efectos secundarios no deseados como la idempotencia. Y tener estos reintentos automáticos para fallos transitorios con retrocesos exponenciales. Así que reintenta cinco veces en diferentes intervalos, y si eso no funciona, deberías enviarlo a lo que se llama una cola de letras muertas para que puedas analizarlo más tarde.

Básicamente cualquier mensaje que puedas procesar, envíalo allí, y luego puedes leer los registros y averiguar qué sucedió. Y algunos consejos generales para construir sistemas como este es tener un buen monitoreo y alertas para mantener un seguimiento de la salud y el rendimiento de tu sistema y practicar la ingeniería del caos probando regularmente cómo se comporta tu sistema inyectando mensajes defectuosos intencionalmente. Otra cosa que es realmente agradable es documentar muy bien tus productores y consumidores. Si piensas en mi pequeño ejemplo de antes, puede ser un poco confuso y hay la diferencia entre complejo y complicado.

Complejo significa que puedes rastrear a través de alguna documentación y averiguar cómo está funcionando incluso si hay muchas cosas. Pero complicado significa que es realmente difícil encontrar el camino correcto al sistema. Así que enfócate en construir una complejidad simple en lugar de hacer las cosas complicadas. Para concluir, EDI se trata de escalabilidad, flexibilidad y habilitar el procesamiento en tiempo real. RabbitMQ es un broker realmente agradable, de código abierto, gratuito para usar, que soporta varios patrones de mensajería en enrutamiento complejo. MQTT es un broker súper ligero con modelo de publicación y suscripción que te permite tener entrega de mensajes confiable en entornos restringidos. Gracias.