Features | Open Source | Releases | Docs | Try us free | Blog | Product
Orquestación de microservicio con motor BPM (Camunda) y patrón Saga
En este post vamos a explicar cómo podemos orquestar microservicios con nuestro motor BPM basado en Camunda.
Antes de nada, vamos a presentar el patrón Saga, qué es y cómo funciona.
Patrón Saga
Saga es uno de los patrones más conocidos para las transacciones distribuidas.
Una saga es una secuencia de transacciones locales en la que cada transacción actualiza los datos dentro de un único servicio. La primera transacción se inicia con una solicitud externa correspondiente al funcionamiento del sistema, y después cada paso subsiguiente se inicia con la finalización del anterior
Hay dos enfoques diferentes para llevar a cabo el patrón Saga:
Eventos/Coreografía: Cuando no hay una coordinación central, cada servicio produce y escucha los eventos de otros servicios y decide si una acción debe ser ejecutada o no.
Comando/Orquestación: cuando un servicio coordinador es responsable de centralizar la toma de decisiones de la saga y secuenciar la lógica de negocios.
En este post veremos el segundo enfoque, porque es el más escalable, simple de entender y consistente.
El motor BPM como orquestador
El motor BPM de Camunda proporciona las herramientas para orquestar servicios siguiendo el patrón de Saga. Con eventos de compensación adjuntos a cada transacción (tarea), el motor puede escucharlos de forma centralizada y tomar medidas de compensación para el retroceso.
He aquí un ejemplo:
Observarás que para cada tarea de transacción, se define una acción de compensación a través de un evento de límite de compensación.
Además, las acciones de compensación se toman en cascada. Esto significa que si "reservar hotel" ("book hotel") falla, entonces se ejecuta "cancelar coche" ("cancel car"). Si "reservar vuelo" ("book flight") falla, entonces se ejecutan las acciones "cancelar hotel" ("cancel hotel") y "cancelar coche" ("cancel car").
Entonces, ¿cómo se manejan los fallos y errores en Camunda?
La magia reside en el subflujo subyacente. Este subflujo se activará cuando se lance cualquier error dentro de las tareas de transacción. Cuando el subflujo se inicie, se lanzará un evento de compensación, y se tomarán acciones de compensación.
En este ejemplo, las dos primeras tareas son falsas y sólo registran un mensaje en la consola. Por otro lado, la última hace una llamada http y, si el código de estado http es diferente a 200, entonces se lanza una excepción genérica con el código de error "error-http-response".
En el subflujo, el evento de inicio de compensación está escuchando a cualquier error de este tipo:
Si iniciamos este proceso de negocio, podemos ver en la consola los registros de las tareas que se están ejecutando:
Más información en: https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part-2/
(c) 2020 Indra Soluciones Tecnologías de la Información, S.L.U.