Descubriendo NodeJS y Kafka: Un Cuento de Transmisión de Eventos

Hola a todos. Espero que esto encaje. Tuvimos algunos desafíos técnicos, pero sigamos adelante. Esta es una charla relámpago. Así que seré muy rápido.

Pasé mucho tiempo, mucho más que la charla, pensando en qué puedo decir en este corto tiempo que les ayude al menos a salir de aquí sintiendo que aprendieron algo, o tal vez que les hice pensar en algo. Mi experiencia está en la computación distribuida. Así que suelo trabajar con empresas en escalado y ayudando a los sistemas a escalar realmente. Big data, he trabajado mucho en eso. Plataformas de streaming, es mi pan de cada día desde hace unos siete años. Y actualmente, vivo en los Países Bajos desde hace siete años, viniendo de Brasil. Y escribo publicaciones técnicas en blogs. Actualmente, escribo en este, pero solía escribir en otros tres o cuatro lugares diferentes. Pero puedes encontrar mis artículos más recientes allí, generalmente hablando sobre Kafka, sobre Kubernetes, principalmente en el backend, en mi caso. Trabajo para Bitvavo. Es el mayor intercambio de criptomonedas en los Países Bajos. Así que si te interesa el mundo de las criptomonedas o quieres adentrarte en él, es tan rápido como hacer clic en un botón como ves ahí. Y ese es el objetivo de la empresa. Realmente queremos brindar la oportunidad de operar con criptomonedas para todos. Y eso es lo que estamos haciendo. Esa es nuestra misión.

Entonces, lo que voy a intentar hablar en este corto tiempo, voy a hablar un poco sobre este mundo en el que vivimos. Muchos de nosotros, estoy seguro de que muchos de ustedes, usan Kafka para compartir eventos entre sistemas. Y esto es un requisito, por supuesto, porque en el mundo actual en el que globalizamos nuestras plataformas y aplicaciones, no podemos depender de la base de datos. Así que realmente necesitamos separar nuestros servicios, ¿verdad?

Y voy a hablar sobre algunos desafíos, errores comunes y patrones que usamos, y soluciones para eso. Esta es una arquitectura de servicios normal. Puedes llamarlo microservicios. Realmente depende de dónde estés, cómo lo hagas. No importa. Lo importante aquí es que tienes múltiples bases de datos, múltiples fuentes de datos. Estás integrando cosas a través de Kafka. Y eso es un patrón común, cada vez más. Apuesto a que muchos de ustedes tienen esto.

Y una forma común de hacerlo, y he visto esto especialmente en el mundo de TypeScript y JavaScript, es enviar eventos usando JSON. Eso es muy fácil porque todo es JSON, pero el problema es que realmente no tienes un contrato, ¿verdad? Si envías eventos a un JSON, los productores, el lado de envío, pueden enviar algo que en realidad está roto, o que otros productores pueden enviar, y el consumidor comienza a procesarlo y se rompe. Y la forma en que funciona Kafka es una cola de eventos. Si no puedes procesar un mensaje, no avanza en el procesamiento de esos mensajes. Y de repente te quedas atascado, y todo tu sistema se detiene porque tienes lo que llamamos una píldora envenenada.

Entonces, ¿cómo evitas eso? En realidad, es bastante simple. Aplicas un patrón llamado cola de mensajes no entregados y utilizas otros esquemas para definir realmente un esquema. Así que es un tipo fuerte.

Ahora tus mensajes deben cumplir en el lado del productor con un sistema de tipificación específico. Así que garantizas que el tipo no se va a equivocar para ese tema específico, y luego tus consumidores no se romperán para ese caso. Y puedes utilizar un enfoque de cola de mensajes no entregados que si comienzas a consumir un mensaje y está roto, en lugar de entrar en ese ciclo para siempre, intentas un par de veces, si no funciona, lo envías a una cola diferente, y pasas al siguiente mensaje. Y para eso es posible que necesites utilizar la confirmación manual de desplazamiento y voy a explicar eso y mostrar algo porque aquí hay un temporizador. Es realmente aterrador. Tengo que ir rápido.

Entonces, piensa en este productor y consumidor estándar, si simplemente usas Kafka.js o cualquier cliente que decidas usar. Los productores normales y los consumidores normales no tienen garantías sólidas. Lo que quiero decir con eso es que no te garantiza que vayas a enviar un solo mensaje en el lado del productor, podría haber duplicados. Es lo que llamamos al menos una vez. Esa es la garantía, lo que significa que puedes tener duplicados. Y en algunos sistemas, no puedes hacer eso. Si estás depositando dinero, no deberías hacer eso. Especialmente al retirar dinero de un cliente, no deberías hacer eso. Y en el lado del cliente, también puedes tener procesamiento duplicado. Esos son los valores predeterminados que obtienes si los usas. Hay soluciones para eso.

Entonces, Kafka ofrece una semántica de exactamente una vez. Eso es lo que significa EOS. Y límites de transacción. Y es muy común que tengas un patrón como ese, en el que tienes un procesador, un mensaje que se inicia como un proceso, quieres consumir el mensaje, hacer algún procesamiento y producir el mensaje en otro tema en una sola transacción. Por lo tanto, quieres asegurarte de que cuando consumas, hagas el procesamiento, algo salga mal. Si vuelves a procesar o reinicias tu sistema, procesas ese mensaje nuevamente, porque no finalizaste esos tres pasos, que es enviar ese mensaje al siguiente paso. Y para esto, debes hacer alguna configuración en Kafka.

Desde el lado del productor, debes establecer la idempotencia en verdadero. Eso garantiza que no se duplique y se envíe. Y en el lado del consumidor, debes deshabilitar la confirmación automática del desplazamiento, lo que significa que tu cliente lee el mensaje, pero ahora tienes el control. Cuando quieras decirle a Kafka que realmente procesaste este mensaje, confirmas el desplazamiento. Y también quieres establecer una propiedad llamada max in-flight request en uno, para que no haya procesamiento paralelo y puedas mantener las garantías de ordenamiento. Y en el lado del productor, en el último paso, recuerda, es consumir y luego producir, y quieres que todo esto esté en la misma transacción. Lo que quieres establecer es un ID de transacción, para que el broker pueda establecer los límites de transacción y decir que el punto es verdadero también. Y lo que esto garantiza es que cuando consumes, procesas y envías, es parte de una única transacción atómica. El cliente de Kafka, esto no es una transacción distribuida, como una transacción XA. No está garantizado que si haces una llamada a la base de datos en el lado que se revierta. Debes encargarte de eso. Está en los límites de Kafka. Es lo mismo que tu transacción normal de base de datos entre dos tablas a las que estás acostumbrado, así que ten eso en cuenta.

Algunas configuraciones del clúster, y también he terminado porque mi reloj ya está parpadeando. Debes tener al menos tres particiones y al menos dos réplicas en sincronización para tus temas para que esto funcione. Por lo tanto, si lo intentas localmente y no lo tienes, no funcionará, y también debes iniciar la transacción como puedes ver, iniciar una transacción, enviar un mensaje, enviar los desplazamientos y luego confirmar las transacciones, lo que significa que todo va a suceder o se revertirá. Y eso es básicamente lo que quieres hacer, y es realmente importante tener eso en cuenta. Eso es todo. Si quieres saber más sobre esto, escribo en esta publicación de blog específica sobre esto, y también tengo un archivo docker-compose donde tengo múltiples nodos de Kafka donde puedes probar este tipo de trabajo más avanzado en tu máquina local. Muchas gracias.