El patrón de comprobante permite que las cargas de trabajo transfieran cargas sin almacenar la carga en un sistema de mensajería. El patrón almacena la carga en un almacén de datos externo y usa una "comprobación de notificaciones" para recuperar la carga. La comprobación de notificaciones es una clave o token único y oculto. 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
Use el patrón de comprobante 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.
- Carga útil
- Guarde la carga en el almacén de datos.
- Genere el token de comprobante y envíe un mensaje con token de comprobante.
- Reciba el mensaje y lea el token de comprobante.
- Recupere la carga.
- Procese la carga.
Problemas y consideraciones con el patrón de comprobante
Tenga en cuenta las siguientes recomendaciones al implementar el patrón de comprobante:
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 control de mensajes y usa la capacidad de proceso de 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 control de mensajes y minimiza el uso del proceso de flujo de trabajo de mensajería.
Implemente el patrón condicionalmente. Incorpore lógica en la aplicación de envío que aplica el patrón de comprobante 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 de comprobante
Los siguientes escenarios son los casos de uso principales para el patrón de comprobante:
Limitaciones del sistema de mensajería: use el patrón de comprobante cuando los tamaños de mensaje superen los límites del 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: use el patrón de comprobante cuando los mensajes de gran tamaño estén sobrecargando el sistema de mensajería y degradando el rendimiento del sistema.
Los siguientes escenarios son los casos de uso secundarios para el patrón de comprobante:
Protección de datos confidenciales: use el patrón de comprobante cuando las cargas contengan datos confidenciales que no deban ser 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. Use el patrón de comprobante para evitar el procesamiento directo de mensajes por los componentes intermedios.
Diseño de carga de trabajo con el patrón de comprobante
El arquitecto debe evaluar cómo se puede usar el patrón de comprobación de notificaciones en el diseño de su carga de trabajo para abordar los objetivos y principios tratados en los pilares del Marco de la Well-Architected de Azure. 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 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 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 de comprobante mejora la eficacia de las aplicaciones emisoras y receptoras y del sistema de 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 grandes solo cuando sea necesario. - PE:05 Escapado 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 comprobante
En los ejemplos siguientes se muestra cómo Azure facilita la implementación del patrón de comprobante:
Sistemas de mensajería de Azure: 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-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 |
| Código de ejemplo 2 | Azure Event Hubs (API estándar) | Azure Event Grid | Cliente de línea de comandos ejecutable | Azure Blob Storage |
| Código de ejemplo 3 | Azure Service Bus | Azure Event Grid | Función | Azure Blob Storage |
| Código de ejemplo 4 | Azure Event Hubs (API de Kafka) | Cliente de línea de comandos ejecutable | Función | Azure Blob Storage |
Pasos siguientes
- El sitio de patrones de integración empresarial contiene una descripción de este patrón.
- Para ver otro ejemplo, consulte Trabajo con mensajes de Service Bus grandes mediante el patrón de comprobante (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 son compatibles de serie con este patrón gracias a su funcionalidad de "bus de datos".