Estilo de arquitectura Web-Queue-Worker

Los componentes principales de esta arquitectura son un front-end web que controla las solicitudes de cliente y un trabajo que realiza tareas que consumen muchos recursos, flujos de trabajo de larga duración o trabajos por lotes. El front-end web se comunica con el trabajador a través de una cola de mensajes.

Los siguientes componentes se suelen incorporar en esta arquitectura:

• Una o varias bases de datos

• Caché para almacenar valores de la base de datos para lecturas rápidas

• Una red de entrega de contenido para servir contenido estático

• Servicios remotos, como el correo electrónico o el servicio de mensajes cortos (SMS), que normalmente proporcionan proveedores de servicios que no son de Microsoft

• Proveedor de identidades para la autenticación

La web y el trabajo no tienen estado y el estado de sesión se puede almacenar en una caché distribuida. El trabajador gestiona tareas de ejecución prolongada de forma asincrónica. Los mensajes de la cola pueden iniciar el trabajo o una programación puede ejecutarlos para el procesamiento por lotes. El trabajador es opcional si la aplicación no tiene operaciones de larga ejecución.

El front-end puede incluir una API web. Una aplicación de página única puede consumir la API web realizando llamadas AJAX o una aplicación cliente nativa puede consumirla directamente.

Cuándo usar esta arquitectura

Normalmente, la arquitectura Web-Queue-Worker se implementa mediante servicios de cómputo administrados como Azure App Service o Azure Kubernetes Service.

Tenga en cuenta esta arquitectura para los siguientes casos de uso:

• Aplicaciones que tienen un dominio relativamente sencillo

• Aplicaciones que tienen flujos de trabajo de ejecución prolongada o operaciones por lotes

• Escenarios en los que prefiere servicios administrados sobre la infraestructura como servicio (IaaS)

Ventajas

• Arquitectura sencilla y fácil de seguir

• Implementación y administración con un esfuerzo mínimo

• Separación clara de responsabilidades

• Desacoplamiento del front-end y del trabajo mediante mensajería asincrónica

• Escalado independiente del front-end y el trabajo

Desafíos

• Sin un diseño cuidadoso, el frontend y el trabajador pueden convertirse en grandes componentes monolíticos que son difíciles de mantener y actualizar.

• Si el front end y el trabajador comparten esquemas de datos o módulos de código, puede haber dependencias ocultas.

• La interfaz web puede fallar después de persistir en la base de datos, pero antes de enviar mensajes a la cola, lo que provoca problemas de coherencia porque el trabajador no realiza su parte de la lógica. Para mitigar este problema, puede usar técnicas como el patrón de Bandeja de Salida Transaccional, que requiere que los mensajes salientes se enruten primero para volver a pasar por una cola independiente. La biblioteca de sesión transaccional NServiceBus admite esta técnica.

procedimientos recomendados

• Exponga una API bien diseñada al cliente. Para más información, consulte Procedimientos recomendados de diseño de API.

• Escale automáticamente para controlar los cambios en la carga. Para obtener más información, consulte Procedimientos recomendados de escalado automático.

• Almacenar en caché datos semistáticos. Para obtener más información, consulte Procedimientos recomendados de almacenamiento en caché.

• Use una red de entrega de contenido para hospedar contenido estático. Para obtener más información, consulte Procedimientos recomendados de red de entrega de contenido.

• Utilice la persistencia políglota cuando sea apropiado. Para más información, consulte Descripción de los modelos de datos.

• Cree particiones de datos para mejorar la escalabilidad, reducir la contención y optimizar el rendimiento. Para obtener más información, consulte Procedimientos recomendados de creación de particiones de datos.

Web:Queue-Worker en App Service

En esta sección se describe una arquitectura recomendada denominada Web-Queue-Worker que utiliza App Service.

Diagrama de arquitectura que muestra a los usuarios que acceden a las aplicaciones web a través de Azure CDN para la entrega de contenido estático. El tráfico fluye a aplicaciones web de App Service que controlan las solicitudes de usuario y envían mensajes a las colas de Azure Service Bus o Azure Storage. Los procesos de Azure Functions gestionan mensajes de las colas para manejar tareas que consumen muchos recursos. El sistema incluye Azure Managed Redis para el estado de sesión y el acceso a datos de baja latencia, Azure Blob Storage para almacenamiento de archivos y documentos y almacenamiento de datos poliglot con Azure SQL Database y Azure Cosmos DB. Tanto las aplicaciones web como las funciones se ejecutan en planes de App Service para la infraestructura de proceso.

Descargue un archivo de Visio de esta arquitectura.

Flujo de trabajo

• El front end se implementa como una aplicación web de App Service y el worker se implementa como una aplicación de Azure Functions. La aplicación web y la aplicación de Functions están asociadas a un plan de App Service que proporciona las instancias de máquina virtual (VM).

• Puede usar ya sea Azure Service Bus o las colas de Azure Storage para la cola de mensajes. En el diagrama anterior se usa una cola de almacenamiento.

• Azure Managed Redis almacena el estado de sesión y otros datos que requieren acceso de baja latencia.

• Azure Content Delivery Network se usa para almacenar en caché contenido estático como imágenes, CSS o HTML.

• Para el almacenamiento, elija las tecnologías que mejor se adapten a las necesidades de la aplicación. Este enfoque, conocido como persistencia políglota, usa varias tecnologías de almacenamiento en el mismo sistema para cumplir distintos requisitos. Para ilustrar esta idea, el diagrama muestra Tanto Azure SQL Database como Azure Cosmos DB.

Para obtener más información, consulte Aplicación web de base altamente disponible y redundante por zonas y Desarrollar aplicaciones empresariales impulsadas por mensajes con NServiceBus y Service Bus.

Otras consideraciones

• No todas las transacciones deben pasar por la cola y el trabajo al almacenamiento. El front-end web puede realizar operaciones sencillas de lectura y escritura directamente. Los trabajadores están diseñados para tareas intensivas en recursos o flujos de trabajo de ejecución prolongada. En algunos casos, es posible que no necesite un trabajador.

• Usa la característica de escalabilidad automática integrada de la plataforma de computación para ampliar el número de instancias. Si la carga en la aplicación sigue patrones predecibles, use el escalado automático basado en horarios. Si la carga es impredecible, use el escalado automático basado en métricas.

• Considere la posibilidad de colocar la aplicación web y la aplicación de Functions en planes de App Service independientes para que se puedan escalar de forma independiente.

• Utilice planes de App Service distintos para producción y pruebas.

• Use las ranuras de implementación para administrar implementaciones. Este método permite implementar una versión actualizada en un espacio de ensayo y, a continuación, intercambiar a la nueva versión. También le permite volver a cambiar a la versión anterior si hay un problema durante la actualización.

Recurso relacionado

• patrón de nivelación de cargaQueue-Based