Patrón de comprobación-notificación

Almacene una carga de mensajes grande en un almacén de datos externo y envíe solo una referencia a la carga almacenada a través del sistema de mensajería. Las aplicaciones receptoras presentan el token de referencia, denominado claim check, para recuperar la carga útil de gran tamaño cuando necesiten procesarla. Este enfoque permite que las cargas de trabajo transfieran cargas grandes sin almacenarlas en el sistema de mensajería.

Contexto y problema

Los sistemas de mensajería tradicionales están optimizados para administrar un gran volumen de mensajes pequeños y, a menudo, restringen el tamaño del mensaje que pueden controlar. Los mensajes grandes no solo corren el riesgo de superar los límites de tamaño, sino que también pueden degradar el rendimiento del sistema cuando el sistema de mensajería los almacena.

Las siguientes limitaciones hacen que la transmisión de carga útil en línea a través del sistema de mensajería sea insuficiente:

  • Rechazo por límite de tamaño. Los sistemas de mensajería rechazan los mensajes que superan un máximo configurado.

  • Presión sobre los recursos del broker. Almacenar cargas útiles de gran tamaño en el broker consume una cantidad desproporcionada de memoria y espacio en disco en comparación con los metadatos que el broker necesita para encaminar y entregar el mensaje. Este consumo compite con los recursos necesarios para otros mensajes del sistema.

  • Degradación del rendimiento. Los mensajes más grandes aumentan el tiempo de serialización, transferencia y deserialización por operación.

  • Escalación de costos. Algunos sistemas de mensajería cobran por tamaño de mensaje, nivel o unidad de capacidad. Transmitir cargas útiles de gran tamaño en línea puede hacer que las cargas de trabajo pasen a niveles de mayor coste o a asignaciones de capacidad.

Solución

El patrón Claim Check separa el almacenamiento de carga de la entrega de mensajes. Una aplicación de envío escribe la carga completa en un almacén de datos externo y envía una referencia a esa carga a través del sistema de mensajería. El sistema de mensajería nunca ve o almacena la carga. Las aplicaciones receptoras usan la referencia para recuperar la carga útil directamente del almacén de datos. La referencia es un identificador que la aplicación receptora debe resolver.

Diagrama que muestra el patrón Claim Check.

El patrón sigue esta secuencia:

  1. La aplicación de envío genera la carga útil.
  2. La aplicación de envío guarda la carga en el almacén de datos externo.
  3. Una vez que el guardado se realiza correctamente, la aplicación de envío genera una referencia a la carga almacenada y la publica en el sistema de mensajería como mensaje de comprobación de notificaciones.
  4. Una aplicación receptora recupera el mensaje y lee el token de claim check.
  5. La aplicación receptora usa el token para recuperar la carga del almacén de datos.
  6. La aplicación receptora procesa la carga útil.

El sistema de mensajería solo gestiona el pequeño mensaje de comprobación, lo que evita el rechazo por tamaño del mensaje y la necesidad de usar recursos para transferir y almacenar cargas útiles de mensajes de gran tamaño. El almacén de datos externo aplica controles de acceso y directivas de ciclo de vida a la carga independiente del sistema de mensajería.

Problemas y consideraciones

Tenga en cuenta los siguientes puntos al decidir cómo implementar este patrón:

  • Titularidad del ciclo de vida de la carga. Defina qué componente posee la eliminación de la carga y cómo determina el componente que la carga no es necesaria. Coordine la expiración de los mensajes y la retención de la carga para que una comprobación de reclamación válida no apunte a datos eliminados.

  • Aplicación condicional. Decida si todos los mensajes deben usar claim checks o si la decisión de usar claim checks debe tomarse para cada mensaje. Si es condicional, garantice que el esquema especifique si la carga útil va insertada o es externa.

  • Seguridad de tokens y del almacenamiento. No incruste tokens de seguridad como parte del claim check. Deje la autorización como una interacción independiente entre los sistemas de productor o consumidor y el almacén de datos. Si tu solución requiere que se conceda explícitamente acceso temporal a los usuarios, usa en su lugar el patrón Valet Key.

  • Coherencia de la carga útil y el token. La escritura de la carga útil y la publicación del token se realizan en sistemas independientes y no forman parte de una única transacción atómica. Un fallo después de escribir la carga útil, pero antes de la publicación del token, puede dejar una carga útil huérfana. Un token publicado antes de que su carga útil sea recuperable puede implicar que los consumidores reciban referencias que no pueden resolver. Publique el token solo después de que la escritura de carga se realice correctamente. Dado que los reintentos pueden entregar el mismo claim check más de una vez, use el patrón de consumidor idempotente para procesar los duplicados de forma segura.

  • Integridad de la carga. Cuando los consumidores deben comprobar la integridad de la carga, incluya un hash de contenido o una firma digital en el mensaje. Defina un protocolo para las discrepancias, como rechazar la carga útil, volver a intentar la recuperación o redirigir el mensaje para investigarlo.

  • Disponibilidad y durabilidad de la carga útil. El almacén de datos externo debe permanecer disponible y duradero durante todo el período que las aplicaciones receptoras necesitan recuperar una carga. Si el almacenamiento sufre una interrupción o una pérdida de datos, los consumidores que tienen tókenes válidos no pueden recuperar sus cargas útiles y el procesamiento de sus mensajes se detiene.

  • Latencia de salto de recuperación. El patrón añade intercambios de red adicionales en comparación con la entrega de mensajes en línea. Las aplicaciones receptoras deben llamar al almacén de datos externo para recuperar la carga útil antes de que pueda comenzar el procesamiento.

  • Compatibilidad con claim check proporcionada por el framework. Use las funcionalidades que ofrece el SDK del bus de mensajes. Por ejemplo, NServiceBus tiene una característica dataBus que puede automatizar el almacenamiento y la recuperación de la carga útil.

Cuándo usar este patrón

Use este patrón cuando:

  • Las cargas de mensajes superan regularmente el tamaño máximo de mensaje que admite el sistema de mensajería. Derivar la carga a un almacén de datos externo y transmitir solo un token ligero de comprobación de reclamación evita rechazos por exceder el límite de tamaño.

  • Los mensajes grandes consumen una cantidad desproporcionada de recursos del broker. Los mensajes grandes afectan al rendimiento del sistema de mensajería aumentando la serialización y el tiempo de transferencia o degradando el rendimiento de todos los productores y consumidores que comparten el sistema de mensajería.

  • Las cargas contienen información confidencial que no debe ser visible para el sistema de mensajería o para componentes intermedios, como herramientas de supervisión de colas. Aplique el patrón a toda la carga o solo a sus partes confidenciales. Almacene el contenido confidencial en un almacén de datos protegido con controles de acceso dedicados para mantenerlo fuera de la ruta de acceso de mensajería.

  • Los mensajes tienen un enrutamiento complejo con serialización repetida. Los mensajes atraviesan varios componentes de enrutamiento que realizan la serialización, la deserialización, el cifrado o el descifrado. Transmita solo un pequeño token a través de intermediarios para eliminar el procesamiento repetido de la carga completa en cada salto y reducir la latencia acumulativa.

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

  • La sensibilidad a la latencia pesa más que las preocupaciones sobre el tamaño de la carga útil. Es posible que las cargas de trabajo que requieran la menor latencia posible de un extremo a otro entre el productor y el consumidor no toleran los saltos de red agregados para el almacenamiento de carga y la recuperación. Si los mensajes se pueden entregar en línea sin superar los límites de tamaño o rendimiento, la entrega directa es más sencilla y rápida.

  • Puede elegir un transporte o nivel que admita el tamaño de carga. Cuando las cargas permanecen dentro del límite admitido de un transporte y no crean un rendimiento o latencia inaceptables, envíelas en línea para evitar la dependencia del almacén externo. Por ejemplo, Azure Service Bus nivel Premium admite mensajes de Protocolo de puesta en cola avanzada (AMQP) de hasta 100 MB. Mantenga los mensajes lo más pequeños posible, ya que los mensajes grandes reducen el rendimiento y aumentan la latencia.

  • La coordinación entre dos sistemas no es posible. El patrón requiere coordinación entre dos sistemas independientes. El valor del comprobante de reclamación debe escribirse de forma que el sistema receptor pueda interpretarlo, y puede que sea necesario ajustar su formato con el tiempo.

Alternatives

Tenga en cuenta estos enfoques como alternativas a este patrón:

  • Reduzca el tamaño de la carga útil en línea. La compresión puede reducir las cargas de texto repetitivas o binarias, y un serializador más compacto puede reducir la sobrecarga de mensajes. Elija este enfoque cuando la carga reducida se ajuste cómodamente al límite de transporte y todos los productores y consumidores pueden usar el mismo formato de compresión y serialización.

  • Dividir y agrupar la carga útil de manera natural. Divida una carga grande en una secuencia de mensajes más pequeños cuando los consumidores puedan procesar fragmentos de forma independiente o volver a ensamblarlos después de la entrega. Este enfoque mantiene los datos en el sistema de mensajería, pero agrega requisitos de secuenciación, correlación, control duplicado y reensamblaje. Para obtener más información, consulte los patrones Splitter y Aggregator de Patrones de integración empresarial.

Diseño de cargas de trabajo

Evalúe cómo usar el patrón Claim Check en el diseño de una carga de trabajo para lograr los objetivos y principios descritos en los pilares de Azure Well-Architected Framework. La siguiente tabla ofrece orientación sobre cómo este patrón respalda los objetivos de los pilares.

Fundamento Cómo apoya este patrón los objetivos de los pilares
Las decisiones de diseño de fiabilidad ayudan a que su carga de trabajo sea resistente al mal funcionamiento y garantiza que se recupere por completo después de un error. Los sistemas de mensajería pueden proporcionar entrega duradera, alta disponibilidad y recuperación ante desastres, pero normalmente no proporcionan las funcionalidades de protección y recuperación de datos de nivel de carga de un almacén de datos dedicado, como el control de versiones, la copia de seguridad, la restauración a un momento dado o la replicación independiente. Almacenar la carga por separado le permite seleccionar y configurar estas funcionalidades en función de los requisitos de recuperación de carga.

- RE:03 Análisis del modo de error
- RE:09 Recuperación ante desastres
Las decisiones de diseño de seguridad ayudan a garantizar la fiabilidad, integridad y disponibilidad de los datos y sistemas de su carga de trabajo. El patrón Claim Check puede extraer datos confidenciales de los mensajes y almacenarlos en un almacén de datos seguro. Esta configuración permite controles de acceso más estrictos para que solo los servicios destinados a usar los datos confidenciales puedan acceder a ellos. El patrón también oculta estos datos de servicios no relacionados, como los usados para la supervisión de colas.

- SE:03 Clasificación de datos
- SE:04 Segmentación
La optimización de costos se centra en mantener y mejorar el retorno de la inversión de la carga de trabajo. Los sistemas de mensajería suelen imponer límites en el tamaño del mensaje y los límites de tamaño aumentado suelen ser una característica premium. Reducir el tamaño de los cuerpos de mensajes puede permitirle usar una solución de mensajería más barata. Tenga en cuenta los costes adicionales del almacenamiento de la carga útil, la transferencia por red y el procesamiento de limpieza.

- CO:07 Costos de componentes
- CO:09 Costos de flujo
La eficiencia del rendimiento ayuda a que la carga de trabajo satisfaga eficazmente las demandas mediante la optimización del escalado, la transferencia de datos y la ejecución del código. El patrón Claim Check mejora la eficiencia de los sistemas de envío, recepción y mensajería al gestionar los mensajes de gran tamaño de forma más eficaz. Reduce el tamaño de los mensajes enviados al sistema de mensajería y garantiza que las aplicaciones receptoras accedan a los mensajes de gran tamaño solo cuando sea necesario.

- PE:05 Escalado y particionamiento
- PE:12 Optimización continua del rendimiento

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

Examples

Esta sección incluye enlaces a GitHub con ejemplos del patrón en la nube Claim Check que muestran cómo los servicios de Azure implementan el patrón Claim Check. Cada ejemplo usa Azure Blob Storage como almacén de datos externo y lo empareja con un sistema de mensajería de Azure diferente. Los ejemplos del 1 al 3 usan la URL del blob en una notificación de Azure Event Grid como claim check. En el ejemplo 4 se usa un patrón Claim Check personalizado que publica la aplicación emisora.

En las muestras de 1 a 3:

  1. Una aplicación de envío carga una carga grande en Blob Storage.
  2. La carga provoca un evento Microsoft.Storage.BlobCreated mediante un tema del sistema de Event Grid.
  3. Event Grid dirige la notificación al sistema de mensajería configurado; esta contiene una dirección URL directa al blob que los ejemplos usan como comprobación de reclamación.
  4. Una aplicación receptora, implementada como una aplicación de función Azure Functions o cliente de línea de comandos, recupera la notificación, extrae la dirección URL del blob y descarga la carga directamente de Blob Storage para su procesamiento.

En una implementación de producción, se filtra la suscripción de eventos por operaciones que indican un blob en bloques totalmente confirmado y se diseña el receptor para controlar eventos retrasados, duplicados y desordenados.

El ejemplo 4 usa un enfoque diferente. En lugar de enrutar una notificación de Blob Storage a través de Event Grid, la aplicación emisora genera el claim check después de cargar el contenido en Blob Storage. A continuación, la aplicación remitente publica el claim check en el punto de conexión Kafka de Azure Event Hubs mediante el protocolo Apache Kafka. Este enfoque se adapta a los entornos que ya usan productores compatibles con Kafka o requieren formatos de token personalizados.

La siguiente tabla enumera cada ejemplo con su sistema de mensajería, el publicador de claim check, la aplicación receptora y las dependencias de almacenamiento. Seleccione cada vínculo para ver el código de ejemplo en GitHub.

Código de ejemplo Sistema de mensajería Publicador de comprobación de reclamaciones Aplicación receptora Dependencias de almacenamiento
Código de ejemplo 1 Almacenamiento de colas de Azure Event Grid Functions Almacenamiento de Blobs
Código de ejemplo 2 Event Hubs (SDK de Azure a través de AMQP) Event Grid Cliente de línea de comandos ejecutable Blob Storage para cargas y un almacén de puntos de comprobación de Blob Storage independiente
Código de ejemplo 3 Bus de Servicio Event Grid Functions Almacenamiento de Blobs
Código de ejemplo 4 Event Hubs (protocolo Apache Kafka) Cliente de línea de comandos ejecutable Functions Almacenamiento de Blobs

Pasos siguientes

  • Se actualizó por última vez el