Transaccionalidad distribuida (II). Integración con sistemas legados

En la entrada anterior comenzamos a hablar sobre transaccionalidad distribuida. En esta entrada abordaremos un enfoque para lograr la transaccionalidad distribuida al integrar una naciente arquitectura microservicios con un sistema legado.

Es común la migración o integración de un sistema legado a una arquitectura basada en microservicios, en cualquiera de los dos casos deberá pasar un tiempo en el que el sistema legado sobreviva.

Cuando comenzamos a desarrollar microservicios que deben convivir con el sistema legado, muchas veces se imponen un grupo de restricciones que deben cumplirse, sobre todo asociadas a “no tocar nada” en el sistema legado.

En vistas de que no es posible implementar nuevas funcionalidades en el sistema para “conocer” de los eventos que tienen lugar en el mismo, debemos acceder al sistema de persistencia e intentar sin modificarlo obtener los eventos que generan acciones transaccionales (crear / actualizar / eliminar).

Los sistemas de persistencia en su mayoría implementan el concepto de “registros transaccionales”, cuando en una base de datos tiene lugar una transacción se escribe un log de cambio, que indica la operación que tuvo lugar. Este concepto en inglés se conoce como transactional logs. Vea una utilidad de lectura de un binlog de mysql en Python.

La forma de poder integrar el sistema legado con los nuevos microservicios, sin tocarlo y lo más cercano a tiempo real es leer estos logs, enrutarlos por una cola u otro mecanismo y manejarlos donde necesitemos en los nuevos microservicios. Hay que tener en cuenta que los sistemas de bases de datos no escribirán estos logs en la forma que necesitaremos, de seguro tendremos que implementar un proceso de transformación de datos (ETL).

En la integración debe mantenerse la consistencia (entre el sistema legado y los microservicios), anteriormente explicamos como obtener la información del sistema legado. Este proceso conlleva a escribir también en la base de datos del sistema legado cuando ocurran cambios provocados por la lógica de los microservicios, en ese caso haríamos el proceso inverso y realizaríamos las operaciones sobre la persistencia del sistema legado. Un buen enfoque es usar una arquitectura como la que se muestra en la figura siguiente:

En el diagrama anterior, en dependencia de las reglas del negocio hay componentes que pueden ser ajustados, por ejemplo la cola de mensajes puede ser eliminada y que el ETL de captura escriba directamente sobre los microservicios afectados si se precisa de mayor inmediatez (reducir los tiempos en que se alcanza la consistencia, una cola de mensajes siempre incrementará los tiempos de consistencia).

Otro buen punto en la integración con el sistema legado es evitar que la lógica presente en el sistema legado “ensucie” la implementación de los microservicios, o lo que es lo mismo “la implementación de los microservicios no puede, ni debe estar guiada por la implementación y protocolos del sistema legado”.

En la figura anterior los elementos que permiten la interacción entre los microservicios y el sistema legado forman parte de la capa anticorrupción (Ver patrón capa anticorrupción y patrón de estrangulación).

Espero te sea útil esta entrada para que conozcas un poco más sobre la arquitectura microservicios, si te ha resultado interesante puedes darle una mirada a nuestro libro Patrones para la implementación de una arquitectura microservicios, en el que hablamos de los patrones, cómo funcionan, cuando usarlos y que herramientas usar en cada caso (de las que hemos probado).