¿Qué son los microservicios basados en eventos? Rompiendo el modelo síncrono

Una arquitectura de microservicios está formada por numerosas unidades funcionales pequeñas, cada una encargada de gestionar una parte del negocio. Es la tendencia hacia la que están evolucionando muchas empresas que quieren moverse hacia DevOps puesto que son muy numerosos los beneficios de una arquitectura de microservicios.  De forma habitual, estos microservicios necesitarán comunicarse entre sí para llevar a cabo algunas de sus funciones. Pero, ¿cómo pueden hacerlo? En este artículo veremos los tipos de comunicación entre microservicios, las limitaciones del modelo de comunicación síncrono y, en contraposición, explicaremos en qué consisten los microservicios basados en eventos y las ventajas que ofrecen.

Tipos de comunicación entre microservicios

La comunicación entre dos microservicios puede ser:

• Síncrona: secuencial. Un servicio realiza una petición a otro y espera a su respuesta.
• Asíncrona: no es secuencial. Un servicio no necesita esperar a que termine otro para continuar su ejecución.

Modelo de comunicación síncrona. Llamadas entre microservicios

La comunicación síncrona entre dos microservicios es conceptualmente sencilla. Veamos un ejemplo:

Tenemos un microservicio A, que recibe órdenes de pedidos. Cuando le llega una orden, entre otras cosas, deberá actualizar el stock del producto. Para ello debe llamar a otro microservicio B que se encarga de gestionar el inventario.

En un modelo de comunicación síncrona el microservicio A mandará, por ejemplo, una petición HTTP hacia el microservicio B. El microservicio realizará las operaciones necesarias para actualizar el stock y devolverá una respuesta. Finalmente, el microservicio A recibirá esta respuesta y continuará su ejecución.

Esta comunicación parece muy natural. Tanto, que se podría comparar con la que podrían tener dos personas que están hablando por teléfono. En algunos casos este modelo se ajusta bien a las necesidades del sistema. No obstante, tiene sus limitaciones.

Inconvenientes del modelo síncrono de comunicación

En primer lugar, la comunicación es bloqueante. El microservicio A no puede continuar su ejecución hasta que el microservicio B haya terminado de actualizar el inventario. ¿Qué pasaría si el microservicio B estuviera temporalmente inaccesible, por ejemplo, por problemas de red? El servicio A permanecería en espera hasta que el servicio B respondiera. En realidad, existen mecanismos, como timeouts, para evitar que un servicio esté a la espera indefinidamente. No obstante, si situaciones como estas son comunes, serían sintomáticas de que tal vez el modelo de comunicación síncrono no es el más apropiado para el caso de uso.

Continuando con el ejemplo. Supongamos que el microservicio de inventariado finaliza su operación y responde con un código de estado exitoso. El procesamiento del pedido no acaba ahí. Implicará varios pasos más, por ejemplo, crear la orden de envío del producto, que podría estar implementada en otro microservicio C distinto. Del mismo modo que se introduce este tercer microservicio, podrían estar implicados un cuarto, un quinto, etc. hasta llegar a n microservicios.

No solo eso, sino que además algunos microservicios no dependen de otros. Un microservicio que gestione el envío del producto seguramente no necesite la respuesta de otro microservicio que calcule el precio final del producto, y, aun así, en una comunicación síncrona, como se deben llamar de manera secuencial, uno de ellos deberá esperar a que termine el otro.

Por estos motivos surge la necesidad de un modelo de comunicación diferente.

Microservicios basados en eventos o modelo de comunicación asíncrona

Imaginemos ahora otra alternativa, un sistema donde los microservicios no se tienen que “llamar” directamente entre sí. Esto es lo que nos proporcionarían los microservicios basados en eventos.

En lugar de peticiones y respuestas, los microservicios trabajarán con el concepto de eventos. Un evento es un mensaje o registro que representa un acontecimiento en el dominio de nuestra aplicación.

Al trabajar con eventos tendremos dos roles implicados, productores y suscriptores.

• Productores: generan eventos en el sistema.
• Suscriptores: consumen eventos y reaccionan a ellos.

Un microservicio puede ser productor de eventos, suscriptor o ambos roles simultáneamente.

Tomando el ejemplo anterior, podemos identificar un evento muy claro: «Se ha creado un pedido con referencia X». En una comunicación por eventos, el microservicio de pedidos no invocará directamente a los otros microservicios, sino que publicará este evento en el sistema.

Tanto el microservicio de inventario como el de logística estarán a la escucha de eventos de creación de pedidos. Como suscriptores, cuando se publique un evento de este tipo, serán notificados y realizarán sus operaciones.

De esta manera se consigue un desacoplamiento entre los microservicios. El microservicio de pedidos ya no tiene que llamar a los microservicios de logística o inventario. Simplemente publicará un evento. Por su parte, los microservicios suscriptores dejan de verse limitados por la ejecución secuencial vista en el caso de las peticiones síncronas.

La comunicación basada en eventos supone un cambio de paradigma. Hemos pasado de microservicios que se dan órdenes entre sí («Actualiza el inventario del producto X») a microservicios que informan de cambios en el dominio mediante eventos, y reaccionan a ellos.

Pero, ¿dónde se gestionan estos eventos? Para ello se utiliza una pieza intermedia, el bus de eventos. Normalmente se usa una tecnología destinada a tal fin, como Apache Kafka o RabbitMQ.

Ventajas de los microservicios basados en eventos

Una arquitectura de microservicios basada en eventos nos ofrece numerosas ventajas:

• Desacoplamiento entre los microservicios. La implementación de los microservicios no requiere conocer quién va a consumir los eventos.
• Aumenta la agilidad de desarrollo. El menor acoplamiento permite que se puedan implementar distintos microservicios en paralelo y por equipos independientes.
• Escalabilidad. Permite responder a aumentos de tráfico en el sistema. Si un microservicio experimenta gran carga, se pueden añadir más instancias de este. Por su parte, las tecnologías del bus de eventos como Kafka también están pensadas para ser escalables.
• Extensibilidad. El modelo productor/suscriptor permite añadir suscriptores a un bus de eventos, sin necesidad de modificar el productor o el resto de consumidores.
• Gracias a la comunicación asíncrona, se consigue mayor resistencia ante fallos. La caída de un servicio no produciría un fallo en cascada.

Esto no quiere decir que no haya lugar para la comunicación síncrona. En ocasiones es necesario disponer de la respuesta de un servicio para continuar con la ejecución de la operación (operaciones transaccionales). No es imposible tener operaciones transaccionales en una arquitectura basada en eventos, pero su implementación puede ser más tediosa. Con una comunicación síncrona, la transaccionalidad surge de forma más natural.

En conclusión, sería preferible utilizar un sistema basado en eventos y representar los cambios en el dominio como tales siempre que sea viable. La comunicación basada en eventos potencia y expande los microservicios, desacoplándolos, facilitando su desarrollo y mantenimiento.

En Hiberus podemos ayudarte a mover tu empresa hacia a una arquitectura de microservicios con un sistema basado en eventos puesto que contamos con un equipo de expertos en microservicios con la capacidad de analizar y aconsejarte acerca de las mejores opciones para ti y para tu empresa.