Los componentes principales de esta arquitectura son un front-end web que atiende solicitudes de cliente y un trabajo que realiza tareas que consumen muchos recursos, flujos de trabajo de ejecución prolongada o trabajos por lotes. El front-end web se comunica con el trabajo a través de una cola de mensajes.
Otros componentes que normalmente se incorporan a esta arquitectura son:
- Una o más bases de datos.
- Una caché para almacenar los valores de la base de datos para las lecturas rápidas.
- Una red CDN para atender contenido estático.
- Servicios remotos, como correo electrónico o un servicio de SMS. Estas características suelen proporcionarlas terceros.
- Un proveedor de identidades para la autenticación.
La web y el trabajo son ambos sin estado. El estado de sesión se puede almacenar en una memoria caché distribuida. El trabajo realiza cualquier trabajo de ejecución prolongada de forma asincrónica. El trabajo pueden desencadenarlo mensajes en la cola o se puede ejecutar 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 consistir en una API web. En el lado del cliente, una aplicación de página única que realiza llamadas AJAX o una aplicación cliente nativa puede consumir la API web.
Cuándo utilizar esta arquitectura
La arquitectura web-cola-trabajo se suele implementar mediante servicios de proceso administrados, ya sea Azure App Service o Azure Cloud Services.
Considere este estilo de arquitectura para:
- Aplicaciones con un dominio relativamente sencillo.
- Aplicaciones con algunos flujos de trabajo de ejecución prolongada u operaciones por lotes.
- Si desea utilizar servicios administrados, en lugar de infraestructura como servicio (IaaS).
Ventajas
- Arquitectura relativamente sencilla que sea fácil de entender.
- Fácil de implementar y administrar.
- Separación clara de cuestiones.
- El front-end se desacopla del trabajo mediante mensajería asincrónica.
- El front-end y el trabajo se pueden escalar de forma independiente.
Desafíos
- Sin un diseño cuidado, el front-end y el trabajo se pueden convertir en componentes grandes y monolíticos que son difíciles de mantener y actualizar.
- Puede haber dependencias ocultas si el servidor front-end y el trabajo comparten esquemas de datos o módulos de código.
- El front-end web puede funcionar mal después de persistir 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. 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 NServiceBus.
procedimientos recomendados
- Exponer una API bien diseñada al cliente. Consulte Procedimientos recomendados para el diseño de API.
- Utilizar el escalado automático para tratar los cambios en la carga. Consulte Procedimientos recomendados de escalado automático.
- Almacene en caché datos semiestáticos. Consulte Procedimientos recomendados para el almacenamiento en caché.
- Utilizar una red CDN para hospedar contenido estático. Consulte Procedimientos recomendados para la red CDN.
- Utilizar la persistencia de Polyglot cuando corresponda. Consulta [Use the best data store for the job][polyglot].
- Crear particiones de datos para mejorar la escalabilidad, reducir la contención y optimizar el rendimiento. Consulte Procedimientos recomendados para la creación de particiones de datos.
Web-cola-trabajo en Azure App Service
En esta sección se describe una arquitectura recomendada web-cola-trabajo que utiliza Azure App Service.
Descargue un archivo 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. Tanto la aplicación web como la aplicación de funciones están asociadas a un plan de App Service que proporciona las instancias de VM.
Puede usar las colas de Azure Service Bus o de 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 de Polyglot). Para ilustrar esta idea, el diagrama muestra Azure SQL Database y Azure Cosmos DB.
Para obtener 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 a través de la cola y el trabajo para ir al almacenamiento. El front-end web puede realizar directamente operaciones de lectura/escritura sencillas. 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 ningún trabajo en absoluto.
Use la característica de escalado automático integrado de App Service para escalar horizontalmente el número de instancias de máquina virtual. Si la carga de la aplicación sigue patrones predecibles, use el escalado automático basado en programación. Si la carga es imprevisible, use reglas de escalado automático basadas en métricas.
Considere la posibilidad de poner la aplicación web y la aplicación de funciones en planes de App Service separados. De este modo, pueden escalarse de manera independiente.
Use planes de App Service independientes para producción y prueba. En caso contrario, si usa el mismo plan para producción y prueba, significa que las pruebas se ejecutan en las máquinas virtuales de producción.
Utilice las ranuras de implementación para administrar implementaciones. Este método le permite implementar una versión actualizada en un espacio de ensayo e intercambiar luego a la nueva versión. También le permite volver a la versión anterior si ha habido un problema con la actualización.