Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Patrón de mensajería desacoplada
Este patrón proporciona una comunicación asincrónica entre microservicios mediante un modelo de sondeo asincrónico. Cuando el sistema backend recibe una llamada, responde inmediatamente con un identificador de solicitud y, a continuación, procesa la solicitud de forma asincrónica. Se puede crear una arquitectura de acoplamiento flexible, que evite los cuellos de botella provocados por la comunicación sincrónica, la latencia y las operaciones de entrada/salida (E/S). En el caso de uso del patrón, Amazon Simple Queue Service (Amazon SQS) y Lambda se utilizan para implementar la comunicación asincrónica entre diferentes microservicios.
Debería considerar la posibilidad de utilizar este patrón si:
-
Desea crear una arquitectura de acoplamiento flexible.
-
No es necesario completar todas las operaciones en una sola transacción y algunas operaciones pueden ser asincrónicas.
-
El sistema descendente no puede gestionar la tasa de transacciones entrantes por segundo (TPS). Los mensajes se pueden escribir en la cola y procesar en función de la disponibilidad de recursos.
Una desventaja de este patrón es que las acciones de las transacciones comerciales son sincrónicas. Aunque el sistema de llamadas reciba una respuesta, es posible que parte de la transacción siga siendo procesada por los sistemas descendentes.
importante
Como este patrón es más adecuado para un modelo de tipo dispare y olvídese, el cliente que llame a este servicio debería sondear el servicio real mediante un ID de solicitud para obtener el estado de la transacción.
Caso de uso
En este caso de uso, el sistema de seguros tiene una base de datos de ventas que se actualiza automáticamente con los detalles de las transacciones del cliente después de realizar un pago mensual. La siguiente ilustración muestra cómo crear este sistema mediante el patrón de mensajería desacoplada.
El flujo de trabajo consta de los siguientes pasos:
La aplicación frontend llama a la puerta de enlace de la API con la información de pago después de que el usuario realice su pago mensual.
La puerta de enlace de la API ejecuta la función de Lambda “Cliente” que guarda la información de pago en una base de datos de Amazon Aurora, escribe los detalles de la transacción en un mensaje dirigido a Amazon SQS de “Ventas” y responde al sistema de llamadas con un mensaje de éxito.
Una función de Lambda “Ventas” extrae los detalles de la transacción del mensaje de SQS y actualiza los datos de ventas. La lógica de errores y reintentos para actualizar la base de datos de ventas se incorpora como parte de la función de Lambda “Ventas”.
