Comunicación asincrónica basada en mensajes
La mensajería asincrónica y la comunicación basada en eventos son fundamentales cuando se propagan cambios a través de múltiples microservicios y sus modelos de dominio relacionados. Por ejemplo, en un sistema de ventas online, los modelos (Usuario, Cliente, Producto, Cuenta, etc.) pueden significar cosas diferentes para diferentes microservicios. Eso significa que cuando se producen cambios, necesita alguna forma de conciliar los cambios en los diferentes modelos. Una solución es la coherencia eventual y la comunicación basada en eventos basada en mensajes asíncronos.
Cuando se utiliza la mensajería, los procesos se comunican intercambiando mensajes de forma asincrónica. Un cliente realiza un comando o una solicitud a un servicio enviándole un mensaje. Si el servicio necesita responder, envía un mensaje diferente al cliente. Como se trata de una comunicación basada en mensajes, el cliente asume que la respuesta no se recibirá de inmediato y que es posible que no haya ninguna respuesta.
Un mensaje está compuesto por un encabezado (metadatos como identificación o información de seguridad) y un cuerpo. Los mensajes generalmente se envían a través de protocolos asincrónicos como AMQP.
La infraestructura preferida para este tipo de comunicación en la comunidad de microservicios es un intermediario de mensajes ligero, que es diferente de los grandes intermediarios y orquestadores utilizados en SOA. En un intermediario de mensajes ligero, la infraestructura es típicamente “dumb”, actuando solo como intermediario de mensajes, con implementaciones simples como RabbitMQ o un bus de servicio escalable en la nube como Azure Service Bus.
Otra regla que debe intentar seguir, en la medida de lo posible, es usar solo mensajes asíncronos entre los servicios internos y usar la comunicación sincrónica (como HTTP) solo desde las aplicaciones del cliente a los servicios front-end (API Gateways más primer nivel de microservicios).
Hay dos tipos de comunicación de mensajes asíncronos: comunicación basada en mensajes de receptor único y comunicación basada en mensajes de receptores múltiples. Las siguientes secciones proporcionan detalles sobre ellos.
Comunicación basada en mensajes de receptor único
La comunicación asincrónica basada en mensajes con un solo receptor significa que hay una comunicación punto a punto que entrega un mensaje exactamente a 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. Debido a fallas en la red, el cliente debe poder volver a intentar enviar mensajes, y el servidor debe implementar una operación para ser idempotente a fin de procesar un mensaje en particular solo una vez.
La comunicación basada en mensajes de receptor único es especialmente adecuada para enviar comandos asíncronos de un microservicio a otro, la siguiente figura ilustra este enfoque.
Una vez que comience a enviar comunicaciones basadas en mensajes (ya sea con comandos o eventos), debe evitar mezclar la comunicación basada en mensajes con la comunicación síncrona HTTP.
Tenga en cuenta que cuando los comandos provienen de aplicaciones cliente, se pueden implementar como comandos síncronos HTTP. Debe usar comandos basados en mensajes cuando necesite una mayor escalabilidad o cuando ya se encuentre en un proceso comercial basado en mensajes.
Comunicación basada en mensajes de receptor múltiples
Como un enfoque más flexible, es posible que también desee utilizar un mecanismo de publicación/suscripción para que la comunicación del remitente esté disponible para microservicios de suscriptor adicionales o para aplicaciones externas. Por lo tanto, le ayuda a seguir el principio open/closed en el servicio de envío. De esa forma, se pueden agregar suscriptores adicionales en el futuro sin la necesidad de modificar el servicio del remitente. Cuando utiliza una comunicación de publicación/suscripción, puede emplear una interfaz de bus de eventos para publicar eventos a cualquier suscriptor.
Comunicación asincrónica dirigida por eventos
Cuando se utiliza la comunicación asíncrona dirigida por eventos, un microservicio publica un evento de integración cuando algo sucede dentro de su dominio y otro microservicio necesita estar al tanto de ello, como un cambio de precio en un microservicio de catálogo de productos. Los microservicios adicionales se suscriben a los eventos para que puedan recibirlos de forma asincrónica. Cuando eso sucede, los receptores pueden actualizar sus propias entidades de dominio, lo que puede hacer que se publiquen más eventos de integración. Este sistema de publicación/suscripción generalmente se realiza mediante el uso de una implementación de un bus de eventos. El bus de eventos se puede diseñar como una abstracción o interfaz, con la API que se necesita para suscribirse o cancelar la suscripción a eventos y para publicar eventos. El bus de eventos también puede tener una o más implementaciones basadas en cualquier intermediario entre procesos y mensajería, como una cola de mensajería o bus de servicio que admita comunicación asincrónica y un modelo de publicación/suscripción.
Los eventos de integración se pueden usar para implementar tareas comerciales que abarcan múltiples microservicios. Por lo tanto, tendrá una coherencia eventual entre esos servicios. Una transacción eventualmente consistente se compone de una colección de acciones distribuidas. En cada acción, el microservicio relacionado actualiza una entidad de dominio y publica otro evento de integración que genera la siguiente acción dentro de la misma tarea comercial de extremo a extremo.
Un punto importante es que es posible que desee comunicarse con múltiples microservicios que están suscritos al mismo evento. Para hacerlo, puede usar mensajes de publicación/suscripción basados en la comunicación dirigida por eventos, como se muestra en la siguiente figura. Este mecanismo de publicación/suscripción no es exclusivo de la arquitectura de microservicios. Es similar a la forma en que se deben comunicar los Contextos delimitados en Domain Driven Design (DDD), o la forma en que propaga las actualizaciones de la base de datos de escritura a la base de datos de lectura en el patrón de arquitectura de Segregación de responsabilidad de comando y consulta (CQRS). El objetivo es tener una coherencia eventual entre múltiples fuentes de datos en su sistema distribuido.
Su implementación determinará qué protocolo usar para las comunicaciones basadas en mensajes y controladas por eventos. AMQP puede ayudar a lograr una comunicación en cola confiable.
Cuando usa un bus de eventos, es posible que desee usar un nivel de abstracción (como una interfaz de bus de eventos) basado en una implementación relacionada en clases con código usando la API de un intermediario de mensajes como RabbitMQ o un bus de servicio como Azure Service Bus with Topics .
Esperamos te sea útil este artículo, si te fue útil, puedes invitarme una cerveza.
