Patrón de coreografía

El patrón coreográfico descentraliza la lógica del flujo de trabajo y distribuye las responsabilidades a otros componentes dentro de un sistema. En lugar de depender de un orquestador central, los servicios deciden cuándo y cómo procesar una operación empresarial.

Contexto y problema

Normalmente, se divide una aplicación basada en la nube en varios servicios pequeños que funcionan conjuntamente para procesar una transacción empresarial de un extremo a otro. Una sola operación dentro de una transacción puede dar lugar a varias llamadas de punto a punto entre todos los servicios. Idealmente, esos servicios están acoplados de forma flexible. Es difícil diseñar un flujo de trabajo distribuido, eficaz y escalable, ya que implica una comunicación entre servicios compleja.

Un patrón común para la comunicación es usar un servicio centralizado o un orquestador. Las solicitudes entrantes fluyen a través del orquestador a medida que delega las operaciones a los servicios respectivos. Cada servicio completa su responsabilidad y no es consciente del flujo de trabajo general.

Normalmente, se implementa el patrón de orquestación como software personalizado que tiene conocimiento especializado sobre las responsabilidades de los servicios dentro del sistema. Una ventaja de este enfoque es que el orquestador puede consolidar el estado de una transacción en función de los resultados de las operaciones individuales que realizan los servicios descendentes.

Este enfoque también crea algunos obstáculos. Agregar o quitar servicios puede romper la lógica existente porque hay que reorganizar partes de la ruta de comunicación. Esta dependencia hace que la implementación del orquestador sea compleja y difícil de mantener. El orquestador podría afectar negativamente a la confiabilidad de la carga de trabajo. Bajo carga, puede introducir cuellos de botella de rendimiento y ser el punto único de falla (SPoF). También puede provocar errores en cascada en los servicios descendentes.

Solución

Delegue la lógica de control de transacciones entre los servicios. Permitir que cada servicio participe en el flujo de trabajo de comunicación de una operación empresarial y decida cuándo y cómo procesarlo.

El patrón de coreografía minimiza la dependencia del software personalizado que centraliza el flujo de trabajo de comunicación. Los componentes implementan lógica común a medida que coreografían el flujo de trabajo entre sí sin comunicarse directamente entre sí.

Una manera común de implementar la coreografía es usar un agente de mensajes que almacena en búfer las solicitudes hasta que los componentes descendentes las reclaman y procesan. En la imagen siguiente se muestra el control de solicitudes a través de un modelo de publicador-suscriptor.

1. El cliente encola solicitudes como mensajes en un intermediario de mensajes.

2. Los servicios o el suscriptor sondea al agente para determinar si estos pueden procesar ese mensaje en función de su lógica empresarial implementada. El intermediario también puede enviar mensajes a los suscriptores interesados en ese mensaje.

3. Cada servicio suscrito realiza su operación como indica el mensaje y responde al agente con un mensaje de operación correcta o de error.

4. Si la operación se realiza correctamente, el servicio puede devolver un mensaje a la misma cola o a una cola de mensajes diferente para que otro servicio pueda continuar el flujo de trabajo si es necesario. Si la operación falla, el agente de mensajes trabaja con otros servicios para compensar esa operación o toda la transacción.

Problemas y consideraciones

Tenga en cuenta los siguientes puntos a medida que decida cómo implementar este patrón:

• El control de errores puede ser difícil. Los componentes de una aplicación pueden administrar tareas atómicas y depender de otras partes del sistema. Un error en un componente puede afectar a otros componentes, lo que puede provocar retrasos en completar la solicitud general.

  Para controlar los errores correctamente, implemente la lógica de control de errores, lo que introduce complejidad. La lógica de control de errores, como la compensación de transacciones, también es propensa a errores.

  

  El diagrama de flujo muestra la lógica de control de errores y compensación en un patrón de coreografía que tiene dependencias de servicio secuenciales. En la parte superior, un nodo de inicio apunta al servicio A. El servicio A se conecta a un diamante que apunta al servicio B a la izquierda y al servicio C a la derecha. Las flechas van desde cada uno de estos servicios hacia un rombo de decisión que evalúa si la solicitud falla. La ruta de acceso con la etiqueta sí se bifurca hacia arriba en un bucle que regresa al rombo que conecta los tres servicios. La ruta de acceso etiquetada 'no' continúa hacia un cuadro que indica que ambos servicios finalizaron con éxito. A partir de este estado de éxito, el flujo continúa hacia abajo hasta el servicio D, que se conecta a un diamante de decisión final que pregunta si se produce un error en la solicitud. El camino de 'sí' desde este diamante vuelve hacia arriba para volver a entrar en el flujo antes del Servicio D, y el camino de 'no' continúa hacia abajo hacia un nodo final.

• Este patrón se adapta a un flujo de trabajo que procesa operaciones empresariales independientes en paralelo. El flujo de trabajo se puede complicar cuando la coreografía debe ocurrir en una secuencia. Por ejemplo, el servicio D solo puede iniciar su operación después de que el servicio B y el servicio C completen correctamente sus operaciones.

  

  El diagrama muestra el flujo de mensajes en un patrón de coreografía en el que los servicios procesan las operaciones en paralelo y secuencialmente. En la parte superior hay cinco componentes organizados horizontalmente: servicio A, agente de mensajes, servicio B, servicio C y servicio D. En el extremo izquierdo, un usuario envía una solicitud al servicio A. El servicio A convierte la solicitud en el mensaje m1_a y la publica en el agente de mensajes. Debajo del agente de mensajes, una escala de tiempo vertical muestra cómo cada servicio controla los mensajes. Dentro de una región sombreada etiquetada "par" para el procesamiento paralelo, el agente de mensajes entrega m1_a tanto al servicio B como al servicio C simultáneamente mediante flechas discontinuas. El servicio B procesa el mensaje y devuelve m1_b al agente de mensajes. El servicio C procesa el mensaje y devuelve m1_c al agente de mensajes. En el lado derecho del diagrama, dos cuadros pequeños representan condiciones de espera para el servicio D. La primera condición indica Esperar hasta m1_b y m1_c, lo que indica que el servicio D no puede continuar hasta que recibe ambos mensajes. La segunda condición indica Esperar hasta m1_b. Una vez completado el procesamiento paralelo y tanto el servicio B como el servicio C responden, el agente de mensajes envía m1_c al servicio D, seguido de m1_b. El servicio D procesa estos mensajes y devuelve m1_d al agente de mensajes. Debajo del diagrama, una leyenda explica cada notación. La solicitud hace referencia a la solicitud HTTP original enviada a un punto de conexión público. M1_a es la solicitud HTTP convertida en un mensaje. M1_b es el mensaje procesado y enviado de vuelta al agente de mensajes desde el servicio B. M1_c es el mensaje procesado y enviado de vuelta al agente de mensajes desde el servicio C, y m1_d indica que m1_b y m1_c se procesan y se envían como confirmación final al agente de mensajes. Las flechas sólidas indican mensajes de publicación y las flechas discontinuas indican mensajes de suscripción.

• Este patrón presenta desafíos si el número de servicios crece rápidamente. Muchas partes móviles independientes complican el flujo de trabajo entre los servicios. Debe usar de forma coherente los identificadores de seguimiento y correlación distribuidos para mantener la observabilidad.

• En un diseño dirigido por orquestador, el componente central puede delegar responsabilidades de resiliencia, como la gestión de reintentos en fallos transitorios, no transitorios y de tiempo de espera, a un controlador de resiliencia dedicado.

  Al quitar el orquestador en un diseño basado en coreografía, los componentes posteriores no asumen responsabilidades de resiliencia. Permanecen centralizados en el controlador de resistencia. Pero los componentes descendentes deben comunicarse directamente con ese manejador, lo que aumenta la comunicación de punto a punto.

• La evolución del esquema de eventos puede provocar cambios importantes en los consumidores a lo largo del tiempo. En este patrón, varios servicios independientes consumen los mismos eventos. Si un productor cambia la estructura de datos de un evento, puede afectar a los consumidores finales que dependen del esquema anterior. Utilice un registro de esquemas para gestionar los contratos de eventos y aplicar la evolución compatible hacia atrás a medida que los servicios evolucionan de forma independiente.

• El orden de eventos no se garantiza en reintentos ni en escalamiento horizontal. Diseñe su sistema para la idempotencia y vuelva a emitir mensajes en secuencia para manejar eventos duplicados o fuera de secuencia.

• Las topologías de eventos descentralizados pueden crear un comportamiento emergente a escala. Cuando muchos servicios reaccionan a los eventos entre sí, el sistema puede generar involuntariamente bucles de retroalimentación o tormentas de eventos. Un evento menor podría desencadenar una cascada de reacciones descendentes. Para evitar cadenas de eventos circulares, use barreras de protección como el filtrado de eventos, los límites de simultaneidad del consumidor, la limitación y las reglas explícitas.

Cuándo usar este patrón

Use este patrón en los siguientes supuestos:

• Los componentes descendentes controlan las operaciones atómicas de forma independiente. Piense en este patrón como un mecanismo de disparar y olvidar, en el que un componente realiza una tarea que no necesita administración activa. Una vez completada la tarea, el componente envía una notificación a los demás componentes.

• Espera actualizar y reemplazar los componentes con frecuencia. Este patrón le permite modificar la aplicación con menos esfuerzo y una interrupción mínima en los servicios existentes.

• Puede usar arquitecturas sin servidor para flujos de trabajo simples. Los componentes pueden ser efímeros y estar basados en eventos. Cuando se produce un evento, el servicio crea componentes que realizan una tarea y el servicio quita los componentes después de completar esa tarea.

• La comunicación entre contextos limitados requiere un acoplamiento flexible a través de los límites del dominio. Para la comunicación dentro de un único contexto delimitado, utilice un patrón de orquestador.

• El orquestador central genera un cuello de botella de rendimiento.

Este patrón podría no ser adecuado cuando:

• La aplicación es compleja y requiere un componente central que controle la lógica compartida para mantener ligeros los componentes descendentes.

• La comunicación de punto a punto entre los componentes es inevitable.

• Debe usar la lógica empresarial para consolidar todas las operaciones que manejan los componentes descendentes.

Diseño de cargas de trabajo

Evalúe cómo usar el patrón de coreografía en el diseño de una carga de trabajo para abordar los objetivos y principios descritos en los pilares de Azure Well-Architected Framework. En la tabla siguiente se proporciona una guía sobre cómo este patrón apoya los objetivos de cada pilar.

Si este patrón introduce concesiones dentro de un pilar, considérelas en relación con los objetivos de los otros pilares.

Ejemplo

En este ejemplo se muestra el patrón de coreografía mediante la creación de una carga de trabajo nativa de la nube controlada por eventos que ejecuta funciones junto con microservicios. Cuando un cliente solicita enviar un paquete, la carga de trabajo asigna un dron. Después de que el paquete esté listo para la recogida por el dron programado, se inicia el proceso de entrega. Mientras el paquete está en tránsito, el sistema de gestión gestiona la entrega hasta que recibe el estado de enviado.

El servicio de ingesta recibe solicitudes de cliente y los convierte en mensajes que incluyen los detalles de entrega. Las transacciones empresariales se inician después de que los servicios consuman esos nuevos mensajes.

Una sola transacción empresarial de cliente requiere tres operaciones empresariales distintas:

• Cree o actualice un paquete.

• Asigne un dron para entregar el paquete.

• Controle la entrega, incluida la comprobación y el envío de una notificación cuando el paquete se envíe.

Los microservicios de paquete, programador de drones y entrega realizan el procesamiento empresarial. Los servicios usan mensajería en lugar de un orquestador central para comunicarse entre sí. Cada servicio debe implementar un protocolo de antemano que coordina el flujo de trabajo empresarial de forma descentralizada.

Design

Los servicios procesan transacciones empresariales en una secuencia a través de varios saltos. Cada nodo comparte un único bus de mensajes entre todos los servicios de negocio.

Cuando un cliente envía una solicitud de entrega a través de un punto de conexión HTTP, el servicio de ingesta lo recibe, lo convierte en un mensaje y, a continuación, publica el mensaje en el bus de mensajes compartido. Los servicios empresariales suscritos consumen nuevos mensajes agregados al bus. Cuando un servicio empresarial recibe el mensaje, completa correctamente la operación o se produce un error en la solicitud o se agota el tiempo de espera. Si la solicitud se realiza correctamente, el servicio responde al bus con el Ok código de estado, genera un nuevo mensaje de operación y lo envía al bus de mensajes. Si se produce un error en la solicitud o se agota el tiempo de espera, el servicio notifica el error enviando el código de motivo al bus de mensajes y, a continuación, agrega el mensaje a una cola de mensajes fallidos (DLQ). El servicio también mueve los mensajes que no puede recibir o procesar dentro de un período de tiempo específico al DLQ.

Este diseño usa varios buses de mensajes para procesar toda la transacción empresarial. Azure Service Bus y Azure Event Grid proporcionan la plataforma del servicio de mensajería para este diseño. La carga de trabajo se ejecuta en Azure Container Apps, que hospeda Azure Functions para la ingesta. Container Apps controla el procesamiento controlado por eventos que ejecuta la lógica de negocios.

Este diseño también garantiza que la coreografía se produzca en una secuencia. Un único espacio de nombres de Service Bus contiene un tema que tiene dos suscripciones y una cola sensible a la sesión. El servicio de ingestión publica mensajes en el tópico. El servicio de paquetes y el servicio de programación de drones se suscriben al tópico y publican mensajes que notifican a la cola sobre solicitudes exitosas. Incluya un identificador de sesión común que asocie un GUID con el identificador de entrega para que los servicios puedan gestionar secuencias ilimitadas de mensajes relacionados en orden. El servicio de entrega espera dos mensajes relacionados para cada transacción. El primer mensaje indica que el paquete está listo para enviarse y el segundo mensaje indica que un dron está programado.

En este diseño, Service Bus controla mensajes de alto valor que no se deben perder ni duplicar durante todo el proceso de entrega. Cuando el paquete se distribuye, se publica un cambio de estado en Event Grid. El remitente del evento no tiene ninguna expectativa sobre cómo se controla el cambio de estado. Los servicios de organizaciones descendentes que este diseño no incluye pueden escuchar este tipo de evento y ejecutar lógica empresarial específica, como enviar un correo electrónico con el estado del pedido al usuario.

Si despliegas este patrón en otro servicio de proceso, como AKS, puedes implementar la aplicación boilerplate del patrón publicador-suscriptor con dos contenedores en el mismo pod. Un contenedor ejecuta el embajador que interactúa con el bus de mensajes que elija mientras el otro contenedor ejecuta la lógica de negocios. Este enfoque mejora el rendimiento y la escalabilidad. El embajador y el servicio empresarial comparten la misma red, lo que reduce la latencia y aumenta el rendimiento.

Para evitar operaciones de reintento en cascada que pueden provocar varios intentos, los servicios empresariales deben marcar inmediatamente mensajes inaceptables. Mejorar estos mensajes utilizando códigos de razón comunes o un código de aplicación definido para que los servicios puedan moverlos a un DLQ. Considere implementar el patrón Saga para administrar problemas de coherencia de los servicios aguas abajo. Por ejemplo, otro servicio maneja los mensajes de dead-letter solo con fines de corrección mediante la ejecución de una transacción de compensación, reintento o pivote.

Los servicios empresariales son idempotentes para asegurarse de que las operaciones de reintento no creen recursos duplicados. Por ejemplo, el servicio de paquetes utiliza operaciones upsert para agregar datos al almacén de datos.

Pasos siguientes

• Centralice la administración del esquema de eventos mediante el registro de esquemas en Azure Event Hubs para mantener la compatibilidad a medida que evolucionan los servicios.

• Revise las opciones de mensajería asincrónica en Azure para obtener información sobre las distintas opciones de infraestructura disponibles para implementar un flujo de trabajo descentralizado.

• Evalúe las funcionalidades técnicas de diferentes plataformas para elegir el servicio de mensajería de Azure adecuado para sus requisitos de coreografía específicos.

Recursos relacionados

Tenga en cuenta estos patrones en el diseño para la coreografía:

• Modularice el servicio empresarial mediante el patrón Ambassador.

• Implemente el patrón de nivelación de carga basado en colas para controlar los picos de la carga de trabajo.

• Use la mensajería distribuida asincrónica a través del patrón Publisher-Subscriber.

• Use transacciones de compensación para deshacer una serie de operaciones exitosas si una o más operaciones relacionadas fallan.