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 realiza transacciones de compensación para deshacer los pasos completados. Este enfoque ayuda a mantener 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 no se realizan correctamente.
- Coherencia: Los datos pasan de un estado válido a otro estado válido.
- Aislamiento: las transacciones simultáneas producen los mismos resultados que las transacciones secuenciales.
- durabilidad: los cambios se conservan después de confirmarlos, incluso cuando se producen errores.
En un único servicio, las transacciones siguen los principios ACID porque funcionan dentro de una base de datos única. Sin embargo, puede ser más complejo lograr el cumplimiento acid en varios servicios.
Desafíos en las arquitecturas de microservicios
Normalmente, las arquitecturas de microservicios asignan una base de datos dedicada a cada microservicio. Este enfoque proporciona 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.
- Las bases de datos de cada servicio se pueden escalar de forma independiente.
- Los errores de un servicio están aislados de otros servicios.
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 o los modelos de transacción tradicionales, como el protocolo de confirmación en dos fases, 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.
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 realiza una serie de las transacciones de compensación para invertir los cambios realizados en las transacciones locales anteriores.
Conceptos clave en el patrón Saga
transacciones compensables se pueden deshacer o compensar por otras transacciones 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.
transacciones dinámicas sirven como punto de no devolución en la saga. Después de que una transacción dinámica se realice correctamente, las transacciones compensables 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 asumir diferentes roles, dependiendo del flujo de la saga:
transacciones irreversibles o no compatibles no se pueden deshacer ni reintentar.
El límite entre la reversible y confirmada significa que la transacción dinámica puede ser la última transacción indestable o compensable. O bien, puede ser la primera operación reintentos de la saga.
transacciones reintentos seguir la transacción dinámica. Las transacciones reintentos son idempotentes y ayudan a garantizar que la saga pueda alcanzar su estado final, incluso si se producen errores temporales. Ayudan a la saga a lograr un estado coherente.
Enfoques de implementación de Saga
Los dos enfoques típicos de implementación de saga son 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 el enfoque de 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.
| Ventajas de la coreografía | Desventajas de la coreografía |
|---|---|
| Adecuado para flujos de trabajo simples que tienen pocos servicios y no necesitan una lógica de coordinación. | El flujo de trabajo puede resultar confuso al agregar nuevos pasos. Es difícil realizar un seguimiento de los comandos a los que responde cada participante de saga. |
| 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 porque 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 orquestación, un controlador centralizado o orquestador, controla todas las transacciones e indica a los participantes qué operación realizar en función de los eventos. El orquestador realiza solicitudes sagas, almacena e interpreta los estados de cada tarea y controla la recuperación de errores mediante transacciones compensatorias.
| Ventajas de la orquestación | Desventajas de la orquestación |
|---|---|
| Más adecuado para flujos de trabajo complejos o cuando se agregan nuevos servicios. | Otra complejidad de diseño requiere una implementación de una lógica de coordinación. |
| Evita las dependencias cíclicas porque 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 a medida que decida cómo implementar este patrón:
Cambio en el pensamiento de diseño: Adoptar el patrón Saga requiere una mentalidad diferente. Requiere que se centre en la coordinación de transacciones y la coherencia de los datos en varios microservicios.
Complejidad de las sagas de depuración: Sagas de depuración pueden ser complejas, específicamente a medida que crece el número de servicios participantes.
cambios irreversibles en la base de datos local: 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, al repetir la misma operación no modifica el resultado. Para obtener más información, vea procesamiento de mensajes idempotentes.
Necesidad de sagas de supervisión y seguimiento: Supervisión y seguimiento del flujo de trabajo de una saga son tareas esenciales para mantener la supervisión operativa.
Limitaciones de las transacciones de compensación: es posible que transacciones de compensación no siempre se realicen correctamente, lo que puede 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 operan en varios servicios. Dado que cada servicio administra sus propios datos, denominados datos de participantes, no hay aislamiento integrado entre los servicios. Esta configuración puede dar lugar a incoherencias de datos o problemas de durabilidad, como actualizaciones aplicadas parcialmente o conflictos entre servicios. Entre los problemas típicos se incluyen:
Actualizaciones perdidas: Cuando una saga modifica los datos sin tener en cuenta los cambios realizados por otra saga, resulta en actualizaciones sobrescritas o que faltan.
lecturas de Dirty: Cuando una saga o transacción lee datos que otra saga ha modificado, pero la modificación no se completa.
aproximada o no actualizable, lee: 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 las siguientes contramedidas:
bloqueo semántico: Usar bloqueos de nivel de aplicación cuando una transacción compensable de una saga usa un semáforo para indicar que una actualización está en curso.
actualizaciones conmutantes: Actualizaciones de diseño para que se puedan aplicar en cualquier orden mientras se produce el mismo resultado. Este enfoque ayuda a reducir los conflictos entre sagas.
vista pesimista: Reordenar 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 o cambios no confirmados, mientras que otra saga realiza simultáneamente una transacción compensable para revertir sus actualizaciones.
valores reread: Confirmar que los datos permanecen sin cambios antes de realizar actualizaciones. Si cambian los datos, detenga el paso actual y reinicie la saga según sea necesario.
Archivos de versión: Mantener un registro de todas las operaciones realizadas en un registro y asegurarse de que se realizan en la secuencia correcta para evitar conflictos.
simultaneidad basada en riesgos en función del valor: elegir 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 actualizaciones de alto riesgo.
Cuándo usar este patrón
Use este patrón cuando:
- Debe garantizar la coherencia de los datos en un sistema distribuido sin acoplamiento estricto.
- Debe revertir o compensar si se produce un error en una de las operaciones de la secuencia.
Este patrón podría no ser adecuado cuando:
- Las transacciones están estrechamente acopladas.
- Las transacciones de compensación se producen en participantes anteriores.
- Hay dependencias cíclicas.
Paso siguiente
Recursos relacionados
Los patrones siguientes pueden ser relevantes al implementar este patrón:
El patrón de 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.
El patrón transacción de compensación deshacer el trabajo realizado por una serie de pasos y, finalmente, define 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 .
El patrón Reintento permite a una aplicación controlar errores transitorios cuando intenta conectarse a un servicio o recurso de red mediante la reintento transparente de la operación con errores. Este patrón puede mejorar la estabilidad de la aplicación.
El patrón Circuit Breaker controla los errores que tardan una cantidad variable de tiempo en recuperarse cuando se conecta a un servicio remoto o recurso. Este patrón puede mejorar la estabilidad y la resistencia de una aplicación.
El patrón de supervisión de puntos de conexión de estado de 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. Este patrón puede ayudarle a comprobar que las aplicaciones y los servicios funcionan correctamente.