Patrón de coreografía de la saga

Intención

El patrón de coreografía de la saga ayuda a preservar la integridad de los datos en las transacciones distribuidas que abarcan varios servicios mediante el uso de suscripciones a eventos. En una transacción distribuida, se puede llamar a varios servicios antes de que se complete la transacción. Cuando los servicios almacenan datos en diferentes almacenes de datos, puede resultar difícil mantener la coherencia de datos entre estos almacenes de datos.

Motivación

Una transacción es una sola unidad de trabajo que puede implicar varios pasos, donde todos los pasos se ejecutan por completo o no se ejecuta ningún paso, lo que da como resultado un almacén de datos que conserva su estado coherente. Los términos atomicidad, coherencia, aislamiento y durabilidad (ACID, por sus siglas en inglés) definen las propiedades de una transacción. Las bases de datos relacionales proporcionan transacciones ACID para mantener la coherencia de datos.

Para mantener la coherencia en una transacción, las bases de datos relacionales utilizan el método de confirmación en dos fases (2PC). Consiste en una fase de preparación y una fase de confirmación.

• En la fase de preparación, el proceso de coordinación solicita a los procesos participantes en la transacción (participantes) que se comprometan a confirmar o anular la transacción.

• En la fase de confirmación, el proceso de coordinación solicita a los participantes que confirmen la transacción. Si los participantes no pueden ponerse de acuerdo para realizar la confirmación en la fase de preparación, la transacción se anula.

En los sistemas distribuidos que siguen un patrón de database-per-service diseño, la confirmación en dos fases no es una opción. Esto se debe a que cada transacción se distribuye en varias bases de datos y no existe un único controlador que pueda coordinar un proceso similar a la confirmación en dos fases de los almacenes de datos relacionales. En este caso, una solución es utilizar el patrón de coreografía de la saga.

Aplicabilidad

Use el patrón de coreografía de la saga cuando:

• El sistema requiere integridad y coherencia de los datos en las transacciones distribuidas que abarcan varios almacenes de datos.

• El almacén de datos (por ejemplo, una base de datos NoSQL) no proporciona la confirmación en dos fases para proporcionar transacciones ACID. Es necesario actualizar varias tablas dentro de una sola transacción e implementar la confirmación en dos fases dentro de los límites de la aplicación sería una tarea compleja.

• Un proceso de control central que administra las transacciones de los participantes podría convertirse en un único punto de error.

• Los participantes de la saga son servicios independientes y deben tener un acoplamiento flexible.

• Existe comunicación entre contextos delimitados en un dominio empresarial.

Problemas y consideraciones

• Complejidad: a medida que aumenta el número de microservicios, la coreografía de la saga puede resultar difícil de administrar debido a la cantidad de interacciones entre los microservicios. Además, las transacciones y los reintentos de compensación agregan complejidad al código de la aplicación, lo que puede provocar una sobrecarga de mantenimiento. La coreografía es adecuada cuando solo hay unos pocos participantes en la saga y se necesita una implementación sencilla sin ningún punto de error. Cuando se agregan más participantes, se hace más difícil realizar un seguimiento de las dependencias entre los participantes mediante este patrón.

• Implementación resiliente: en la coreografía de la saga, es más difícil implementar los tiempos de espera, los reintentos y otros patrones de resiliencia a nivel mundial que en la orquestación de la saga. La coreografía debe implementarse en componentes individuales y no a nivel de un orquestador.

• Dependencias cíclicas: los participantes consumen mensajes que se publican unos a otros. Esto podría dar lugar a dependencias cíclicas, lo que generaría complejidades en el código y sobrecargas de mantenimiento, además de posibles bloqueos.

• Problema de escritura doble: el microservicio tiene que actualizar atómicamente la base de datos y publicar un evento. El error de cualquiera de las dos operaciones puede provocar un estado incoherente. Una forma de solucionar este problema es utilizar el patrón de bandeja de salida transaccional.

• Conservación de los eventos: los participantes de la saga actúan en función de los eventos publicados. Es importante guardar los eventos en el orden en que se producen para poder auditarlos, depurarlos y reproducirlos. Puede utilizar el patrón de aprovisionamiento de eventos para conservar los eventos en un almacén de eventos en caso de que sea necesario reproducir el estado del sistema para restablecer la coherencia de datos. Los almacenes de eventos también se pueden utilizar con fines de auditoría y solución de problemas, ya que reflejan todos los cambios en el sistema.

• Coherencia final: el procesamiento secuencial de las transacciones locales da como resultado una coherencia final, lo que puede ser un desafío en los sistemas que requieren una gran coherencia. Para abordar este problema, establezca las expectativas de sus equipos empresariales con respecto al modelo de coherencia o reevalúe el caso de uso y cambie a una base de datos que ofrezca una coherencia sólida.

• Idempotencia: los participantes de la saga tienen que ser idempotentes para permitir la ejecución repetida en caso de que se produzcan errores transitorios provocados por bloqueos inesperados o errores del orquestador.

• Aislamiento de transacciones: el patrón saga carece de aislamiento de transacciones, que es una de las cuatro propiedades de las transacciones ACID. El grado de aislamiento de una transacción determina el grado en el que otras transacciones simultáneas pueden afectar a los datos en los que opera. La orquestación simultánea de las transacciones puede provocar datos obsoletos. Recomendamos utilizar el bloqueo semántico para gestionar estos escenarios.

• Observabilidad: la observabilidad se refiere al registro y el seguimiento detallados para solucionar problemas en el proceso de implementación y orquestación. Esto se vuelve importante cuando aumenta el número de participantes de la saga, lo que dificulta la depuración. La nd-to-end supervisión electrónica y la presentación de informes son más difíciles de lograr en la coreografía de una saga que en la orquestación de una saga.

• Problemas de latencia: las transacciones compensatorias pueden agregar latencia al tiempo de respuesta total cuando la saga consta de varios pasos. Si las transacciones realizan llamadas sincrónicas, la latencia puede aumentar aún más.

Implementación

Arquitectura de alto nivel

En el siguiente diagrama de arquitectura, la coreografía de la saga tiene tres participantes: el servicio de pedidos, el servicio de inventario y el servicio de pago. Se requieren tres pasos para completar la transacción: T1, T2 y T3. Tres transacciones compensatorias restauran los datos al estado inicial: C1, C2 y C3.

• El servicio de pedidos ejecuta una transacción local, la T1, que actualiza de forma atómica la base de datos y publica un mensaje Order placed en el agente de mensajes.

• El servicio de inventario se suscribe a los mensajes del servicio de pedidos y recibe el mensaje de que se ha creado un pedido.

• El servicio de inventario ejecuta una transacción local, la T2, que actualiza de forma atómica la base de datos y publica un mensaje Inventory updated en el agente de mensajes.

• El servicio de pago se suscribe a los mensajes del servicio de inventario y recibe el mensaje de que el inventario se ha actualizado.

• El servicio de pago ejecuta una transacción local, la T3, que actualiza de forma atómica la base de datos con los detalles de los pagos y publica un mensaje Payment processed en el agente de mensajes.

• Si el pago no se realiza correctamente, el servicio de pago ejecuta una transacción compensatoria, la C1, que revierte el pago de forma atómica en la base de datos y publica un mensaje Payment failed en el agente de mensajes.

• Las transacciones compensatorias C2 y C3 se ejecutan para restablecer la coherencia de los datos.

Implementación mediante los servicios de AWS

Puedes implementar el patrón coreográfico de la saga utilizando Amazon. EventBridge EventBridgeusa eventos para conectar los componentes de la aplicación. Procesa los eventos a través de buses o canalizaciones de eventos. Un bus de eventos es un enrutador que recibe eventos y los envía a cero o más destinos u objetivos. Las reglas asociadas al bus de eventos evalúan los eventos a medida que llegan y los envían a los objetivos para su procesamiento.

En la siguiente arquitectura:

• Los microservicios (servicio de pedidos, servicio de inventario y servicio de pago) se implementan como funciones de Lambda.

• Hay tres EventBridge buses personalizados: bus de Orders eventos, bus de Inventory eventos y bus de Payment eventos.

• Las reglas de Orders, reglas de Inventory y reglas de Payment hacen coincidir los eventos que se envían al bus de eventos correspondiente e invocan las funciones de Lambda.

En un escenario que se ejecuta correctamente, cuando se realiza un pedido:

1. El servicio de pedidos procesa la solicitud y envía el evento al bus de eventos Orders.

2. Las reglas de Orders coinciden con los eventos e inician el servicio de inventario.

3. El servicio de inventario actualiza el inventario y envía el evento al bus de eventos Inventory.

4. Las reglas de Inventory coinciden con los eventos e inician el servicio de pago.

5. El servicio de pago procesa la solicitud y envía el evento al bus de eventos Payment.

6. Las reglas de Payment coinciden con los eventos y envían la notificación del evento Payment processed al oyente.

   Como alternativa, cuando hay un problema en el procesamiento de un pedido, las EventBridge reglas inician las transacciones compensatorias para revertir las actualizaciones de datos y mantener la coherencia e integridad de los datos.

7. Si el pago no se realiza correctamente, las reglas de Payment procesan el evento e inician el servicio de inventario. El servicio de inventario ejecuta transacciones compensatorias para revertir el inventario.

8. Cuando el inventario se ha revertido, el servicio de inventario envía el evento Inventory reverted al bus de eventos Inventory. Este evento se procesa mediante reglas de Inventory.. Inicia el servicio de pedidos, que ejecuta la transacción de compensación para eliminar el pedido.

Contenido relacionado

• Patrón de orquestación de la saga

• Patrón de bandeja de salida transaccional

• Patrón de reintento con retroceso