Cómo construir sistemas distribuidos en TypeScript

Hola, amigos. Así es como se construyen sistemas distribuidos en TypeScript. Mi nombre es Lauren, y escribí un libro sobre GraphQL llamado la Guía de GraphQL, y actualmente trabajo como ingeniera de tiempo de ejecución de lenguaje en Temporal, trabajando en nuestro SDK de TypeScript.

Cuando trabajamos en un monolito, es posible que no tengamos muchas preocupaciones sobre sistemas distribuidos de las que preocuparnos. Si solo tenemos una capa de servidor de aplicaciones y una base de datos que realiza transacciones, es posible que solo estemos recibiendo una solicitud de un usuario, realizando una operación única y, si falla, le decimos a nuestro usuario que lo intente de nuevo. Si estamos hablando con API externas y son una parte esencial de la aplicación comercial como, por ejemplo, hablar con Stripe y decirle que cobre esto, y luego actualizar mi base de datos, entonces tengo algunos problemas más, como que es posible que no pueda comunicarme con Stripe. Así que necesito reintentarlo. Cuando reintentamos, debemos hacerlo de forma idempotente, para no cobrarle al usuario dos veces. Y hay casos en los que mi base de datos puede estar desincronizada con la comprensión de Stripe del mundo. Stripe devuelve éxito y no puedo comunicarme con la base de datos y esa operación falla o mi proceso se detiene antes de llegar a ese paso, entonces mis datos no son consistentes.

En esta charla, trabajaremos en una tienda de comercio electrónico e implementaremos un punto de enlace para crear pedidos. Y repasaremos todos los modos de fallo e intentaremos hacerlo más confiable, y no llegaremos a una confiabilidad total, pero veremos cuánto más simple podemos hacerlo si lo escribimos en temporal. Para comenzar, tenemos una función serverless alojada en Vercel, y obtenemos del cuerpo el ID del artículo, la cantidad y la dirección a la que se envía, y obtenemos el ID del usuario del frasco. Y luego tomamos tres pasos cada vez que tenemos un nuevo pedido. Reservamos el inventario con el servicio de inventario. Luego hablamos con el servicio de pagos para cobrar, y luego hablamos con el servicio de cumplimiento para enviar el paquete. Y respondemos con éxito.

Entonces, en un caso exitoso, esta lógica funciona bien, pero hay varias cosas que pueden salir mal. Si no podemos reservar, entonces no queremos continuar cobrando y enviando paquetes. Si logramos reservar y luego fallamos al cobrar, entonces no solo no queremos enviar el paquete, sino que también queremos cancelar la reserva del inventario para que otra persona pueda comprar esos artículos. Y por último, si la reserva y el cobro son exitosos y recibimos ese mismo paquete, entonces queremos reembolsar el cargo y cancelar la reserva. Ahora, cuando tenemos una falla, enviamos el estado 400 al cliente. Pero idealmente, estaríamos reintentando cada uno de estos pasos en caso de que la falla fuera transitoria, como un error de red o que el servicio estuviera temporalmente inactivo. Pero si lo intentamos nuevamente, tal vez funcione. Así que agreguemos reintentos a cada uno de estos pasos.

Tenemos una función de reintentos que toma parámetros, como intentos máximos y un tiempo de espera en intervalos. Y para cada uno de estos intentos, intenta llamar al servicio, compitiendo entre eso y el tiempo de espera. Entonces, si pasan 30 segundos y no hemos recibido respuesta del servicio, entonces reintentamos. Y cada vez que reintentamos, hacemos un retraso exponencial. Y aquí envolvemos cada una de estas llamadas de servicio en la función de reintentos.

Un problema que tenemos ahora al reintentar es que podríamos tener múltiples llamadas exitosas y necesitamos algún tipo de token de idempotencia para que el servicio sepa que no debe hacer la segunda vez. Y la mejor manera de hacer esto es obtenerlo del cliente. Así que lo agregaremos. Obtendremos un ID de solicitud del cuerpo y lo pasaremos a cada uno de los servicios.

También queremos reintentar estas llamadas fallidas, como si el reembolso falla, entonces ni reembolsaremos ni cancelaremos la reserva. Entonces el cliente terminará con el cargo y se tomará el inventario. Así que agreguemos eso. Envolveremos la cancelación de la reserva con la función de reintentos y también el reembolso. Además, cuando hablamos de lanzar, en realidad no estamos capturando el lanzamiento, solo estamos viendo si el objeto de respuesta tiene una propiedad de falla. Así que también capturaremos estos errores.

Entonces, obtenemos un objeto de reserva si nos comunicamos exitosamente con el servicio. Pero si no pudimos comunicarnos con el servicio, entonces eso lanzará una excepción y la capturamos, la guardamos aquí y luego la enviamos al usuario. Pero ¿qué sucede si este proceso se bloquea? En este punto, con todos estos reintentos, podríamos estar reintentando durante horas y ya no encajamos en la ventana de tiempo de una función sin servidor de Vercel.

Y así, a medida que tenemos estos procesos de larga duración, en algún momento, algunos de ellos fallarán, se bloquearán porque el servidor pierde energía o cualquier otra cosa. Y queremos poder retomar en el mismo estado en el que estábamos para poder continuar procesando el pedido. Y en este momento, la única conciencia de en qué paso estamos está en la memoria de este código.

Entonces, en cada paso, queremos guardar en algún almacenamiento duradero y en un disco en algún lugar en qué estado estamos , qué hemos hecho y qué nos queda por hacer. Así que hagámoslo. Tenemos el cliente de Mongo y los diferentes estados en los que puede estar un pedido. Nos conectamos a la base de datos, insertamos uno en el estado creado, obtenemos el ID y luego usamos eso para actualizar el mismo registro del pedido después de cada estado. Falló la reserva o se reservó, falló el cobro, etc. Hay varios otros problemas que no tenemos tiempo de solucionar. Queremos asegurarnos de que el cliente de la database esté reintentando y queremos manejar los errores de la database y queremos manejar estos errores de lógica de compensación. Y necesitamos tener un grupo de trabajadores.

En este momento, estamos dentro de un controlador HTTP, pero si esto falla, necesitamos que algún otro proceso en algún lugar se dé cuenta de que hay un registro en database en un estado no terminal. La última vez que se actualizó fue hace tanto tiempo que sé que nadie sigue trabajando en él, y el trabajador debe recogerlo y continuar. También probablemente queremos devolverle al usuario antes de que termine esta función porque todo este proceso de reintentos podría llevar minutos u horas.

No tengo tiempo para codificar esto. Probablemente tú tampoco tengas tiempo para codificar esto, y no deberíamos tener que hacerlo. Deberíamos estar trabajando a un nivel de abstracción donde todo lo que hacemos se persista automáticamente y se reintenten y no tengamos que preocuparnos por ello. Desafortunadamente, ese sistema existe y se llama Temporal. Veamos cómo se ve nuestra aplicación en el sistema Temporal. Aquí está la nueva función serverless. Todavía obtenemos los mismos datos. Solo hacemos un paso, y eso es client.start. Esto está utilizando el SDK de Temporal aquí arriba. Estamos iniciando una función de procesamiento de pedidos y le proporcionamos los argumentos del pedido y el ID de la solicitud como una especie de ID de la ejecución de la función y también un token de potencia, y luego respondemos que hemos enviado esto. Si esto ha sucedido, sabemos que se ha iniciado y guardado de forma duradera, y si obtenemos este error de ya iniciado, entonces sabemos que la solicitud era un duplicado. Así que decimos, hey, el pedido del usuario ya ha sido enviado.

Ahora veamos esta función de procesamiento de pedidos. Tenemos cada paso, reserva, cobro. Si el cobro falla, entonces cancelamos la reserva y luego enviamos el paquete, y si eso falla, reembolsamos y luego cancelamos la reserva. Así que eso es muy simple. Esa es toda nuestra lógica y funciona.

Puede que estés pensando, bueno, pero estas funciones de reserva, cobro, etc., deben ser realmente complicadas. Veámoslas. Entonces, estas se llaman actividades, y usamos actividades para cualquier cosa que pueda fallar. Entonces, toda esta lógica no tiene riesgo de falla, pero todo lo que llama sí. Este es el servicio de reserva, cancelación de reserva. Puedes ver que son solo llamadas básicas al servicio. Cada una de estas funciones de actividad se reintenta y se agota el tiempo según mi política de reintento y cualquier opción que coloque aquí, hay muchas opciones diferentes. Todo eso es atendido por el sistema.

Además, cada paso de esta función de procesamiento de pedidos se persiste. Entonces, si el proceso se interrumpe después de esto, un nuevo trabajador continuará la ejecución en el mismo lugar exacto, en el mismo estado exacto y con cualquier variable local. Solo tenemos la variable 'order' aquí arriba, pero podríamos tener muchas otras que cambiamos durante la función. Todas tendrán los mismos valores. También puedes hacer otras cosas geniales como pausar durante 30 minutos. Estamos haciendo la compra de un solo clic de Amazon. Decimos reservar y luego establecemos un temporizador de 30 minutos, y luego cobramos. Y si nos cancelan durante esos 30 minutos, entonces no cobramos ni enviamos el paquete. También podemos pausar durante 30 días en un bucle si estamos intentando cobrar mensualmente a alguien en una suscripción.

Y la forma en que funciona esto es que tenemos un servidor temporal, que es de código abierto, y puedes alojarlo en cualquier lugar. Y eso hace la persistencia. Y tenemos entornos de ejecución de lenguaje o SDKs. Y el SDK se divide en un cliente y un trabajador. Y luego tienes un cliente que se puede usar en cualquier lugar. En este momento lo estamos usando en una función serverless. Y el cliente se comunica con el servidor temporal, y el trabajador se comunica con el servidor. Y el cliente dice, inicia este flujo de trabajo, que es esta función de procesamiento de pedidos.

Y luego los trabajadores están constantemente extrayendo y recogiendo tareas del servidor. Como, ok, inicia esta función, inicia esta actividad, etc. Y el trabajador informa al servidor después de completar cada paso para que el servidor pueda persistirlo.

Entonces, cuando la gente me pregunta, ¿qué es Temporal? Digo que es un marco de ejecución de código duradero. Ejecutamos tu código en nuestros trabajadores y lo hacemos de manera duradera, de modo que si algo sale mal, lo retomamos en el mismo estado exacto. Y así puedes escribir tu código de una manera que sea ajena a las fallas. Eso es Temporal.

Creo que es un gran avance en el desarrollo de software, trabajando a un nivel de abstracción más alto en el que no tienes que preocuparte por la responsabilidad. Si quieres obtener más información, visita temporal.io.ts. Es la documentación del SDK de TypeScript. No dudes en enviarme un correo electrónico a lauren.temporal.io. Contáctame en Twitter, en la cuenta laurenDSR. Además, estamos contratando, así que si quieres trabajar conmigo, avísame.