Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure Event Grid
Azure Blob Storage
El patrón Claim-Check permite que las aplicaciones transfieran datos sin almacenar estos datos en un sistema de mensajería. El patrón almacena la carga útil en un almacén de datos externo y usa un "comprobante de validación" para recuperar la carga útil. El comprobante es un token o clave único y oscuro. Para recuperar la carga, las aplicaciones deben presentar el token de comprobante al almacén de datos externo.
Contexto y problema
Los sistemas de mensajería tradicionales están optimizados para gestionar un gran volumen de mensajes pequeños y suelen tener restricciones en cuanto al tamaño de los mensajes que pueden manejar. Los mensajes de gran tamaño no solo conllevan el riesgo de superar estos límites, sino que también pueden degradar el rendimiento de todo el sistema cuando el sistema de mensajería los almacena.
Solución
Utilice el patrón Claim-Check y no envíe mensajes de gran tamaño al sistema de mensajería. En su lugar, envíe la carga a un almacén de datos externo y genere un token de comprobante para esa carga. El sistema de mensajería envía un mensaje con el token de comprobante a las aplicaciones receptoras para que estas puedan recuperar la carga del almacén de datos. El sistema de mensajería nunca ve o almacena la carga.
Diagrama del patrón Claim-Check.
- Carga útil
- Guarde la carga en el almacén de datos.
- Genere el token de comprobante y envíe un mensaje con el token de comprobante.
- Reciba el mensaje y lea el token de comprobante.
- Recupere la carga.
- Procesar la carga.
Problemas y consideraciones con el patrón Claim-Check
Tenga en cuenta las siguientes recomendaciones al implementar el patrón de verificación:
Elimine los mensajes consumidos. Si no necesita archivar el mensaje, elimine el mensaje y la carga una vez que las aplicaciones receptoras la consuman. Use una estrategia de eliminación sincrónica o asincrónica:
Eliminación sincrónica: la aplicación que consume elimina el mensaje y la carga inmediatamente después del consumo. Vincula la eliminación al flujo de trabajo de manejo de mensajes y utiliza la capacidad de cálculo del flujo de trabajo de mensajería.
Eliminación asincrónica: un proceso fuera del flujo de trabajo de procesamiento de mensajes elimina el mensaje y la carga. Desacopla el proceso de eliminación del flujo de trabajo de manejo de mensajes y minimiza el uso del cómputo de flujo de trabajo de mensajería.
Implemente el patrón condicionalmente. Incorpore una lógica en la aplicación de envío que aplica el patrón Claim-Check si el tamaño del mensaje supera el límite del sistema de mensajería. Para mensajes más pequeños, omita el patrón y envíe el mensaje más pequeño al sistema de mensajería. Este enfoque condicional reduce la latencia, optimiza el uso de los recursos y mejora el rendimiento.
Cuándo usar el patrón Claim-Check
Los siguientes escenarios son los casos de uso principales para el patrón Claim-Check:
Limitaciones del sistema de mensajería: use el patrón "Claim-Check" cuando los tamaños de mensaje superen los límites de su sistema de mensajería. Descargue la carga en el almacenamiento externo. Envíe solo el mensaje con su token de comprobante al sistema de mensajería.
Rendimiento del sistema de mensajería: utilice el patrón de Claim-Check cuando los mensajes de gran tamaño estén sobrecargando el sistema de envío de mensajes y degradando el rendimiento del sistema.
Los siguientes escenarios son casos de uso secundarios del patrón Claim-Check.
Protección de datos confidenciales: use el patrón Claim-Check cuando las cargas contengan datos confidenciales que no desea que sean visibles para el sistema de mensajería. Aplique el patrón a toda o a parte de la información confidencial de la carga. Proteja los datos confidenciales sin transmitirlos directamente a través del sistema de mensajería.
Escenarios de enrutamiento complejos: los mensajes que atraviesan varios componentes pueden provocar cuellos de botella de rendimiento debido a las tareas de serialización, deserialización, cifrado y descifrado. Utiliza el patrón Claim-Check para evitar el procesamiento directo de mensajes por los componentes intermedios.
Diseño de carga de trabajo con el patrón Claim-Check
Un arquitecto debe evaluar cómo se puede usar el patrón de Claim-Check en el diseño de su carga de trabajo para abordar los objetivos y principios descritos en los pilares de Azure Well-Architected Framework. Por ejemplo:
| 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 no proporcionan la misma fiabilidad y recuperación ante desastres que suelen estar presentes en almacenes de datos especializados. Separar los datos del mensaje puede proporcionar una mayor fiabilidad para la carga. Esta separación facilita la redundancia de datos que permite recuperar cargas después de un desastre. RE:03 Análisis del modo de fallo 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 de comprobante puede extraer datos confidenciales de mensajes y almacenarlos en un almacén de datos seguro. Esta configuración permite implementar controles de acceso más estrictos, lo que garantiza que solo los servicios destinados a usar los datos confidenciales puedan acceder a ellos. Al mismo tiempo, 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 al tamaño de los mensajes y el aumento de los límites de tamaño suele ser una característica adicional. Reducir el tamaño de los cuerpos de los mensajes puede permitirle utilizar una solución de mensajería más barata. 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 las aplicaciones de envío y recepción y del sistema de mensajería al gestionar los mensajes grandes de manera 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 grandes solo cuando sea necesario. PE:05 Escalado y particiones PE:12 Optimización continua del rendimiento |
Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.
Ejemplos de patrones de verificación de reclamos
En los ejemplos siguientes se muestra cómo Azure facilita la implementación del patrón de Claim-Check:
Azure sistemas de mensajería: Los ejemplos abarcan cuatro escenarios diferentes del sistema de mensajería de Azure: Azure Queue Storage, Azure Event Hubs (API estándar), Azure Service Bus y Azure Event Hubs ( API de Kafka).
Generación automática frente a manual de tokens de comprobante: estos ejemplos también muestran dos métodos para generar el token de comprobante. En los ejemplos de código 1 a 3, Azure Event Grid genera automáticamente el token cuando la aplicación de envío transfiere la carga a Azure Blob Storage. En el ejemplo de código 4 se muestra un proceso de generación manual de tokens mediante un cliente de línea de comandos ejecutable.
Elija el ejemplo que se adapte a sus necesidades y siga el vínculo proporcionado para ver el código en GitHub:
| Código de ejemplo | Escenarios del sistema de mensajería | Generador de token | Aplicación receptora | Almacén de datos |
|---|---|---|---|---|
| Código de ejemplo 1 | Azure Queue Storage | Azure Event Grid | Función | Azure Blob Storage (Almacenamiento de objetos Blob de Azure) |
| Código de ejemplo 2 | Azure Event Hubs (API estándar) | Azure Event Grid | Cliente de línea de comandos ejecutable | Azure Blob Storage (Almacenamiento de objetos Blob de Azure) |
| Código de ejemplo 3 | Azure Service Bus | Azure Event Grid | Función | Azure Blob Storage (Almacenamiento de objetos Blob de Azure) |
| Código de ejemplo 4 | Azure Event Hubs (API de Kafka) | Cliente de línea de comandos ejecutable | Función | Azure Blob Storage (Almacenamiento de objetos Blob de Azure) |
Pasos siguientes
- El sitio de patrones de integración empresarial contiene una descripción de este patrón.
- Para obtener otro ejemplo, consulte Cómo gestionar mensajes grandes de Service Bus utilizando el patrón de verificación de reclamos (entrada de blog).
- Un patrón alternativo para administrar mensajes de gran tamaño es el patrón de División y agregación.
- Las bibliotecas como NServiceBus proporcionan soporte para este patrón con su funcionalidad DataBus.
Recursos relacionados
- Patrón asincrónico de solicitud-respuesta
- Patrón de consumidores concurrentes
- Patrón de convoy secuencial