Cuando creas que los microservicios son un poco "voluminosos", prueba esta vieja saga amiga

Crear microservicios es como construir bloques. Es hermoso que cada módulo funcione de forma independiente. Pero una vez que se involucra el procesamiento de transacciones entre servicios, la hermosa imagen puede fácilmente romperse en pedazos: se crea el pedido pero no se deduce el inventario, el pago se realiza correctamente pero la logística no se activa, es posible que haya encontrado cosas tan malas.

¿Por qué las transacciones distribuidas siempre causan dolores de cabeza?

Imagínese esto: compra un libro en línea y, después de hacer clic para pagar, el sistema le indica que se ha realizado correctamente. Unos días después recibí un correo electrónico que decía "Pedido cancelado por falta de inventario", pero el dinero ya había sido descontado. Este no es un escenario ficticio, sino un problema típico de inconsistencia de datos en sistemas distribuidos. Las transacciones de bases de datos tradicionales funcionan bien en una sola aplicación, pero después de dividirse en microservicios, cada servicio usa su propia base de datos y las transacciones ACID no pueden cruzar los límites de la red.

Entonces, algunas personas intentaron el compromiso de dos fases (2PC), pero los cuellos de botella en el rendimiento y los problemas de bloqueo de sincronización desanimaron a muchos equipos. Especialmente en escenarios de alta concurrencia, el coordinador se convierte en un único punto de falla y la disponibilidad general del sistema disminuye. Es como pedirle a un director que coordine la actuación de diez orquestas al mismo tiempo. Si el ritmo está ligeramente desalineado, toda la pieza se estropeará.

Patrón de diseño de saga: cambia tu forma de pensar y coordina acciones

La idea central de Saga es bastante simple: dividir una transacción larga en una serie de transacciones locales y activar la siguiente después de que se complete cada transacción. Si falla un paso intermedio, se realizan una serie de operaciones de compensación para revertir el impacto anterior. No persigue la atomicidad, pero garantiza una eventual coherencia.

¿Suena un poco abstracto? Tomemos un ejemplo de la vida real: organizas una gira de conferencias por varias ciudades. El enfoque tradicional es esperar hasta que se confirmen todos los lugares antes de anunciar el itinerario, pero esto puede perder el mejor período de publicidad. La idea de Saga es finalizar el primer lugar primero, luego reservar el segundo lugar y luego el tercer lugar... Si hay un problema temporal con un lugar determinado de la ciudad, el lugar siguiente programado se cancelará y se coordinará un plan alternativo. Es posible que todo el proceso no esté completamente sincronizado, pero en última instancia hará que la gira se realice.

Varias formas de implementar Saga en microservicios Java

Una saga orquestada es como un director que cuenta la historia: hay un coordinador central (generalmente llamado orquestador) que le dice a cada servicio qué hacer y cuándo hacerlo. Los servicios no se comunican directamente entre sí, sólo hablan con el coordinador. Este enfoque está lógicamente centralizado y es fácil de entender y depurar, pero el coordinador puede convertirse fácilmente en un cuello de botella. Es adecuado para escenarios con pocos pasos de transacción y procesos estables.

Una saga de conciertos se parece más a una improvisación de jazz: después de que cada servicio completa su tarea, publica un evento para notificar al siguiente servicio. No existe un comando central y los servicios se basan en eventos. Esta solución tiene buena escalabilidad y bajo acoplamiento de servicios, pero es laborioso rastrear todo el flujo de transacciones y depurar cuando ocurre un error es como resolver un rompecabezas.

¿Cuál elegir? Si su equipo es bueno en arquitectura basada en eventos y los pasos de las transacciones cambian con frecuencia, Concerto es más flexible. Si busca la controlabilidad y observabilidad del proceso, la orquestación puede ser más conveniente. No existe ninguna ventaja o desventaja absoluta, solo coincidencia de escenas.

¿Por qué el sistema es más "duro" después de usar Saga?

El cambio más intuitivo después de adoptar el modo Saga es que aumenta el rendimiento del sistema; debido a que los servicios ya no esperan a la sincronización, la utilización de recursos aumenta naturalmente. Más importante aún, hace que el sistema sea "resistente": la indisponibilidad temporal de un determinado servicio no provocará que toda la transacción se bloquee y el mecanismo de compensación deja espacio para la reparación y el reintento.

Existe un caso práctico: durante un período de promoción, una plataforma de comercio electrónico experimentó una presión excesiva en el servicio de pedidos y ralentizó su respuesta. En el modo de transacción tradicional, los servicios de pago e inventario esperarán la respuesta del servicio de pedidos simultáneamente, lo que provocará que el pago del usuario expire y falle. Después de cambiar a la implementación de Saga, el retraso en el servicio del pedido solo afecta su propio proceso de compensación. Los servicios de pago e inventario aún se pueden procesar de forma asincrónica y la tasa de éxito del pago del usuario es mucho mayor.

¿Cómo es una implementación útil de Saga?

Una implementación de Saga bien diseñada suele tener varias características: las operaciones de compensación son idempotentes (la ejecución repetida tiene el mismo efecto), el estado de la transacción es rastreable y los tiempos de espera y los mecanismos de reintento son razonables. Estos parecen detalles técnicos, pero afectan directamente la experiencia de desarrollo.

kpotenciaAl abordar tales requisitos, descubrimos que muchos equipos estaban estancados en el diseño de la lógica de compensación. Por ejemplo, la compensación por "reducir inventario" es "restaurar inventario", pero el tiempo de espera de la red puede hacer que se repita la operación de compensación. Si simplemente ejecuta "Inventario +1", las compensaciones múltiples causarán confusión en los datos. Por lo tanto, en su solución, la operación de compensación comprobará si el ID de la transacción original se ha procesado para evitar una acumulación repetida.

¿Cuándo deberías considerar presentar una saga?

Si descubre que su equipo pasa mucho tiempo lidiando con una limpieza de datos "parcialmente exitosa", o que todo el enlace está bloqueado porque un servicio no funciona, es hora de echarle un vistazo a Saga. Especialmente cuando el negocio implica un procesamiento asincrónico de varios pasos (por ejemplo, la compra de un curso en línea implica la selección del curso, el pago, la activación de permisos y el envío de notificaciones), estos pasos son naturalmente adecuados para la coordinación de Saga.

Al comenzar la implementación, se recomienda realizar una prueba piloto a pequeña escala y seleccionar un proceso no central pero típico para transformar primero. Registre la tasa de error, el tiempo de finalización de la transacción y los cambios en los costos de desarrollo y depuración antes y después de la transformación. Los datos le dirán si vale la pena promocionarlo.

Posibles trampas y desvíos

Saga no es una solución milagrosa. Las operaciones de compensación mal diseñadas pueden causar "daños secundarios", como reembolsos y deducciones repetidas. Los eventos fuera de orden pueden generar estados inconsistentes; por ejemplo, el evento de "cancelación de pedido" llega antes que el evento de "creación de pedido". Estos temas deben diseñarse cuidadosamente en conjunto con la empresa.

Una estrategia práctica es agregar un número de versión o marca de tiempo a cada paso de la transacción y verificar el pedido cuando el servicio posterior lo procesa. Se recomienda configurar un panel de monitoreo de Saga para mostrar las transacciones en curso y el estado anormal en tiempo real para facilitar una intervención rápida. Después de todo, no importa cuán buena sea la automatización, todavía requiere trabajo manual.

escrito en

Los sistemas distribuidos son como varias personas que colaboran para completar tareas manuales: la sincronización completa es ineficiente y la asincronía completa es propensa al caos. Saga encuentra ese término medio: dejar que todos los involucrados trabajen a su propio ritmo y al mismo tiempo garantizar que el producto final esté completo. No es perfecto, pero hace falta que muchos proyectos de microservicios pasen de "apenas ejecutarse" a "colaboración fluida".

La próxima vez que le dé dolor de cabeza la coherencia de los datos entre servicios, también podría echar un vistazo a las transacciones. Quizás esos flujos de negocios aparentemente complejos simplemente necesiten conectarse de otra manera.

Establecido en 2005,kpotenciase ha dedicado a un fabricante profesional de unidades de movimiento compacto, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en la tecnología de accionamiento modular,kpotenciaintegra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas. Kpower ha brindado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.