Patrón de dispersión y recolección

Intención

El patrón de dispersión y recopilación es un patrón de enrutamiento de mensajes que implica transmitir solicitudes similares o relacionadas a varios destinatarios y volver a agrupar sus respuestas en un solo mensaje mediante un componente denominado agregador. Este patrón ayuda a lograr la paralelización, reduce la latencia del procesamiento y gestiona la comunicación asincrónica. Es sencillo implementar el patrón de dispersión y recolección mediante un enfoque sincrónico, pero un enfoque más eficaz implica implementarlo como enrutamiento de mensajes en la comunicación asincrónica, con o sin un servicio de mensajería.

Motivación

En el procesamiento de solicitudes, una solicitud que puede tardar mucho tiempo en procesarse secuencialmente se puede dividir en varias solicitudes que se procesan en paralelo. También puedes enviar solicitudes a varios sistemas externos mediante llamadas a la API para obtener una respuesta. El patrón de dispersión y recolección es útil cuando se necesita información de varias fuentes. Scatter-gather agrega los resultados para ayudarte a tomar una decisión informada o a seleccionar la mejor respuesta para la solicitud.

El patrón de dispersión y recolección consta de dos fases, como su nombre lo indica:

• La fase de dispersión procesa el mensaje de solicitud y lo envía a varios destinatarios en paralelo. Durante esta fase, la aplicación dispersa las solicitudes por la red y continúa ejecutándose sin esperar respuestas inmediatas.

• Durante la fase de recopilación, la aplicación recopila las respuestas de los destinatarios y las filtra o combina en una respuesta unificada. Cuando se hayan recopilado todas las respuestas, se pueden agregar en una sola respuesta o se puede elegir la mejor para su posterior procesamiento.

Aplicabilidad

Usa el patrón de dispersión y recolección cuando:

• Planea agregar y consolidar datos de varias API para crear una respuesta precisa. El patrón consolida la información de fuentes dispares en un todo cohesivo. Por ejemplo, un sistema de reservas puede hacer una solicitud a varios destinatarios para obtener cotizaciones de varios socios externos.

• La misma solicitud debe enviarse a varios destinatarios simultáneamente para completar una transacción. Por ejemplo, puedes usar este patrón para consultar datos de inventario en paralelo para comprobar la disponibilidad de un producto.

• Desea implementar un sistema confiable y escalable en el que se pueda lograr el equilibrio de carga distribuyendo las solicitudes entre varios destinatarios. Si un destinatario falla o experimenta una carga elevada, los demás destinatarios pueden seguir procesando las solicitudes.

• Desea optimizar el rendimiento al implementar consultas complejas que involucren múltiples fuentes de datos. Puede dispersar la consulta en las bases de datos relevantes, recopilar los resultados parciales y combinarlos en una respuesta completa.

• Está implementando un tipo de procesamiento de mapas reducido en el que la solicitud de datos se enruta a varios puntos finales de procesamiento de datos para su fragmentación y replicación. Los resultados parciales se filtran y combinan para crear la respuesta correcta.

• Desea distribuir las operaciones de escritura en un espacio de claves de partición en las cargas de trabajo de escritura intensiva en bases de datos con valores clave. El agregador lee los resultados consultando los datos de cada fragmento y, a continuación, los consolida en una sola respuesta.

Problemas y consideraciones

• Tolerancia a errores: este patrón se basa en varios receptores que funcionan en paralelo, por lo que es esencial gestionar los errores con elegancia. Para mitigar el impacto de los fallos de los receptores en todo el sistema, puede implementar estrategias como la redundancia, la replicación y la detección de errores.

• Límites de escalamiento horizontal: a medida que aumenta el número total de nodos de procesamiento, también aumenta la sobrecarga de red asociada. Cada solicitud que implique la comunicación a través de la red puede aumentar la latencia y afectar negativamente a las ventajas de la paralelización.

• Obstáculos en el tiempo de respuesta: en el caso de las operaciones que requieren que se procese a todos los destinatarios antes de finalizar el procesamiento final, el rendimiento del sistema en general se ve limitado por el tiempo de respuesta del destinatario más lento.

• Respuestas parciales: cuando las solicitudes se distribuyen entre varios destinatarios, es posible que se agote el tiempo de espera de algunos destinatarios. En estos casos, la implementación debe comunicar al cliente que la respuesta está incompleta. También puede mostrar los detalles de agregación de respuestas mediante una interfaz de usuario.

• Coherencia de los datos: cuando procese datos de varios destinatarios, debe considerar detenidamente las técnicas de sincronización de datos y resolución de conflictos para garantizar que los resultados agregados finales sean precisos y coherentes.

Implementación

Arquitectura de alto nivel

El patrón de dispersión y recopilación utiliza un controlador raíz para distribuir las solicitudes a los destinatarios que las procesarán. Durante la fase de dispersión, este patrón puede utilizar dos mecanismos para enviar mensajes a los destinatarios:

• Dispersión por distribución: la aplicación tiene una lista conocida de destinatarios a los que hay que llamar para obtener los resultados. Los destinatarios pueden ser diferentes procesos que tienen funciones únicas o un solo proceso que se ha ampliado para distribuir la carga de procesamiento. Si alguno de los nodos de procesamiento agota el tiempo de espera o presenta retrasos en la respuesta, el controlador puede redistribuir el procesamiento a otro nodo.

• Dispersar por subasta: la aplicación difunde el mensaje a los destinatarios interesados mediante un patrón de publicación-suscripción. En este caso, los destinatarios pueden suscribirse al mensaje o cancelar la suscripción en cualquier momento.

Dispersión por distribución

En el método de dispersión por distribución, el controlador raíz divide la solicitud entrante en tareas independientes y las asigna a los destinatarios disponibles (la fase de dispersión). Cada destinatario (proceso, contenedor o función Lambda) trabaja de forma independiente y paralela en su cálculo y produce una parte de la respuesta. Cuando los destinatarios completan sus tareas, envían sus respuestas a un agregador (la fase de recopilación). El agregador combina las respuestas parciales y devuelve el resultado final al cliente. El siguiente diagrama ilustra este flujo de trabajo.

El controlador (procesador de archivos de datos) organiza todo el conjunto de invocaciones y conoce todos los puntos finales de reserva a los que llamar. Puede configurar un parámetro de tiempo de espera para ignorar las respuestas que tardan demasiado. Una vez enviadas las solicitudes, el agregador espera a que lleguen las respuestas de cada punto final. Para implementar la resiliencia, cada microservicio se puede implementar con varias instancias para equilibrar la carga. El agregador obtiene los resultados, los combina en un único mensaje de respuesta y elimina los datos duplicados antes de continuar con su procesamiento. Se ignoran las respuestas cuyo tiempo de espera se agota. El controlador también puede actuar como un agregador en lugar de utilizar un servicio de agregación independiente.

Dispersa por subasta

Si el controlador no sabe cuáles son los destinatarios o si los destinatarios están ligeramente acoplados, puedes utilizar el método de dispersión por subasta. En este método, los destinatarios se suscriben a un tema y el controlador publica la solicitud en ese tema. Los destinatarios publican los resultados en una cola de respuestas. Como el controlador raíz no conoce a los destinatarios, el proceso de recopilación utiliza un agregador (otro patrón de mensajería) para recopilar las respuestas y resumirlas en un único mensaje de respuesta. El agregador usa un identificador único para identificar un grupo de solicitudes.

Por ejemplo, en el siguiente diagrama, el método de dispersión por subasta se utiliza para implementar un servicio de reserva de vuelos para el sitio web de una aerolínea. El sitio web permite a los usuarios buscar y mostrar vuelos de la propia aerolínea y de las compañías aéreas asociadas, y debe mostrar el estado de la búsqueda en tiempo real. El servicio de reserva de vuelos consta de tres microservicios de búsqueda: vuelos sin escalas, vuelos con escalas y aerolíneas asociadas. La búsqueda de aerolíneas asociadas llama a los puntos finales de la API del socio para obtener las respuestas.

1. El servicio de reserva de vuelos (controlador) toma los criterios de búsqueda como datos del cliente y procesa y publica la solicitud relacionada con el tema.

2. El controlador utiliza un identificador único para identificar cada grupo de solicitudes.

3. El cliente envía el ID único al agregador para el paso 6.

4. Los microservicios de búsqueda de reservas que se han suscrito al tema de reserva reciben la solicitud.

5. Los microservicios procesan la solicitud y devuelven la disponibilidad de asientos según los criterios de búsqueda indicados a una cola de respuesta.

6. El agregador recopila todos los mensajes de respuesta almacenados en una base de datos temporal, agrupa los vuelos por un identificador único, crea una respuesta unificada única y la devuelve al cliente.

Implementación mediante Servicios de AWS

Dispersión por distribución

En la siguiente arquitectura, el controlador raíz es un procesador de archivos de datos (Amazon ECS) que divide los datos de las solicitudes entrantes en depósitos individuales de Amazon Simple Storage Service (Amazon S3) e inicia un flujo de trabajo. AWS Step Functions El flujo de trabajo descarga los datos e inicia el procesamiento de archivos en paralelo. El Parallel estado espera a que todas las tareas devuelvan una respuesta. Una AWS Lambda función agrega los datos y los guarda de nuevo en Amazon S3.

El siguiente diagrama ilustra el flujo de trabajo de Step Functions con el Parallel estado.

Dispersar por subasta

El siguiente diagrama muestra una AWS arquitectura para el método de dispersión por subasta. El servicio de reserva de vuelos del controlador raíz dispersa la solicitud de búsqueda de vuelos en varios microservicios. Se implementa un canal de publicación-suscripción con Amazon Simple Notification Service (Amazon SNS), que es un servicio de mensajería gestionada para las comunicaciones. Amazon SNS admite mensajes entre aplicaciones de microservicios disociadas o comunicaciones directas con los usuarios. Puede implementar los microservicios destinatarios en Amazon Elastic Kubernetes Service (Amazon EKS) o Amazon Elastic Container Service (Amazon ECS) para mejorar la administración y la escalabilidad. El servicio de resultados de vuelos devuelve los resultados al cliente. Se puede implementar en AWS Lambda u otros servicios de organización de contenedores, como Amazon ECS o Amazon EKS.

1. El servicio de reserva de vuelos (controlador) toma los criterios de búsqueda como datos del cliente y procesa y publica la solicitud en el tema de SNS.

2. El controlador publica el identificador único en una base de datos de Amazon Aurora para identificar la solicitud.

3. El cliente envía el identificador único al cliente para el paso 6.

4. Los microservicios de búsqueda de reservas que se han suscrito al tema de reserva reciben la solicitud.

5. Los microservicios procesan la solicitud y devuelven la disponibilidad de asientos para los criterios de búsqueda indicados a una cola de respuestas en Amazon Simple Queue Service (Amazon SQS). El agregador recopila todos los mensajes de respuesta y los almacena en una base de datos temporal.

6. El servicio de resultados de vuelos agrupa los vuelos por un identificador único, crea una única respuesta unificada y la envía de vuelta al cliente.

Si desea añadir otra búsqueda de aerolíneas a esta arquitectura, añada un microservicio que se suscriba al tema de SNS y lo publique en la cola de SQS.

En resumen, el patrón de dispersión y recolección permite a los sistemas distribuidos lograr una paralelización eficiente, reducir la latencia y gestionar sin problemas la comunicación asincrónica.

GitHub repositorio

Para obtener una implementación completa de la arquitectura de ejemplo para este patrón, consulte el GitHub repositorio en https://github.com/aws-samples/ asynchronous-messaging-workshop /tree/master/code/lab-3.

Taller

• Laboratorio de dispersión en el taller sobre microservicios desacoplados

Referencias de blogs

• Patrones de integración de aplicaciones para microservicios

Contenido relacionado

• Patrón de publicación y suscripción