Compartir a través de

Recomendaciones para desarrollar trabajos en segundo plano

  • Artículo

Se aplica a esta recomendación de lista de comprobación de confiabilidad del marco de trabajo bien diseñado de Azure:

RE:07 Refuerce la resistencia y la capacidad de recuperación de la carga de trabajo mediante la implementación de medidas de conservación y recuperación automáticas. Cree funcionalidades en la solución mediante patrones de confiabilidad basados en infraestructura y patrones de diseño basados en software para controlar errores de componentes y errores transitorios. Cree funcionalidades en el sistema para detectar errores de componentes de solución e iniciar automáticamente una acción correctiva mientras la carga de trabajo sigue funcionando con funcionalidad completa o reducida.

Guías relacionadas: Errores transitorios | Autoconservación

En esta guía se describen las recomendaciones para desarrollar trabajos en segundo plano. Los trabajos en segundo plano se ejecutan automáticamente sin necesidad de interacción del usuario. Muchas aplicaciones requieren trabajos en segundo plano que se ejecutan independientemente de la interfaz de usuario.

Algunos ejemplos de trabajos en segundo plano incluyen trabajos por lotes, tareas de procesamiento intensivo y procesos de ejecución prolongada, como flujos de trabajo. La aplicación inicia el trabajo y procesa las solicitudes interactivas de los usuarios. Por ejemplo, si una aplicación necesita generar miniaturas de imágenes que los usuarios cargan, se puede realizar un trabajo en segundo plano para generar la miniatura y guardarla en el almacenamiento. El usuario no tiene que esperar a que se complete el proceso. Como otro ejemplo, un cliente realiza un pedido, que inicia un flujo de trabajo en segundo plano que procesa el pedido. El cliente sigue explorando la aplicación web mientras se ejecuta el trabajo en segundo plano. Una vez finalizado el trabajo en segundo plano, actualiza los datos del pedido almacenado y envía un correo electrónico al cliente para confirmar el pedido.

Los trabajos en segundo plano ayudan a minimizar la carga en la interfaz de usuario de la aplicación, lo que mejora la disponibilidad y reduce el tiempo de respuesta interactivo.

Estrategias de diseño principales

Para elegir qué tarea designar como un trabajo en segundo plano, considere si la tarea se ejecuta sin interacción del usuario y si la interfaz de usuario debe esperar a que se complete la tarea. Las tareas que requieren que el usuario o la interfaz de usuario esperen mientras se ejecutan normalmente no son trabajos en segundo plano adecuados.

Evaluación de la necesidad de trabajos en segundo plano

Algunos ejemplos de trabajos en segundo plano son:

  • Trabajos de uso intensivo de la CPU, tales como cálculos matemáticos o análisis de modelo estructural.

  • Trabajos intensivos de E/S, como ejecutar una serie de transacciones de almacenamiento o archivos de indexación.

  • Trabajos por lotes, tales como actualizaciones de datos por la noche o procesamiento programado.

  • Flujos de trabajo de larga duración, como el suministro de pedidos o los servicios y sistemas de aprovisionamiento.

  • Procesamiento de datos confidenciales que transfiere la tarea a una ubicación más segura para su procesamiento. Por ejemplo, quizás no quiera procesar datos confidenciales en una aplicación web. En su lugar, puede usar un patrón como el patrón de operador de control para transferir los datos a un proceso en segundo plano aislado que tenga acceso al almacenamiento protegido.

Elegir los desencadenadores adecuados

Inicie trabajos en segundo plano con:

  • Desencadenadores controlados por eventos: un evento, normalmente una acción de usuario o un paso en un flujo de trabajo, desencadena la tarea.

  • Desencadenadores controlados por programación: una programación basada en un temporizador invoca la tarea. El trabajo se puede programar de forma periódica o para una sola ejecución.

Desencadenadores impulsados por eventos

Una acción desencadena una invocación controlada por eventos que inicia la tarea en segundo plano. Algunos ejemplos de desencadenadores controlados por eventos son:

  • La interfaz de usuario o un trabajo diferente coloca un mensaje en una cola, como se describe en el estilo arquitectónico Web-Queue-Worker. El mensaje contiene datos sobre una acción realizada anteriormente, como un cliente que realizó un pedido. El trabajo en segundo plano supervisa esta cola y detecta la llegada de un nuevo mensaje. Lee el mensaje y usa los datos del mensaje como entrada para el trabajo en segundo plano. Este patrón se denomina comunicación asincrónica basada en mensajes.

  • La interfaz de usuario o un trabajo diferente guarda o actualiza un valor que está en el almacenamiento. El trabajo en segundo plano supervisa el almacenamiento y detecta los cambios. Lee los datos y los usa como entrada para el trabajo en segundo plano.

  • La interfaz de usuario o un trabajo diferente realiza una solicitud a un punto de conexión, como un URI HTTPS o una API que se expone como un servicio web. Como parte de la solicitud, la interfaz de usuario o el trabajo transfiere los datos que requiere la tarea en segundo plano. El punto de conexión o servicio web invoca la tarea en segundo plano, que usa los datos como entrada.

Otros ejemplos de tareas que son adecuadas para la invocación controlada por eventos incluyen procesamiento de imágenes, flujos de trabajo, envío de información a servicios remotos, envío de mensajes de correo electrónico y aprovisionamiento de nuevos usuarios en aplicaciones multiinquilino.

Desencadenadores impulsados por programación

Un temporizador desencadena una invocación controlada por programación que inicia la tarea en segundo plano. Entre los ejemplos de desencadenadores controlados por programación se incluyen:

  • Un temporizador que se ejecuta localmente dentro de la aplicación o como parte del sistema operativo de la aplicación invoca regularmente una tarea en segundo plano.

  • Un temporizador que se ejecuta en una aplicación diferente, como Azure Logic Apps, envía regularmente una solicitud a una API o servicio web. La API o servicio web invoca la tarea en segundo plano.

  • Un proceso o aplicación independientes inicia un temporizador que invoca la tarea en segundo plano después de un retraso de tiempo o en un momento específico.

Otros ejemplos de tareas que son adecuadas para la invocación controlada por programación incluyen rutinas de procesamiento por lotes (como actualizar listas de productos relacionados para los clientes en función de su comportamiento reciente), tareas rutinarias de procesamiento de datos (como actualizar índices o generar resultados acumulados), análisis de datos para informes diarios, limpieza de retención de datos y comprobaciones de coherencia de datos.

Si usa una tarea controlada por programación que debe ejecutarse como una sola instancia, revise las consideraciones siguientes:

  • Si la instancia de proceso que ejecuta el programador, como una máquina virtual (VM) que usa tareas programadas de Windows, se escala, se ejecuta varias instancias del programador. Varias instancias del programador pueden iniciar varias instancias de la tarea. Para obtener más información, consulte ¿Qué significa idempotent en los sistemas de software?

  • Si las tareas se ejecutan más tiempo que el período entre los eventos del programador, el programador podría iniciar otra instancia de la tarea mientras se ejecuta la tarea anterior.

Devolver datos a la carga de trabajo

Los trabajos en segundo plano se ejecutan de forma asincrónica en un proceso independiente, o incluso en una ubicación independiente, desde la interfaz de usuario o el proceso que invocó el trabajo en segundo plano. Idealmente, los trabajos en segundo plano se activan y olvidan operaciones. Su progreso en tiempo de ejecución no tiene ningún efecto en la interfaz de usuario o en el proceso de llamada, lo que significa que el proceso de llamada no espera a que se completen las tareas. La interfaz de usuario y el proceso de llamada no pueden detectar cuándo finaliza la tarea.

Si necesita una tarea en segundo plano para comunicarse con la tarea de llamada para indicar el progreso o la finalización, debe implementar un mecanismo. Algunos ejemplos son:

  • Escriba un valor de indicador de estado en el almacenamiento al que se pueda acceder a la interfaz de usuario o a la tarea del autor de la llamada, que puede supervisar o comprobar este valor. Otros datos que devuelve la tarea en segundo plano al autor de la llamada se pueden colocar en el mismo almacenamiento.

  • Establezca una cola de respuesta que supervisa la interfaz de usuario o el autor de la llamada. La tarea en segundo plano puede enviar mensajes a la cola que indica el estado. Los datos que devuelve la tarea en segundo plano al autor de la llamada se pueden colocar en los mensajes. Para Azure Service Bus, use las ReplyTo propiedades y CorrelationId para implementar esta funcionalidad.

  • Exponer una API o punto de conexión desde la tarea en segundo plano a la que pueda acceder la interfaz de usuario o la llamada para obtener información sobre el estado. La respuesta puede incluir los datos que devuelve la tarea en segundo plano al autor de la llamada.

  • Configure la tarea en segundo plano para volver a llamar a la interfaz de usuario o al autor de la llamada a través de una API para indicar el estado en puntos predefinidos o en la finalización. Puede usar eventos generados localmente o un mecanismo de publicación y suscripción. La solicitud o la carga del evento pueden incluir los datos que devuelve la tarea en segundo plano al autor de la llamada.

Creación de particiones de trabajos en segundo plano

Si incluye trabajos en segundo plano en una instancia de proceso existente, tenga en cuenta cómo afectan estos cambios a los atributos de calidad de la instancia de proceso y al trabajo en segundo plano. Tenga en cuenta estos factores para decidir si desea colocar las tareas con la instancia de proceso existente o separarlas en otra instancia de proceso:

  • Disponibilidad: es posible que las tareas en segundo plano no necesiten el mismo nivel de disponibilidad que otras partes de la aplicación, en particular la interfaz de usuario y las partes que implican directamente la interacción del usuario. Las tareas en segundo plano pueden tener una mayor tolerancia a la latencia, los errores de conexión reintentados y otros factores que afectan a la disponibilidad, ya que las operaciones se pueden poner en cola. Sin embargo, debe haber suficiente capacidad para evitar las solicitudes de copia de seguridad que pueden bloquear las colas y afectar a toda la aplicación.

  • Escalabilidad: es probable que las tareas en segundo plano tengan requisitos de escalabilidad diferentes en comparación con la interfaz de usuario y las partes interactivas de la aplicación. Es posible que tenga que escalar la interfaz de usuario para satisfacer los picos de demanda. Las tareas en segundo plano pendientes se pueden ejecutar durante tiempos menos ocupados y con menos instancias de proceso.

  • Resistencia: si se produce un error en una instancia de proceso que hospeda solo tareas en segundo plano, es posible que no afecte gravemente a toda la aplicación. Las solicitudes de estas tareas se pueden poner en cola o posponer hasta que la tarea esté disponible. Si la instancia de proceso o las tareas se pueden reiniciar dentro de un intervalo adecuado, es posible que no afecte a los usuarios de la aplicación.

  • Seguridad: las tareas en segundo plano pueden tener diferentes requisitos de seguridad o restricciones en comparación con la interfaz de usuario u otras partes de la aplicación. Use una instancia de proceso independiente para especificar un entorno de seguridad diferente para las tareas. Para maximizar la seguridad y la separación, también puede usar patrones como Gatekeeper para aislar las instancias de proceso en segundo plano de la interfaz de usuario.

  • Rendimiento: elija el tipo de instancia de proceso para las tareas en segundo plano que coincidan específicamente con los requisitos de rendimiento de la tarea. Puede usar una opción de proceso menos costosa si las tareas no requieren las mismas funcionalidades de procesamiento que la interfaz de usuario. O bien, puede usar una instancia mayor si las tareas requieren más capacidad y recursos.

  • Capacidad de administración: las tareas en segundo plano pueden tener un ritmo de desarrollo e implementación diferente en comparación con el código de aplicación principal o la interfaz de usuario. Para simplificar las actualizaciones y el control de versiones, implemente tareas en segundo plano en una instancia de proceso independiente.

  • Costo: si agrega instancias de proceso para ejecutar tareas en segundo plano, aumenten los costos de hospedaje. Considere cuidadosamente el equilibrio entre más capacidad y costos adicionales.

Para obtener más información, consulte Patrón de elección de líder y Patrón de consumidores competidores.

Evitar conflictos de recursos

Si tiene varias instancias de un trabajo en segundo plano, podrían competir por el acceso a recursos y servicios, como bases de datos y almacenamiento. Este acceso simultáneo puede dar lugar a la contención de recursos, lo que podría provocar conflictos de disponibilidad del servicio y dañar la integridad de los datos que están en el almacenamiento. Resuelva la contención de recursos mediante un enfoque de bloqueo pesimista. Este enfoque impide que las instancias de competencia de una tarea accedan simultáneamente a un servicio o a datos dañados.

Otro enfoque para resolver conflictos es definir tareas en segundo plano como singleton, de modo que solo se ejecute una instancia. Sin embargo, este enfoque elimina las ventajas de confiabilidad y rendimiento que proporciona una configuración de varias instancias. Esta desventaja es especialmente cierta si la interfaz de usuario proporciona suficiente trabajo para mantener más de una tarea en segundo plano ocupada.

Asegúrese de que la tarea en segundo plano se pueda reiniciar automáticamente y que tenga capacidad suficiente para controlar los picos de demanda. Asigne una instancia de proceso con recursos suficientes, implemente un mecanismo de puesta en cola que almacene las solicitudes para ejecutarse cuando la demanda disminuya o use una combinación de estas técnicas.

Orquestación de varias tareas

Las tareas en segundo plano pueden ser complejas y requieren que se ejecuten varias tareas. En estos escenarios, es habitual dividir la tarea en pasos discretos más pequeños o subtareas que varios consumidores pueden ejecutar. Los trabajos de varios pasos son más eficaces y flexibles, ya que los pasos individuales suelen ser reutilizables en varios trabajos. También es fácil agregar, quitar o modificar el orden de los pasos.

Puede ser un desafío coordinar varias tareas y pasos, pero hay tres patrones comunes para guiar la solución:

  • Descompone una tarea en varios pasos reutilizables. Es posible que se requiera una aplicación para realizar diversas tareas de complejidad diferente en la información que procesa. Un enfoque sencillo pero inflexible para implementar dicha aplicación es realizar este procesamiento como módulo monolítico. Pero es probable que este enfoque reduzca las oportunidades para refactorizar el código, optimizarlo o reutilizarlo si la aplicación requiere partes del mismo procesamiento en otra parte. Para más información, consulte el artículo sobre el patrón de canalizaciones y filtros.

  • Administre la orquestación de los pasos de una tarea. Una aplicación puede realizar tareas que componen muchos pasos, algunos de los cuales pueden invocar servicios remotos o acceder a recursos remotos. A veces, los pasos individuales son independientes entre sí, pero están orquestados por la lógica de la aplicación que implementa la tarea. Para más información, consulte el patrón de supervisor de agente de programador.

  • Administre la recuperación de los pasos de tarea que producen un error. Si se produce un error en uno o varios de los pasos, es posible que una aplicación tenga que deshacer el trabajo que realiza una serie de pasos, que juntos definen una operación eventualmente coherente. Para obtener más información, consulte Patrón de compensación de transacciones.

Hacer que los trabajos sean resistentes

Cree tareas en segundo plano resistentes para proporcionar servicios confiables para la aplicación. Al planear y diseñar tareas en segundo plano, tenga en cuenta los siguientes puntos:

  • Las tareas en segundo plano deben controlar correctamente los reinicios sin dañar los datos ni introducir incoherencia en la aplicación. Para las tareas de ejecución prolongada o de varios pasos, considere la posibilidad de usar puntos de control. Use puntos de control para guardar el estado de los trabajos en el almacenamiento persistente o como mensajes en una cola. Por ejemplo, puede almacenar información de estado en un mensaje que se encuentra en una cola y actualizar incrementalmente esta información de estado con el progreso de la tarea. La tarea se puede procesar desde el último punto de control conocido en lugar de reiniciarse desde el principio.

    Para las colas de Service Bus, use sesiones de mensajes para este propósito. Con las sesiones de mensaje, guarde y recupere el estado de procesamiento de la aplicación mediante los métodos SetState y GetState . Para obtener más información sobre el diseño de procesos y flujos de trabajo de varios pasos confiables, consulte Patrón de supervisor del agente de Scheduler.

  • Cuando use las colas para comunicarse con las tareas en segundo plano, las colas pueden actuar como un búfer para almacenar las solicitudes que se envían a las tareas cuando la aplicación se encuentra con una mayor carga que la habitual. Las tareas pueden ponerse al día con la interfaz de usuario durante períodos menos ocupados y los reinicios no bloquean la interfaz de usuario. Para más información, consulte Patrón Queue-Based Load Leveling. Si algunas tareas son más importantes que otras, considere la posibilidad de implementar el patrón de cola de prioridad para asegurarse de que estas tareas se ejecutan primero.

Mensajes

Configure tareas en segundo plano iniciadas por mensajes o que procesen mensajes para controlar incoherencias, como mensajes que llegan fuera de orden, mensajes que provocan repetidamente un error (mensajes dudosos) y mensajes que se entregan más de una vez. Tenga en cuenta las recomendaciones siguientes:

  • A veces, necesita que los mensajes se procesen en un orden específico, como los mensajes que cambian los datos en función del valor de datos existente, por ejemplo, agregando un valor a un valor existente. Los mensajes no siempre llegan en el orden en que se enviaron. Además, diferentes instancias de una tarea en segundo plano pueden procesar mensajes en un orden diferente debido a cargas variables en cada instancia.

    En el caso de los mensajes que se deben procesar en un orden específico, incluya un número de secuencia, una clave u otro indicador que las tareas en segundo plano puedan usar para procesar los mensajes en el orden correcto. Para Service Bus, use sesiones de mensajes para garantizar el orden correcto de entrega. Es más eficaz diseñar el proceso para que el orden del mensaje no sea importante. Para obtener más información, consulte secuenciación de mensajes y marcas de tiempo.

  • Normalmente, una tarea en segundo plano examina los mensajes de la cola, que los oculta temporalmente de otros consumidores de mensajes. Una vez que la tarea procesa correctamente el mensaje, elimina el mensaje. Si se produce un error en una tarea en segundo plano cuando procesa un mensaje, ese mensaje vuelve a aparecer en la cola después de que expire el tiempo de espera de inspección. Una instancia diferente de la tarea procesa el mensaje o el siguiente ciclo de procesamiento de la instancia original procesa el mensaje.

    Si el mensaje provoca de forma coherente un error en el consumidor, bloquea la tarea, la cola y, finalmente, la propia aplicación cuando la cola se llena. Es fundamental detectar y quitar mensajes dudosos de la cola. Si usa Service Bus, mueva automáticamente o manualmente mensajes dudosos a una cola de mensajes fallidos asociada.

  • Las colas son al menos mecanismos de entrega una vez , pero pueden entregar el mismo mensaje más de una vez. Si se produce un error en una tarea en segundo plano después de procesar un mensaje, pero antes de eliminarlo de la cola, el mensaje estará disponible para su procesamiento de nuevo.

    Las tareas en segundo plano deben ser idempotentes, lo que significa que cuando la tarea procesa el mismo mensaje más de una vez, no produce un error o incoherencia en los datos de la aplicación. Algunas operaciones son naturalmente idempotentes, por ejemplo, si un valor almacenado se establece en un nuevo valor específico. Sin embargo, algunas operaciones provocan incoherencias, por ejemplo, si se agrega un valor a un valor almacenado existente sin comprobar que el valor almacenado sigue siendo el mismo que cuando se envió originalmente el mensaje. Configure colas de Service Bus para quitar automáticamente mensajes duplicados. Para obtener más información, consulte Procesamiento del mensaje Idempotent.

  • Algunos sistemas de mensajería, como las colas de Azure Storage y las colas de Service Bus, admiten una propiedad count de puesta en cola que indica cuántas veces se lee un mensaje de la cola. Estos datos son útiles para controlar mensajes repetidos y mensajes dudosos. Para obtener más información, consulte Patrones de identificación e identificación de mensajería asincrónica.

Hacer que los trabajos sean escalables

Las tareas en segundo plano deben ofrecer un rendimiento suficiente para asegurarse de que no bloquean la aplicación ni retrasan la operación cuando el sistema está bajo carga. Normalmente, el rendimiento mejora cuando se escalan las instancias de proceso que hospedan las tareas en segundo plano. Al planear y diseñar tareas en segundo plano, tenga en cuenta los siguientes puntos relacionados con la escalabilidad y el rendimiento:

  • Azure Virtual Machines y la característica Web Apps de App de Azure Service pueden hospedar implementaciones. Admiten el escalado automático, tanto el escalado horizontal como el escalado horizontal. El escalado automático viene determinado por la demanda y carga o una programación predefinida. Use el escalado automático para ayudar a garantizar que la aplicación tenga suficientes funcionalidades de rendimiento, al tiempo que se minimizan los costos en tiempo de ejecución.

  • Algunas tareas en segundo plano tienen una funcionalidad de rendimiento diferente en comparación con otras partes de una aplicación, por ejemplo, la interfaz de usuario o los componentes, como la capa de acceso a datos. En ese escenario, hospede las tareas en segundo plano en un servicio de proceso independiente para que la interfaz de usuario y las tareas en segundo plano se puedan escalar de forma independiente para administrar la carga. Si varias tareas en segundo plano tienen funcionalidades de rendimiento significativamente diferentes, dividalas y escale cada tipo de forma independiente. Esta técnica puede aumentar los costos en tiempo de ejecución.

  • Para evitar la pérdida de rendimiento bajo carga, es posible que también necesite escalar las colas de almacenamiento y otros recursos, por lo que un único punto de la cadena de procesamiento no provoca un cuello de botella. Tenga en cuenta otras limitaciones, como el rendimiento máximo del almacenamiento y otros servicios en los que se basan la aplicación y las tareas en segundo plano.

  • Diseñar tareas en segundo plano para el escalado. Por ejemplo, las tareas en segundo plano deben detectar dinámicamente el número de colas de almacenamiento utilizadas para supervisar los mensajes o enviar mensajes a la cola adecuada.

  • De forma predeterminada, un trabajo web se escala con su instancia de Web Apps asociada. Sin embargo, si desea que un WebJob se ejecute como una sola instancia, puede crear un archivo Settings.job que contenga los datos { "is_singleton": true }JSON . Este método obliga a Azure a ejecutar solo una instancia de WebJob, aunque haya varias instancias de la aplicación web asociada. Esta técnica es útil para los trabajos programados que deben ejecutarse como una sola instancia.

  • Los trabajos en segundo plano pueden crear desafíos para la sincronización de datos y la coordinación de procesos, especialmente si las tareas en segundo plano dependen entre sí o de otros orígenes de datos. Por ejemplo, los trabajos en segundo plano pueden controlar problemas de coherencia de datos, condiciones de carrera, interbloqueos o tiempos de espera.

  • Los trabajos en segundo plano pueden afectar a la experiencia del usuario si los resultados de las tareas en segundo plano se presentan al usuario. Por ejemplo, los trabajos en segundo plano pueden requerir que el usuario espere una notificación, actualice la página o compruebe manualmente el estado de la tarea. Estos comportamientos pueden aumentar la complejidad de la interacción del usuario y afectar negativamente a la experiencia del usuario.

Compensación: los trabajos en segundo plano introducen más componentes y dependencias en el sistema, lo que puede aumentar la complejidad y los costos de mantenimiento de la solución. Por ejemplo, los trabajos en segundo plano pueden requerir un servicio de cola independiente, un servicio de trabajo, un servicio de supervisión y un mecanismo de reintento.

Facilitación de Azure

En las secciones siguientes se describen los servicios de Azure que puede usar para hospedar, ejecutar, configurar y administrar trabajos en segundo plano.

Entornos de host

Hay varios servicios de plataforma de Azure que pueden hospedar tareas en segundo plano:

  • Web Apps y WebJobs: use la característica WebJobs de App Service para ejecutar trabajos personalizados basados en distintos scripts o programas que puede ejecutar en una aplicación web.

  • Azure Functions: use aplicaciones de funciones para trabajos en segundo plano que no se ejecuten durante mucho tiempo. También puede usar aplicaciones de funciones si hospeda la carga de trabajo en un plan de App Service infrautilizado.

  • Máquinas virtuales: si tiene un servicio de Windows o quiere usar el Programador de tareas de Windows, hospede las tareas en segundo plano en una máquina virtual dedicada.

  • Azure Batch: Batch es un servicio de plataforma que puede usar para programar el trabajo intensivo de proceso para ejecutarse en una colección administrada de máquinas virtuales. Puede escalar automáticamente los recursos de proceso.

  • Azure Kubernetes Service (AKS): AKS proporciona un entorno de hospedaje administrado para Kubernetes en Azure.

  • Azure Container Apps: con Container Apps, puede crear microservicios sin servidor basados en contenedores.

En las secciones siguientes se proporcionan consideraciones para cada una de estas opciones que le ayudarán a elegir la mejor opción.

Web Apps y WebJobs

Puede usar la característica WebJobs para ejecutar trabajos personalizados como trabajos en segundo plano en una aplicación web. Un trabajo web se ejecuta como un proceso continuo en el contexto de la aplicación web. Un trabajo web también se puede ejecutar en respuesta a un evento de desencadenador de Logic Apps o factores externos, como cambios en blobs de almacenamiento o colas de mensajes. WebJobs se puede iniciar y detener a petición y apagarse correctamente. Si se produce un error en un webJob en ejecución continua, se reiniciará automáticamente. Puede configurar las acciones de reintento y error.

Cuando configura un WebJob:

  • Si desea que el trabajo responda a un desencadenador controlado por eventos, configúrelo para Ejecutar continuamente. El script o programa se almacena en la carpeta denominada site/wwwroot/app_data/jobs/continuous.

  • Si desea que el trabajo responda a un desencadenador controlado por programación, configúrelo en Ejecutar según una programación. El script o programa se almacena en la carpeta denominada site/wwwroot/app_data/jobs/triggered.

  • Si elige la opción Ejecutar a petición al configurar un trabajo, ejecuta el mismo código que la opción Ejecutar según una programación al iniciar el trabajo.

Un trabajo web se ejecuta en el espacio aislado de la aplicación web. Tiene acceso a variables de entorno y puede compartir información, como cadena de conexión s, con la aplicación web. WebJob tiene acceso al identificador único de la máquina que ejecuta webJob. El cadena de conexión denominado AzureWebJobsStorage proporciona acceso a las colas, blobs y tablas de Storage para los datos de la aplicación. También proporciona acceso a Service Bus para la mensajería y la comunicación. El cadena de conexión denominado AzureWebJobsDashboard proporciona acceso a los archivos de registro de acciones de WebJob.

Los trabajos web tienen las siguientes características:

  • Seguridad: las credenciales de implementación de la aplicación web proporcionan protección para WebJobs.

  • Tipos de archivo admitidos: defina WebJobs mediante scripts de comandos (.cmd), archivos por lotes (.bat), scripts de PowerShell (.ps1), scripts de shell de Bash (.sh), scripts PHP (.php), scripts de Python (.py), código JavaScript (.js) y programas ejecutables (.exe y .jar).

  • Implementación: puede implementar scripts y ejecutables mediante Azure Portal, Visual Studio o el SDK de WebJobs, o bien puede copiarlos directamente en las siguientes ubicaciones:

    • Para la implementación desencadenada: site/wwwroot/app_data/jobs/triggered/<job name>

    • Para la implementación continua: site/wwwroot/app_data/jobs/continuous/<job name>

  • Archivos de registro: Console.Out se trata o marca como INFO. Console.Error se trata como ERROR. Use el portal para acceder a la información de supervisión y diagnóstico. Descargue los archivos de registro directamente desde el sitio web. Los archivos de registro se guardan en las siguientes ubicaciones:

    • Para la implementación desencadenada: Vfs/data/jobs/triggered/<job name>

    • Para la implementación continua: Vfs/data/jobs/continuous/<job name>

  • Configuración: configure WebJobs mediante el portal, la API REST y PowerShell. Use un archivo de configuración denominado settings.job, que se encuentra en el mismo directorio raíz que el script de WebJob, para proporcionar información de configuración para un WebJob. Por ejemplo:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

Consideraciones sobre Web Apps y WebJobs

  • De forma predeterminada, los trabajos web se escalan con la aplicación web. Para configurar WebJobs para que se ejecute en una sola instancia, establezca la is_singleton propiedad truede configuración en . WebJobs de instancia única es útil para las tareas que no desea escalar o ejecutar como instancias simultáneas, como la reindexación o el análisis de datos.

  • Para minimizar el efecto de WebJobs en el rendimiento de la aplicación web, cree una instancia de aplicación web vacía en un nuevo plan de App Service para hospedar WebJobs de ejecución prolongada o intensivo en recursos.

Funciones de Azure

Azure Functions es similar a WebJobs. Azure Functions es sin servidor y es más adecuado para los desencadenadores controlados por eventos que se ejecutan durante un breve período. También puede usar Azure Functions para ejecutar trabajos programados a través de desencadenadores de temporizador si configura una función para que se ejecute en momentos especificados.

Azure Functions no se recomienda para tareas grandes y de larga duración, ya que una función puede provocar tiempos de espera inesperados. Sin embargo, en función del plan de hospedaje, considere la posibilidad de usar funciones para desencadenadores controlados por programación.

Consideraciones sobre Azure Functions

Si espera que la tarea en segundo plano se ejecute durante un breve período de tiempo en respuesta a un evento, considere la posibilidad de ejecutar la tarea en el plan de consumo. Puede configurar el tiempo de ejecución en un tiempo máximo. Una función que se ejecuta más tiempo tiene un costo mayor. Los trabajos intensivos de CPU que consumen más memoria pueden ser más caros. Si usa desencadenadores adicionales para los servicios como parte de la tarea, se facturan por separado.

El plan Premium es adecuado si tiene varias tareas que son cortas, pero se ejecutan continuamente. Este plan es más caro porque necesita más memoria y más CPU. Como ventaja, puede usar otras características, como la integración de red virtual.

El plan dedicado es adecuado para trabajos en segundo plano si la carga de trabajo ya se ejecuta en el plan dedicado. Si tiene máquinas virtuales infrautilizadas, puede ejecutar el plan dedicado en la misma máquina virtual y compartir los costos de proceso.

Para más información, vea:

Virtual Machines

Puede implementar tareas en segundo plano para que no se implementen en Web Apps. Por ejemplo, puede implementar tareas mediante servicios de Windows, utilidades de terceros o programas ejecutables. También puede usar programas escritos para un entorno en tiempo de ejecución diferente al entorno que hospeda la aplicación. Por ejemplo, puede usar un programa Unix o Linux que quiera ejecutar desde una aplicación de Windows o .NET. Elija entre varios sistemas operativos para una máquina virtual de Azure y ejecute el servicio o ejecutable en esa máquina virtual.

Para más información, vea:

Para iniciar la tarea en segundo plano en una máquina virtual independiente, puede hacer lo siguiente:

  • Envíe una solicitud a un punto de conexión que la tarea expone para ejecutar la tarea a petición directamente desde la aplicación. La solicitud transfiere los datos que requiere la tarea. El punto de conexión invoca la tarea.

  • Use un programador o un temporizador del sistema operativo elegido para configurar la tarea para que se ejecute según una programación. Por ejemplo, en Windows, puede usar el Programador de tareas de Windows para ejecutar scripts y tareas. Si tiene SQL Server instalado en la máquina virtual, use Agente SQL Server para ejecutar scripts y tareas.

  • Use Logic Apps para iniciar la tarea agregando un mensaje a una cola que supervisa la tarea o enviando una solicitud a una API que expone la tarea.

Para obtener más información sobre cómo puede iniciar tareas en segundo plano, consulte la sección Desencadenadores anteriores.

Consideraciones sobre máquinas virtuales

Tenga en cuenta los siguientes puntos al implementar tareas en segundo plano en una máquina virtual de Azure:

  • Hospede tareas en segundo plano en una máquina virtual de Azure independiente para proporcionar flexibilidad y control preciso sobre el inicio, la implementación, la programación y la asignación de recursos. Sin embargo, los costos en tiempo de ejecución aumentan si implementa una máquina virtual únicamente para tareas en segundo plano.

  • No hay ninguna instalación para supervisar las tareas en el portal y no hay ninguna funcionalidad de reinicio automatizada para las tareas con errores. Pero puede usar los cmdlets de Azure Resource Manager para supervisar el estado de la máquina virtual y administrarlo. No hay ninguna instalación para controlar los procesos y subprocesos en los nodos de proceso. Normalmente, si usa una máquina virtual, debe implementar un mecanismo que recopile datos de la instrumentación en la tarea y también del sistema operativo de la máquina virtual. Puede usar el módulo de administración de System Center para Azure para este propósito.

  • Considere la posibilidad de crear sondeos de supervisión que se exponen a través de puntos de conexión HTTP. Puede configurar el código de estos sondeos para realizar comprobaciones de estado y recopilar información operativa y estadísticas. También puede usar los sondeos para intercalar la información de error y devolverla a una aplicación de administración.

Para más información, vea:

Batch

Considere Batch si necesita ejecutar cargas de trabajo de informática de alto rendimiento (HPC) grandes y paralelas en decenas, cientos o miles de máquinas virtuales.

Use Batch para preparar las máquinas virtuales, asignar tareas a las máquinas virtuales, ejecutar las tareas, supervisar el progreso y escalar horizontalmente automáticamente las máquinas virtuales en respuesta a la carga de trabajo. Batch también proporciona programación de trabajos y admite máquinas virtuales Linux y Windows.

Consideraciones sobre Batch

Batch es adecuado para cargas de trabajo intrínsecamente paralelas. Puede usar Batch para realizar cálculos paralelos con un paso de reducción al final o ejecutar aplicaciones de interfaz de paso de mensajes (MPI) para tareas paralelas que requieren el paso de mensajes entre nodos.

Un trabajo de Batch se ejecuta en un grupo de nodos o máquinas virtuales. Solo puede asignar un grupo cuando sea necesario y, a continuación, eliminarlo una vez finalizado el trabajo. Este enfoque maximiza el uso porque los nodos no están inactivos, pero el trabajo debe esperar a que asigne nodos. Como alternativa, puede crear un grupo de antemano. Este enfoque minimiza el tiempo que tarda un trabajo en iniciarse, pero puede dar lugar a nodos que se encuentran inactivos.

Para más información, vea:

Azure Kubernetes Service

Use AKS para administrar el entorno de Kubernetes hospedado para que pueda implementar y administrar fácilmente aplicaciones en contenedores.

Los contenedores son útiles para ejecutar trabajos en segundo plano. Estas son algunas de las ventajas:

  • Los contenedores admiten el hospedaje de alta densidad. Puede aislar una tarea en segundo plano en un contenedor y colocar varios contenedores en cada máquina virtual.

  • Use el orquestador de contenedores para realizar el equilibrio de carga interno, configurar la red interna y realizar otras tareas de configuración.

  • Puede iniciar y detener contenedores según sea necesario.

  • Con Azure Container Registry, puede registrar los contenedores dentro de los límites de Azure para proporcionar ventajas de seguridad, privacidad y proximidad.

Consideraciones sobre AKS

AKS requiere una comprensión de cómo usar un orquestador de contenedores.

Para más información, vea:

Aplicaciones de contenedor

Con Container Apps, puede crear microservicios sin servidor basados en contenedores. Aplicaciones de contenedor:

  • Está optimizado para ejecutar contenedores de uso general, especialmente las aplicaciones que abarcan muchos microservicios que se implementan en contenedores.

  • Tiene tecnología de Kubernetes y tecnologías de código abierto, como Dapr, Escalado automático controlado por eventos de Kubernetes (KEDA) y Envoy.

  • Admite aplicaciones y microservicios de estilo Kubernetes con características como la detección de servicios y la separación del tráfico.

  • Habilita las arquitecturas de aplicaciones controladas por eventos mediante la compatibilidad con el escalado basado en el tráfico y la extracción de orígenes de eventos como colas, incluida la escala a cero.

  • Admite procesos de ejecución prolongada y puede ejecutar tareas en segundo plano.

Consideraciones sobre Container Apps

Container Apps no proporciona acceso directo a las API de Kubernetes subyacentes. Si necesita acceso a las API de Kubernetes y al plano de control, use AKS. Si quiere compilar aplicaciones de estilo de Kubernetes y no requiere acceso directo a las API nativas de Kubernetes y a la administración de clústeres, use Container Apps para una experiencia totalmente administrada. Container Apps es más adecuado para compilar microservicios de contenedor.

Para más información, vea:

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de confiabilidad