Comunicación tolerante a fallos en arquitecturas de microservicios: Sistemas Change Data Capture

En sistemas basados en microservicios, es algo casi obligatorio que los componentes del sistema provean y usen información entre ellos. Un patrón comúnmente utilizado, es el basado en sistemas de colas de mensajería para lograr una arquitectura de tipo Publicador/Suscriptor. A pesar de que los brókeres de mensajería proporcionan resiliencia y recuperabilidad ante fallos de comunicación, estos problemas no se resuelven directamente en el lado de la aplicación publicadora ni en el de la consumidora. Por tanto, es necesario aplicar patrones de diseño software enfocados a resolver estos problemas en la implementación de estas aplicaciones. En este trabajo se va a llevar a cabo la construcción iterativa de un sistema de microservicios, con la intención de estudiar y resolver algunos problemas habituales que surgen con respecto a los fallos de comunicación en este tipo de sistemas: En el lado del publicador un problema a resolver es la transaccionalidad entre los cambios en el estado de la aplicación y la comunicación de estos cambios. Es decir que debe asegurarse que la publicación del mensaje y los cambios en el estado de la aplicación son coherentes. Por ejemplo, un servicio web tiene la responsabilidad de generar una orden de compra de un producto. Una vez generada esa orden de compra, debería guardarla en su BBDD y, además, emitir un evento informando de este cambio. En este último punto, se debe asegurar que ambas cosas suceden de forma atómica, es decir, ambas deben completarse correctamente o ninguna de ellas debe llevarse a cabo. En el lado del suscriptor, también existe un problema de transaccionalidad. Si durante el procesamiento del evento consumido, sucede un error, se deben deshacer todos los cambios previos antes de notificar al bróker que el evento no ha podido ser consumido. Por ejemplo, un servicio web generaría una factura a partir de la consumición de un evento de compra. La ejecución podría implicar un primer paso en el que se genera un descuento futuro para el cliente en base a su compra y después generar y guardar la factura. Si la generación de la factura falla, entonces se debería poder eliminar la generación del descuento que se hizo previamente. Por tanto, al igual que ocurría en el ejemplo de la parte publicadora, aquí también es necesario asegurar la atomicidad de los cambios. El desarrollo del trabajo buscará, por tanto, estudiar y proveer de una solución a los problemas previamente comentados siguiendo un diseño basado en el uso de los siguientes patrones: Comunicación tipo Pub/Sub: El sistema usará un bróker de mensajería que permita asegurar una arquitectura Publicador-Suscriptor, proporcionando así resiliencia y recuperabilidad ante fallos de comunicación. Transactional Outbox: Un patrón de diseño que permitirá asegurar la entrega del mensaje al bróker de mensajería de forma asíncrona y robusta ante fallos de comunicación entre la aplicación publicadora y el bróker de mensajería. Change Data Capture: Un Patrón arquitectónico que permitirá llevar a cabo la entrega de los mensajes del publicador al bróker de mensajería de forma eficiente y escalable, mejorando así la implementación previa del Patrón Transactional Outbox. Abstract: In microservices-based systems, it is almost mandatory for services to provide and exchange information between them. A widely used pattern, is the one that relies on the use of messaging brokers to implement a Publisher/Subscriber architecture. Although messaging brokers provide resilience and recoverability in case of communication failures. These problems are not solved directly by the publisher or by the consuming service. Therefore, it is necessary to apply software design patterns oriented to solve these problems in the implementation of these applications. In this Thesis, an iterative construction of a microservices system will be carried out, with the scope of studying and solve some common problems that arise regarding communication failures in this kind of systems: On the publisher side, an issue to be solved is the transactionality between the changes in the application state and its communication through the messaging broker. In other words, the communication of related messages and changes in application state must be consistent. For instance, a web service is responsible for generating a purchase order for a product. Once the purchase order is generated, it should save it in its database and, in addition, publish an event informing of this change. At this last point, it must be ensured that both things happen atomically, meaning that both must be completed correctly or neither of them should take place. On the subscriber side, there is also a transactionality problem. If during the processing of the consumed event, an error occurs, all previous changes must be undone before notifying the bróker that the event could not be consumed. For example, a web service will generate an invoice from the consumption of a purchase event. The execution could involve a first step where a future discount is generated for the customer based on their purchase and then generating and saving the invoice. If the invoice generation fails, then it should be possible to remove the discount generation that was previously done. Therefore, as in the example of the publishing part, it is also necessary here to ensure the atomicity of the changes. The development of this thesis will therefore seek to study and provide solutions to the problems presented above, following a design based on the following patterns: Pub/sub communication: The system will use a message broker to ensure a pub/sub architecture, thus providing, resiliency and recoverability in communications. Transactional Outbox: A design pattern that will ensure asynchronous and robust delivery of messages to the messaging broker in case of communication failure between the publisher and the message broker. Change Data Capture: An architectural pattern that will allow efficient and scalable delivery of messages from the publisher to the messaging broker. Improving on the previous Transactional Outbox implementation