Información sacada del libro Microservice patterns with examples in java, de Chris Richardson(2019)
Hacer microservicios no es facil una de las dificultades al hacerlos es como generar operaciones que requieren la interacción de múltiples servicios.
Para conseguir esto se usa una estrategia llamada sagas, estas permiten conectar las funcionalidades de varios servicios para realizar una operación
Mediante sagas los servicios se comunican para lograr una operacion conjunta y como todo existen muchas maneras de hacerlo para no entrar en todas las variantes voy a escribir del enfoque recomendado en el libro para la mayoría de casos(aunque en el libro se explican sus variantes ventajas y desventajas).
Debido a que múltiples servicios van a interactuar en la operación lo recomendado inicia con un retorno temprano, esto significa responder al cliente con un valor(un id generalmente) aunque la operación(en el caso de comandos) no esté completa, luego el cliente (por ejemplo una pagina web, o app móvil) puede consultar para verificar si su operación ya se aplicó y su información actualizada (mandando el id que recibió de manera temprana el servicio/s que reciben la petición pueden confirmar si la operación que hizo el cliente ya se aplicó)
Se recomienda hacer esto (aunque se convierta en una lógica mas completa para el cliente) por que si no se hace la disponibilidad del sistema disminuye al tener que estar arriba/disponibles al mismo tiempo todos los servicios involucrados en una operación para que la operación no falle(recordando que la disponibilidad es la multiplicación de la disponibilidad de los servicios involucrados)
Generalmente en una arquitectura de microservicio este servicio A va ser un api gateway (o backend for frontend), teniendo esto claro entramos a las sagas que las hay de 2 tipos.
- sagas coreografiadas: donde los servicios se comunican directamente entre sí, sin una aplicación o sistema central que los coordine, solo se recomienda si una operación muy sencilla pues se vuelve muy complejo de mantener muy rápido (esto se da a que la lógica para una sola operación, sus estados queda distribuida entre los servicios mismo, por que lo para entender una operación hay que entrar a ver cada servicio)
- sagas orquestadas: una aplicación se encarga de mantener una máquina de estado de la operación y con ella conectarse con los servicios correspondientes y servir de punto central de comunicación entre servicios, tener una máquina de estado para cada operación simplifica el entendimiento de como funciona una operación y sus interacciones con otros servicios
Debido a esto las sagas orquestadas son mas recomendadas en general (solo podrian estar bien las coreografiadas cuando se estén haciendo operaciones sencillas), en el libro recomiendan que las sagas se conecten mediante una estrategia request-response asíncrona esta estrategia consiste en usar un sistema de mensajería (como rabbit o kafka) pero simulando el modelo de petición respuesta.
al usar un broker de mensajería con el retorno temprano de ante, se logra mejorar la disponibilidad (si el servicio que recibe el mensaje esta abajo el broker mantiene el mensaje hasta que el servicio vuelva a subir, y como se respondio rapidamente al cliente la petición no se queda esperando ni falla) y al ser un modelo request response la comunicación es más sencilla( se usa un id de mensaje como en la imagen que permite que el servicio que hace la petición vincula la respuesta con la misma petición con hizo al recibir el mismo id, también se le llama aveces requestId).
Entonces el orquestador de sagas (que puede ser un servicio o correr como parte de uno de los servicios) con su interacciones luce algo así
todavía faltan varias cosas de sagas en microservicios que se mencionan, pero ya se alargo bastante por lo que seguirá en una parte 2, las cosas que faltan que recuerdo son.
- tipos de operaciones en sagas(compesatable, retriable, pivot)
- compensation transaction.
- isolation y semantic locking
