Estilo de arquitectura deQueue-Worker web
Los componentes principales de esta arquitectura son un front-end web que atiende 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.
Otros componentes que normalmente se incorporan en esta arquitectura son:
- Una o varias bases de datos.
- Caché para almacenar valores de la base de datos para lecturas rápidas.
- CDN para servir contenido estático
- Servicios remotos, como el correo electrónico o el servicio SMS. A menudo, estas características las proporcionan terceros.
- Proveedor de identidades para la autenticación.
La web y el trabajo no tienen estado. El estado de sesión se puede almacenar en una caché distribuida. El trabajo realiza de forma asincrónica cualquier trabajo de larga duración. Los mensajes de la cola pueden desencadenar el trabajo o ejecutarse según una programación para el procesamiento por lotes. El trabajo es un componente opcional. Si no hay ninguna operación de ejecución prolongada, se puede omitir el trabajo.
El front-end puede constar de una API web. En el lado cliente, la API web se puede consumir mediante una aplicación de página única que realiza llamadas AJAX o mediante una aplicación cliente nativa.
Cuándo usar esta arquitectura
Normalmente, la arquitectura deQueue-Worker web se implementa mediante servicios de proceso administrados, ya sea Azure App Service o Azure Cloud Services.
Tenga en cuenta este estilo de arquitectura para:
- Aplicaciones con un dominio relativamente sencillo.
- Aplicaciones con algunos flujos de trabajo de ejecución prolongada o operaciones por lotes.
- Cuando quiera usar servicios administrados, en lugar de infraestructura como servicio (IaaS).
Ventajas
- Arquitectura relativamente sencilla que es fácil de entender.
- Fácil de implementar y administrar.
- Separación clara de preocupaciones.
- El front-end se desacopla del trabajo mediante la mensajería asincrónica.
- El front-end y el trabajador se pueden escalar de forma independiente.
Desafíos
- Sin un diseño cuidadoso, el front-end y el trabajo pueden convertirse en componentes monolíticos grandes que son difíciles de mantener y actualizar.
- Puede haber dependencias ocultas, si el front-end y el trabajo comparten esquemas de datos o módulos de código.
- El front-end web no funciona correctamente después de conservar correctamente la base de datos, pero antes de emitir los mensajes a la cola. Esto puede dar lugar a posibles problemas de coherencia, ya que el trabajo no realizará su parte de la lógica. Las técnicas como el patrón de bandeja de salida transaccional se pueden usar para ayudar a mitigar este problema, pero requieren cambiar el enrutamiento de los mensajes salientes a un primer "bucle invertido" a través de una cola independiente. Una biblioteca que proporciona compatibilidad con esta técnica es la sesión transaccional de NServiceBus.
procedimientos recomendados
- Exponga una API bien diseñada al cliente. Consulte Procedimientos recomendados de diseño de API.
- Escalado automático para controlar los cambios en la carga. Consulte procedimientos recomendados de escalado automático.
- Almacenar en caché datos semiestáticas. Consulte Procedimientos recomendados de almacenamiento en caché.
- Use una red CDN para hospedar contenido estático. Consulte Procedimientos recomendados de cdn.
- Use la persistencia poliglot cuando corresponda. Consulte [Uso del mejor almacén de datos para el trabajo][polyglot].
- Cree particiones de datos para mejorar la escalabilidad, reducir la contención y optimizar el rendimiento. Consulte Procedimientos recomendados de creación de particiones de datos.
Web:Queue-Worker en Azure App Service
En esta sección se describe una arquitectura deQueue-Worker web recomendada que usa Azure App Service.
Descargar un archivo de Visio de esta arquitectura.
Flujo de trabajo
El front-end se implementa como una aplicación web de Azure App Service y el trabajo se implementa como una aplicación de Azure Functions . La aplicación web y la aplicación de funciones están asociadas a un plan de App Service que proporciona las instancias de máquina virtual.
Puede usar Las colas de Azure Service Bus o Azure Storage para la cola de mensajes. (El diagrama muestra una cola de Azure Storage).
Azure Cache for Redis almacena el estado de sesión y otros datos que necesitan acceso de baja latencia.
Azure CDN se usa para almacenar en caché contenido estático, como imágenes, CSS o HTML.
Para el almacenamiento, elija las tecnologías de almacenamiento que mejor se adapten a las necesidades de la aplicación. Puede usar varias tecnologías de almacenamiento (persistencia políglota). Para ilustrar esta idea, el diagrama muestra Azure SQL Database y Azure Cosmos DB.
Para más información, consulte la arquitectura de referencia de aplicaciones web de App Service y cómo crear aplicaciones empresariales controladas por mensajes con NServiceBus y Azure Service Bus.
Otras consideraciones
No todas las transacciones tienen que pasar por la cola y el trabajo al almacenamiento. El front-end web puede realizar operaciones sencillas de lectura y escritura directamente. Los trabajos están diseñados para tareas que consumen muchos recursos o flujos de trabajo de ejecución prolongada. En algunos casos, es posible que no necesite un trabajador.
Use la característica de escalabilidad automática integrada de App Service para escalar horizontalmente el número de instancias de máquina virtual. Si la carga en la aplicación sigue patrones de predicción, use la escalabilidad automática basada en programación. Si la carga es impredecible, use reglas de escalado automático basadas en métricas.
Considere la posibilidad de colocar la aplicación web y la aplicación de funciones en planes de App Service independientes. De este modo, se pueden escalar de forma independiente.
Use planes de App Service independientes para producción y pruebas. De lo contrario, si usa el mismo plan para producción y pruebas, significa que las pruebas se ejecutan en las máquinas virtuales de producción.
Use 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 se produjo un problema con la actualización.