Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Elegir el tipo de flujo de trabajo en Step Functions
Al crear una nueva máquina de estado, debe seleccionar un Tipo que sea Estándar o bien Rápido. El Tipo predeterminado para las máquinas de estado es Estándar. Una máquina de estado cuyo Tipo es Estándar se denomina Flujo de trabajo estándar y una máquina de estado cuyo Tipo es Rápido se denomina Flujo de trabajo rápido.
Se define la máquina de estados mediante Uso del lenguaje de Amazon States para definir los flujos de trabajo de Step Functions tanto para los flujos de trabajo estándar como rápidos. Las ejecuciones de la máquina de estado se comportarán de forma diferente en función del Type que seleccione.
importante
El tipo de flujo de trabajo que elija no se puede cambiar después de crear la máquina de estados.
Los flujos de trabajo estándar y exprés pueden iniciarse automáticamente en respuesta a eventos como HTTP las solicitudes de Amazon API Gateway (totalmente gestionadas APIs a escala), las reglas de IoT y más de 140 fuentes de eventos más en Amazon EventBridge.
Los flujos de trabajo estándar son ideales para flujos de trabajo auditables, duraderos y de larga duración (hasta un año). Puede recuperar el historial de ejecución completo mediante Step Functions API hasta 90 días después de que se complete la ejecución. Los flujos de trabajo estándar siguen un modelo que funciona exactamente una vez, en el que las tareas y los estados nunca se ejecutan más de una vez, a menos que haya especificado Retry un comportamiento en. ASL Esto hace que los flujos de trabajo estándar sean adecuados para organizar acciones no idempotentes, como iniciar un EMR clúster de Amazon o procesar pagos. Las ejecuciones de flujos de trabajo estándar se facturan de acuerdo con el número de transiciones de estado que se han procesado.
Los flujos de trabajo express son ideales para cargas de trabajo de procesamiento de eventos de gran volumen, como la ingesta de datos de IoT, el procesamiento y la transformación de datos en streaming y los backends de aplicaciones móviles. Pueden ejecutarse durante un máximo de 5 minutos. Los flujos de trabajo de Express utilizan un at-least-oncemodelo en el que una ejecución podría ejecutarse más de una vez. Esto hace que Express Workflows sea ideal para organizar acciones idempotentes, como la transformación de los datos de entrada y el almacenamiento mediante una PUT acción en Amazon DynamoDB. Las ejecuciones de Express Workflow se facturan según el número de ejecuciones, la duración total de la ejecución y la memoria consumida durante la ejecución.
sugerencia
Para implementar un ejemplo de flujo de trabajo de Express, consulte Parallel State
Comparación de los tipos de flujo de trabajo estándar y exprés
| Tipo o categoría | Flujos de trabajo estándar | Flujos de trabajo rápidos: síncronos y asíncronos |
|---|---|---|
| Duración máxima | Un año | Cinco minutos |
| Velocidad de inicio de ejecución admitida |
Para obtener información sobre las cuotas relacionadas con la velocidad de inicio de ejecución admitida, consulte Cuotas relacionadas con la limitación API de las acciones. |
Para obtener información sobre las cuotas relacionadas con la velocidad de inicio de ejecución admitida, consulte Cuotas relacionadas con la limitación API de las acciones. |
| Velocidad de transición de estado admitida |
Para obtener información sobre las cuotas relacionadas con la velocidad de transición de estado admitida, consulte Cuotas relacionadas con la limitación controlada de estados. |
Sin límite |
| Precios |
El precio se basa en el número de transiciones de estado. Una transición de estado se cuenta cada vez que se completa un paso de la ejecución. | El precio varía en función del número de ejecuciones que realice, la duración y el consumo de memoria. |
| Historial de ejecuciones |
Las ejecuciones se pueden enumerar y describir con Step FunctionsAPIs. Las ejecuciones se pueden depurar visualmente a través de la consola. También se pueden inspeccionar en CloudWatch los registros habilitando el registro en su máquina de estados. Para obtener más información sobre cómo depurar las ejecuciones de flujos de trabajo estándar en la consola, consulte Las consolas Standard y Express experimentan diferencias y Ver las ejecuciones del flujo de trabajo. |
El historial de ejecuciones es ilimitado, es decir, se conservan tantas entradas del historial de ejecuciones como se puedan generar en un período de 5 minutos. Las ejecuciones se pueden inspeccionar en CloudWatch Logs o en la consola Step Functions activando el registro en la máquina de estados. Para obtener más información sobre cómo depurar las ejecuciones de flujos de trabajo rápidos en la consola, consulte Las consolas Standard y Express experimentan diferencias y Ver las ejecuciones del flujo de trabajo. |
| Semántica de ejecuciones | Ejecución del flujo de trabajo exactamente una vez. | Flujos de trabajo exprés asíncronos: ejecución de un t-least-once flujo de trabajo. Flujos de trabajo exprés sincrónicos: una ejecución de un flujo de trabajo. t-most-once |
| Integraciones de servicios | Admite todos los patrones y las integraciones de servicios. | Admite todas las integraciones de servicios. notaLos flujos de trabajo rápidos no admiten patrones de integración de servicios Job-run ( |
| Mapa distribuido | Compatible | No compatible |
| Actividades | Compatible | No compatible |
Optimice el tipo de flujo de
En el taller de procesamiento de datos a gran escala, consulte el módulo Elegir el tipo de flujo de trabajo (taller)
Flujos de trabajo exprés sincrónicos y asíncronos en Step Functions
Puede elegir entre dos tipos de flujos de trabajo rápidos: flujos de trabajo rápidos asíncronos y flujos de trabajo rápidos síncronos.
-
Los flujos de trabajo rápidos asíncronos devuelven una confirmación de que el flujo de trabajo se ha iniciado, pero no esperan a que se complete. Para obtener el resultado, debe sondear los registros del servicio. CloudWatch Puede utilizar flujos de trabajo rápidos asíncronos cuando no necesite una salida de respuesta inmediata, como en los servicios de mensajería o en el procesamiento de datos del que no dependen otros servicios. Puede iniciar flujos de trabajo exprés asíncronos en respuesta a un evento, mediante un flujo de trabajo anidado en Step Functions o mediante la llamada.
StartExecutionAPI -
Los flujos de trabajo rápidos síncronos inician un flujo de trabajo, esperan a que se complete y, a continuación, devuelven el resultado. Los flujos de trabajo rápidos síncronos se pueden utilizar para orquestar microservicios. Con flujos de trabajo rápidos síncronos, puede desarrollar aplicaciones sin necesidad de desarrollar código adicional para gestionar errores o reintentos o ejecutar tareas paralelas. Puede ejecutar Synchronous Express Workflows invocados desde Amazon API Gateway, AWS Lambda, o mediante la
StartSyncExecutionAPI llamada.nota
Si ejecuta Step Functions Express Workflows de forma sincrónica desde la consola, la
StartSyncExecutionsolicitud caduca a los 60 segundos. Para ejecutar los flujos de trabajo express de forma sincrónica durante un máximo de cinco minutos, realice laStartSyncExecutionsolicitud mediante el AWS SDKo AWS Command Line Interface (AWS CLI) en lugar de la consola Step Functions.APILas llamadas de ejecución de Synchronous Express no contribuyen a los límites de capacidad de las cuentas existentes. Step Functions proporciona capacidad bajo demanda y escala automáticamente con una carga de trabajo sostenida. Los picos de carga de trabajo pueden reducirse hasta que haya capacidad disponible.
Garantías de ejecución en los flujos de trabajo de Step Functions
| Flujos de trabajo estándar | Flujos de trabajo rápidos asíncronos | Flujos de trabajo rápidos síncronos |
|---|---|---|
| Ejecución del flujo de trabajo exactamente una vez | Una ejecución de un t-least-once flujo de trabajo | Una ejecución de un t-most-once flujo de trabajo |
| El estado de ejecución persiste internamente entre las transiciones de estado. | El estado de ejecución no persiste entre transiciones de estado. | El estado de ejecución no persiste entre transiciones de estado. |
| Devuelve automáticamente una respuesta idempotente al iniciar una ejecución con el mismo nombre que un flujo de trabajo en ejecución. El nuevo flujo de trabajo no se inicia y se produce una excepción una vez que se completa el flujo de trabajo que se está ejecutando actualmente. | La idempotencia no se gestiona automáticamente. Si se inician varios flujos de trabajo con el mismo nombre, se producen ejecuciones simultáneas. Puede provocar la pérdida del estado del flujo de trabajo interno si la lógica de la máquina de estados no es idempotente. | La idempotencia no se gestiona automáticamente. Step Functions espera una vez que se inicia una ejecución y devuelve el resultado de la máquina de estado al finalizar. Los flujos de trabajo no se reinician si se produce una excepción. |
|
Los datos del historial de ejecuciones se eliminan después de 90 días. Los nombres de los flujos de trabajo se pueden reutilizar después de eliminar los datos de out-of-date ejecución. Para cumplir con los requisitos de conformidad, organizativos o normativos, se puede reducir el periodo de retención del historial de ejecución a 30 días mediante el envío de una solicitud de cuota. Para ello, utilice la AWS Support Center Console y crea un nuevo estuche. |
Step Functions no captura el historial de ejecución. El registro debe estar habilitado a través de Amazon CloudWatch Logs. | Step Functions no captura el historial de ejecución. El registro debe estar habilitado a través de Amazon CloudWatch Logs. |
