Comunicación basada en mensajes asíncronos II - de receptor único y de múltiples receptores

Comunicación basada en mensajes asíncronos

La mensajería asíncrona y la comunicación orientada a eventos, son fundamentales cuando se propagan cambios entre múltiples microservicios a sus modelos de dominio relacionados. Los modelos (Usuario, Cliente, Producto, Cuenta, etc.) pueden significar diferentes cosas para diferentes microservicios. Eso significa que cuando se producen cambios, se necesita alguna forma de reconciliar los cambios en los diferentes modelos. Una solución es la consistencia eventual y la comunicación basada en eventos basada en mensajes asíncronos.

Una de las reglas más importantes que se debe seguir, en la medida de lo posible, es usar solo mensajes asíncronos entre los servicios internos y usar comunicación síncrona solo desde las

aplicaciones cliente a los servicios de interfaz de usuario (API Gateway más el primer nivel de microservicios).

Hay dos tipos de mensajería asíncrona: comunicación basada en mensajes de receptor único o en mensajes de receptores múltiples. En las siguientes secciones entraremos en detalles sobre ellos.

Comunicaciones de receptor único

La comunicación asíncrona basada en mensajes con un receptor único, significa que hay una comunicación punto a punto que envía un mensaje a exactamente uno de los consumidores que está leyendo desde el canal y que el mensaje se procesa solo una vez. Sin embargo, hay situaciones especiales.

Por ejemplo, en un sistema en la nube que intenta recuperarse automáticamente de fallas, el mismo mensaje podría enviarse varias veces. El cliente debe poder volver a intentar el envió de mensajes en caso de fallos y el servidor debe implementar la lógica necesaria para que una operación sea independiente, para que cada mensaje solo se procese una vez.

La comunicación basada en mensajes de un receptor único, es especialmente adecuada para enviar comandos asíncronos de un microservicio a otro, como se muestra en la Figura 6 que ilustra este enfoque.

Comunicación de receptores múltiples

Para lograr un enfoque más flexible, también se puede usar un mecanismo de publicación/suscripción para que un mensaje del remitente esté disponible para los microservicios subscriptores o para aplicaciones externas. Esto le ayuda a seguir el principio open/closed en el servicio de envió. De esta forma, se pueden agregar suscriptores adicionales en el futuro sin la necesidad de modificar el servicio del remitente.

Un punto importante es que se puede necesitar comunicación con múltiples microservicios que están suscritos al mismo evento. Para hacerlo, se pueden usar los mensajes de publicación/suscripción basados en eventos, como se muestra en la Figura 7. Este mecanismo de publicación/suscripción no es exclusivo de la arquitectura de microservicios. Es similar a la forma en que propagan las actualizaciones desde la base de datos de escritura hacia la base de datos de consulta en el patrón arquitectónico Command and Query Responsibility Segregation (CQRS). El objetivo es tener una consistencia eventual entre múltiples fuentes de datos en un sistema distribuido.

Cuando se usa un bus de eventos, se puede usar un nivel de abstracción (como una interfaz de bus de eventos) basado en una implementación usando la API de un message broker como RabbitMQ. También se puede usar un bus de servicio de nivel superior como NServiceBus, MassTransit o Brighter para coordinar el bus de eventos y el sistema de publicación/suscripción.