Microservicios y arquitecturas impulsadas por eventos

¿Cómo se relacionan los microservicios y las arquitecturas impulsadas por eventos?

Al comenzar con microservicios, una de las primeras preguntas es cómo mantener la consistencia de los sistemas generales a pesar de que todos los microservicios estén separados entre sí. Dependiendo de los requisitos, la segregación a veces se puede omitir en el nivel de persistencia.


Sin embargo, si el objetivo es que diferentes equipos trabajen en microservicios específicos para que cada uno pueda ser implementado de manera independiente, una buena manera de mantener la coherencia es implementar una arquitectura dirigida por eventos.

Microservicios y Persistencia

Decidir cómo conservar los datos en todos los microservicios, no solo se trata de si todos los microservicios compartirán la misma base de datos o si cada uno tendrá tablas privadas o un esquema / base de datos independiente. En realidad es mucho más que eso. 

En algunas ocasiones, no se accederá a los datos de la misma manera porque el volumen o la complejidad pueden ser demasiado altos o solo consiste en lecturas, escrituras gruesas o bien ambas.

Identificar cómo se debe acceder a los datos le ayudará a tomar una decisión informada sobre qué tipo de persistencia se ajusta mejor a la necesidad de cada microservicio específico. 

Un ejemplo podría ser recuperar los datos históricos de todas las compras realizadas por un cliente. Puede tener una base de datos NoSQL que puede suministrar esa información rápidamente, en lugar de usar una base de datos relacional que está siendo utilizada por otro microservicio que une información de múltiples tablas.

Este enfoque de tener diferentes fuentes de datos nos puede llevar a tener una persistencia de Polyglot.

Como puede ver, hay muchos beneficios en permitir que cada microservicio administre su propia persistencia pero ¿qué sucede en el contexto delimitado cuando diferentes microservicios necesitan compartir los mismos datos?¿Podemos asegurar las transacciones atómicas?

Considerando todo hasta ahora, ¿cómo podemos mantener la persistencia de nuestro microservicio y también mantener los datos consistentes?Ahí es cuando entran en juego las arquitecturas dirigidas por eventos.

Arquitecturas impulsadas por eventos

La idea detrás de la arquitectura dirigida por eventos es publicar un evento cuando sucede algo importante.

Luego, un suscriptor a ese evento puede tomar la información necesaria para actualizar su estado, lo que permite que los datos se mantengan consistentes y se sincronicen. Es importante especificar que tendrá una consistencia eventual a medida que pase el tiempo entre el momento en que se publica el evento y el momento cuando el suscriptor lo recibe.

Existen diferentes maneras de hacer esto:

• Seguimiento al registro de los últimos Logs de las transacciones
• Aplicación creada por eventos
• Fuente o creadores de eventos

Seguimiento al registro de los últimos Logs de las transacciones

Este enfoque está en el nivel de base de datos. Básicamente, extrae el registro de transacciones de la base de datos para publicar eventos. Con este enfoque, no es necesario realizar cambios en el nivel de la aplicación, pero está limitado por el tipo de base de datos que puede usar. Con este enfoque, también es imposible tener una persistencia Polyglot.

Aplicación creada por eventos

En este caso, los eventos están en un nivel de aplicación. Después de un cambio en la base de datos y un evento publicado, no se envía ninguna notificación sobre el cambio a sus suscriptores. Luego el suscriptor obtiene el evento y actualiza su estado. En este caso, puede surgir un problema con la atomicidad de las transacciones.

Imaginemos un escenario en el que se confirmó un cambio en la base de datos y luego se publicó un evento para el intermediario.Sin embargo, por alguna razón se perdió, lo que causará una inconsistencia, porque los cambios en la persistencia del microservicio no se propagaron.Esto se puede resolver mediante un seguimiento del evento para saber si se propagó o no y actuar en consecuencia.

Fuente o creadores de eventos

Como lo escribió Martin Flower, “La idea fundamental de Event Sourcing es garantizar que cada cambio en el estado de una aplicación se capture en un objeto de evento, y que estos objetos de evento se almacenen en la secuencia en que se aplicaron durante el mismo tiempo de vida que el estado de la aplicación.” 

Con este enfoque, es posible, en lugar de persistir en la entidad, persistir solo los eventos, para que el estado de las entidades se pueda obtener al reproducir todos los eventos. 

En este caso, un Event Store actuará como un intermediario a cargo de la comunicación cuando se mantenga un nuevo estado para los suscriptores apropiados. 

Con una fuente de eventos, puede obtener muchos beneficios porque le permite hacer un seguimiento de los cambios en tiempo real, lo que además le ayuda a evitar el uso de una auditoría tradicional.

Como es de esperar, tiene sus inconvenientes.

Imagine un sistema que generará muchos eventos, que forzará la generación de instantáneas para permitir recrear fácilmente el estado actual.

Es posible que desee utilizar solo la fuente de eventos en una parte de su sistema.

Úselo solo donde tenga sentido en lugar de hacer que todo su sistema se base en él. 

Conclusión

No existe una receta exacta para mantener la consistencia en un sistema basado en Microservicios, pero las arquitecturas dirigidas por eventos pueden ayudar a lograr una consistencia eventual. La decisión del enfoque a seguir dependerá de los requisitos del sistema y de la lógica empresarial.