El patrón de diseño Saga ayuda a mantener la coherencia de los datos en sistemas distribuidos mediante la coordinación de transacciones entre varios servicios. Una saga es una secuencia de transacciones locales donde cada servicio realiza su operación e inicia el siguiente paso a través de eventos o mensajes. Si se produce un error en un paso de la secuencia, la saga ejecuta transacciones de compensación para deshacer los pasos completados, manteniendo la coherencia de los datos.
Contexto y problema
Una transacción representa una unidad de trabajo, que puede incluir varias operaciones. Dentro de una transacción, un evento hace referencia a un cambio de estado que afecta a una entidad. Un comando encapsula toda la información necesaria para realizar una acción o desencadenar un evento posterior.
Las transacciones deben cumplir los principios de atomicidad, coherencia, aislamiento y durabilidad (ACID).
- atomicidad: todas las operaciones se realizan correctamente o ninguna.
- de coherencia: los datos pasan de un estado válido a otro.
- Aislamiento: las transacciones simultáneas producen los mismos resultados que los secuenciales.
- durabilidad: una vez confirmados, los cambios se conservan incluso en errores.
En un único servicio, las transacciones siguen los principios ACID porque funcionan dentro de una base de datos única. Sin embargo, lograr el cumplimiento acid en varios servicios es más complejo.
Desafíos en las arquitecturas de microservicios
Las arquitecturas de microservicios suelen asignar una base de datos dedicada a cada microservicio, que ofrece varias ventajas:
- Cada servicio encapsula sus propios datos.
- Cada servicio puede usar la tecnología de base de datos y el esquema más adecuados para sus necesidades específicas.
- Escalado independiente de bases de datos para cada servicio.
- Los errores de un servicio están aislados de otros.
A pesar de estas ventajas, esta arquitectura complica la coherencia de los datos entre servicios. Las garantías de base de datos tradicionales, como ACID, no se aplican directamente a varios almacenes de datos administrados de forma independiente. Debido a estas limitaciones, las arquitecturas que se basan en la comunicación entre procesos (IPC) o los modelos de transacción tradicionales, como el protocolo de confirmación en dos fases (2PC), suelen ser más adecuados para el patrón Saga.
Solución
El patrón Saga administra las transacciones dividiéndolas en una secuencia de transacciones locales (ver la figura 1).
Figura 1. Una saga con tres servicios.
Cada transacción local:
- Completa su trabajo de forma atómica dentro de un único servicio.
- Actualiza la base de datos del servicio.
- Inicia la siguiente transacción a través de un evento o mensaje.
- Si se produce un error en una transacción local, la saga ejecuta una serie de transacciones de compensación para invertir los cambios realizados por las transacciones locales anteriores.
Conceptos clave en el patrón Saga
transacciones compensables: transacciones que otras transacciones pueden deshacer o compensar con el efecto opuesto. Si se produce un error en un paso de la saga, las transacciones compensatorias deshacen los cambios realizados en las transacciones compensables.
de transacción dinámica: la transacción dinámica actúa como el "punto sin retorno" en la saga. Una vez que la transacción dinámica se realiza correctamente, las transacciones compensables (que podrían deshacerse) ya no son pertinentes. Todas las acciones posteriores deben completarse para que el sistema logre un estado final coherente. Una transacción dinámica puede caer en diferentes roles en función del flujo de la saga:
irreversible (no compatible): no se puede deshacer ni reintentar.
límite entrereversibles y confirmadas: puede ser la última transacción irredable (compensable) o puede ser la primera operación reintentos de la saga.
transacciones reintentos: estas transacciones siguen la transacción dinámica. Las transacciones reintentos son idempotentes y garantizan que la saga pueda alcanzar su estado final, incluso si se producen errores temporales. Garantiza que la saga logra un estado coherente finalmente.
Enfoques de implementación de Saga
Hay dos enfoques comunes de implementación de sagas, coreografía y orquestación. Cada enfoque tiene su propio conjunto de desafíos y tecnologías para coordinar el flujo de trabajo.
Coreografía
En la coreografía, los servicios intercambian eventos sin un controlador centralizado. Con la coreografía, cada transacción local publica eventos de dominio que desencadenan transacciones locales en otros servicios (ver la figura 2).
Figura 2. Una saga que usa coreografía.
| Ventajas de la coreografía | desventajas de la coreografía |
|---|---|
| Adecuado para flujos de trabajo sencillos con pocos servicios y no necesita una lógica de coordinación. | El flujo de trabajo puede resultar confuso al agregar nuevos pasos. Es difícil realizar un seguimiento de qué participantes de saga escuchan qué comandos. |
| No se requiere ningún otro servicio para la coordinación. | Existe un riesgo de dependencia cíclica entre los participantes de la saga porque tienen que consumir los comandos entre sí. |
| No introduce un único punto de error, ya que las responsabilidades se distribuyen entre los participantes de la saga. | Las pruebas de integración son difíciles porque todos los servicios deben ejecutarse para simular una transacción. |
Orquestación
En la orquestación, un controlador centralizado (orquestador) controla todas las transacciones e indica a los participantes qué operación realizar en función de los eventos. El orquestador ejecuta solicitudes saga, almacena e interpreta los estados de cada tarea y controla la recuperación de errores con transacciones compensatorias (vea la figura 3).
Figura 3. Una saga que usa orquestación.
| ventajas de la orquestación | desventajas de la de orquestación |
|---|---|
| Más adecuado para flujos de trabajo complejos o al agregar nuevos servicios. | Otra complejidad de diseño requiere una implementación de una lógica de coordinación. |
| Evita las dependencias cíclicas, ya que el orquestador administra el flujo. | Presenta un punto de error porque el orquestador administra el flujo de trabajo completo. |
| La separación clara de responsabilidades simplifica la lógica del servicio. |
Problemas y consideraciones
Tenga en cuenta los siguientes puntos al implementar el patrón Saga:
Cambio en el pensamiento de diseño: la adopción del patrón Saga requiere una mentalidad diferente, centrándose en coordinar transacciones y garantizar la coherencia de los datos en varios microservicios.
Complejidad de las sagas de depuración: las sagas de depuración pueden ser complejas, especialmente a medida que crece el número de servicios participantes.
cambios irreversibles en la base de datos local: los datos no se pueden revertir porque los participantes de saga confirman cambios en sus respectivas bases de datos.
Control de errores transitorios e idempotencia: el sistema debe controlar los errores transitorios de forma eficaz y garantizar la idempotencia, donde la repetición de la misma operación no modifica el resultado. Para obtener más información, vea procesamiento de mensajes idempotentes.
Necesidad de supervisión y seguimiento de sagas: La supervisión y el seguimiento del flujo de trabajo de una saga son esenciales para mantener la supervisión operativa.
Limitaciones de las transacciones de compensación: es posible que las transacciones de compensación no siempre se realicen correctamente, lo que podría dejar el sistema en un estado incoherente.
Posibles anomalías de datos en sagas
Las anomalías de datos son incoherencias que pueden producirse cuando las sagas se ejecutan en varios servicios. Dado que cada servicio administra sus propios datos (datos de participantes), no hay aislamiento integrado entre los servicios. Esta configuración puede provocar incoherencias de datos o problemas de durabilidad, como actualizaciones aplicadas parcialmente o conflictos entre servicios. Entre los problemas comunes se incluyen:
actualizaciones perdidas: cuando una saga modifica los datos sin tener en cuenta los cambios realizados por otra saga, conduce a actualizaciones sobrescritas o que faltan.
lecturas de Dirty: cuando una saga o transacción lee los datos que modificó otra saga, pero aún no se completó.
lectura aproximada (no irrepeatable): cuando los distintos pasos de una saga leen datos incoherentes porque las actualizaciones se producen entre las lecturas.
Estrategias para abordar anomalías de datos
Para reducir o evitar estas anomalías, tenga en cuenta estas contramedidas:
bloqueo semántico: use bloqueos de nivel de aplicación donde la transacción compensable de una saga usa un semáforo para indicar que hay una actualización en curso.
actualizaciones conmutantes: actualizaciones de diseño para que se puedan aplicar en cualquier orden mientras se produce el mismo resultado, lo que reduce los conflictos entre sagas.
vista pesimista: reordene la secuencia de la saga para que las actualizaciones de datos se produzcan en transacciones reintentos para eliminar las lecturas sucias. De lo contrario, una saga podría leer datos sucios (cambios no confirmados) mientras que otra saga ejecuta simultáneamente una transacción compensable para revertir sus actualizaciones.
Rereading values: valide que los datos permanecen sin cambios antes de realizar actualizaciones. Si cambian los datos, anule el paso actual y reinicie la saga según sea necesario.
Archivos de versión: mantenga un registro de todas las operaciones en un registro y asegúrese de que se ejecutan en la secuencia correcta para evitar conflictos.
simultaneidad basada en riesgos (por valor): elija dinámicamente el mecanismo de simultaneidad adecuado en función del riesgo empresarial potencial. Por ejemplo, use sagas para actualizaciones de bajo riesgo y transacciones distribuidas para las de alto riesgo.
Cuándo usar este patrón
Use el patrón Saga cuando necesite:
- Asegúrese de la coherencia de los datos en un sistema distribuido sin acoplamiento estricto.
- Revierte o compense si se produce un error en una de las operaciones de la secuencia.
El patrón Saga es menos adecuado para:
- Transacciones estrechamente acopladas.
- Compensación de transacciones que se producen en participantes anteriores.
- Dependencias cíclicas.
Pasos siguientes
Recursos relacionados
Los patrones siguientes también pueden resultar útiles al implementar este patrón:
- coreografía tiene cada componente del sistema que participa en el proceso de toma de decisiones sobre el flujo de trabajo de una transacción empresarial, en lugar de confiar en un punto central de control.
- transacciones de compensación trabajo de deshacer realizado por una serie de pasos y, finalmente, definir una operación coherente si se produce un error en uno o varios pasos. Las aplicaciones hospedadas en la nube que implementan flujos de trabajo y procesos empresariales complejos suelen seguir este modelo de coherencia final .
- reintento permite que una aplicación controle los errores transitorios cuando intenta conectarse a un servicio o recurso de red mediante el reintento transparente de la operación con errores. El reintento puede mejorar la estabilidad de la aplicación.
- interruptor controla los errores que tardan un tiempo variable en recuperarse, al conectarse a un servicio o recurso remotos. El interruptor puede mejorar la estabilidad y la resistencia de una aplicación.
- Supervisión de puntos de conexión de mantenimiento implementa comprobaciones funcionales en una aplicación a la que las herramientas externas pueden acceder a través de puntos de conexión expuestos a intervalos regulares. La supervisión del punto de conexión de mantenimiento puede ayudar a comprobar que las aplicaciones y los servicios funcionan correctamente.