Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Quando si crea una macchina a stati, è necessario scegliere un tipo Standard (predefinito) o Express, denominato comunemente flusso di lavoro standard o flusso di lavoro rapido.
È possibile definire entrambi i tipi di macchine a stati utilizzandoUtilizzo di Amazon States Language per definire i flussi di lavoro Step Functions.
Sia i flussi di lavoro standard che quelli rapidi possono iniziare in risposta a eventi, come richieste HTTP da Amazon API Gateway, regole IoT e oltre 140 altre fonti di eventi in Amazon EventBridge.
Il tipo di flusso di lavoro è immutabile
Il tipo di workflow non può essere aggiornato dopo aver creato una macchina a stati.
I flussi di lavoro standard sono ideali per flussi di lavoro di lunga durata (fino a un anno), durevoli e verificabili. Puoi recuperare la cronologia completa delle esecuzioni utilizzando l'API Step Functions per un massimo di 90 giorni dopo il completamento dell'esecuzione.
I flussi di lavoro standard seguono un exactly-oncemodello, in cui le attività e gli stati non vengono mai eseguiti più di una volta, a meno che non sia stato specificato un Retry
comportamento in ASL. Il exactly-once questo modello rende i flussi di lavoro standard adatti a orchestrare azioni non idempotenti, come l'avvio di un cluster Amazon EMR o l'elaborazione dei pagamenti.
Le esecuzioni dei flussi di lavoro standard vengono fatturate in base al numero di transizioni di stato elaborate.
I flussi di lavoro Express sono ideali per carichi di lavoro di elaborazione di eventi ad alto volume come l'ingestione di dati IoT, l'elaborazione e la trasformazione dei dati in streaming e i backend di applicazioni mobili. L'esecuzione può durare fino a cinque minuti.
Express Workflows utilizza un at-least-oncemodello, quindi un'esecuzione potrebbe potenzialmente essere eseguita più di una volta. Il at-least-once il modello rende Express Workflows più adatto per orchestrare azioni idempotenti, come la trasformazione dei dati di input da archiviare in Amazon DynamoDB utilizzando un'azione PUT.
Le esecuzioni Express Workflow vengono fatturate in base al numero di esecuzioni, alla durata totale dell'esecuzione e alla memoria consumata durante l'esecuzione.
Suggerimento
Per implementare un esempio di flusso di lavoro Express, consulta Elaborazione dei dati in parallelo
Confronto tra i tipi di flusso di lavoro Standard ed Express
Tipo/Categoria | Flussi di lavoro Standard | Flussi di lavoro rapidi: sincroni e asincroni |
---|---|---|
Durata massima | Un anno | Cinque minuti |
Frequenza di avvio dell'esecuzione supportata |
Per informazioni sulle quote relative alla frequenza di avvio dell'esecuzione supportata, vedereQuote relative alla limitazione delle azioni delle API. |
Per informazioni sulle quote relative alla frequenza di avvio dell'esecuzione supportata, vedere. Quote relative alla limitazione delle azioni delle API |
Frequenza di transizione dello stato supportata |
Per informazioni sulle quote relative alla velocità di transizione degli stati supportata, vedere. Quote relative alla limitazione statale |
Nessun limite |
Prezzi |
Prezzo in base al numero di transizioni di stato. Una transizione di stato viene conteggiata ogni volta che viene completata una fase dell'esecuzione. | Il prezzo è calcolato in base al numero di esecuzioni eseguite, alla loro durata e al consumo di memoria. |
Cronologia delle esecuzioni |
Le esecuzioni possono essere elencate e descritte con Step Functions APIs. Le esecuzioni possono essere sottoposte a debug visivi tramite la console. Possono anche essere ispezionate in CloudWatch Logs abilitando la registrazione sulla macchina a stati. Per ulteriori informazioni sul debug delle esecuzioni Standard Workflow nella console, consulta e. Differenze di esperienza tra console Standard ed Express Visualizzazione delle esecuzioni del workflow |
Cronologia di esecuzione illimitata, ovvero vengono mantenute tutte le voci della cronologia di esecuzione che è possibile generare in un periodo di 5 minuti. Le esecuzioni possono essere controllate in CloudWatch Logs o nella console Step Functions abilitando la registrazione sulla macchina a stati. Per ulteriori informazioni sul debug delle esecuzioni di Express Workflow nella console, consulta e. Differenze di esperienza tra console Standard ed Express Visualizzazione delle esecuzioni del workflow |
Semantica di esecuzione | Exactly-onceesecuzione del flusso di lavoro. | Flussi di lavoro Express asincroni: At-least-onceesecuzione del flusso di lavoro. Flussi di lavoro Synchronous Express: At-most-onceesecuzione del flusso di lavoro. |
Integrazioni dei servizi | Supporta tutte le integrazioni e i modelli di servizi. | Supporta tutte le integrazioni di servizi. NotaI flussi di lavoro Express non supportano i modelli di integrazione dei servizi Job-run ( |
Mappa distribuita | Supportato | Non supportato |
Attività | Supportato | Non supportato |
Ottimizza il tipo di workflow
Per un confronto e un esempio di analisi dell'impatto sui costi, vedere Scelta del tipo di flusso di lavoro
Flussi di lavoro Express sincroni e asincroni in Step Functions
È possibile scegliere tra due tipi di flussi di lavoro Express: flussi di lavoro Express asincroni e flussi di lavoro Express sincroni.
-
I flussi di lavoro Asynchronous Express confermano che il flusso di lavoro è stato avviato, ma non aspettate il completamento del flusso di lavoro. Per ottenere il risultato, è necessario eseguire il polling dei log del servizio. CloudWatch Puoi utilizzare Asynchronous Express Workflows quando non hai bisogno di un output di risposta immediato, come i servizi di messaggistica o l'elaborazione dei dati da cui altri servizi non dipendono. È possibile avviare Asynchronous Express Workflows in risposta a un evento, tramite un flusso di lavoro annidato in Step Functions o utilizzando la chiamata API.
StartExecution
-
Synchronous Express Workflows avvia un flusso di lavoro, attende il completamento e quindi restituisce il risultato. I flussi di lavoro Synchronous Express possono essere utilizzati per orchestrare i microservizi. Con Synchronous Express Workflows, puoi sviluppare applicazioni senza la necessità di sviluppare codice aggiuntivo per gestire errori, nuovi tentativi o eseguire attività parallele. Puoi eseguire Synchronous Express Workflows richiamati da Amazon API Gateway o utilizzando la
StartSyncExecution
chiamata API. AWS LambdaNota
Se esegui Step Functions Express Workflows in modo sincrono dalla console, la
StartSyncExecution
richiesta scade dopo 60 secondi. Per eseguire Express Workflows in modo sincrono per una durata massima di cinque minuti, effettua laStartSyncExecution
richiesta utilizzando l' AWS SDK o AWS Command Line Interface (AWS CLI) anziché la console Step Functions.Le chiamate all'API di esecuzione sincrona di Express non contribuiscono ai limiti di capacità degli account esistenti. Step Functions fornisce capacità su richiesta e si ridimensiona automaticamente con un carico di lavoro sostenuto. I picchi di carico di lavoro possono essere limitati fino a quando la capacità non sarà disponibile.
Garanzie di esecuzione nei flussi di lavoro Step Functions
Flussi di lavoro Standard | Flussi di lavoro Express asincroni | Flussi di lavoro Express sincroni |
---|---|---|
Exactly-onceesecuzione del flusso di lavoro | At-least-onceesecuzione del flusso di lavoro | At-most-onceesecuzione del flusso di lavoro |
Lo stato di esecuzione persiste internamente tra le transizioni di stato. | Lo stato di esecuzione non persiste tra le transizioni di stato. | Lo stato di esecuzione non persiste tra le transizioni di stato. |
Restituisce automaticamente una risposta idempotente all'avvio di un'esecuzione con lo stesso nome di un workflow attualmente in esecuzione. Il nuovo flusso di lavoro non si avvia e viene generata un'eccezione una volta completato il flusso di lavoro attualmente in esecuzione. | L'idempotenza non viene gestita automaticamente. L'avvio di più flussi di lavoro con lo stesso nome comporta esecuzioni simultanee. Può causare la perdita dello stato interno del flusso di lavoro se la logica della macchina a stati non è idempotente. | L'idempotenza non viene gestita automaticamente. Step Functions attende l'avvio di un'esecuzione e restituisce il risultato della macchina a stati al termine. I flussi di lavoro non si riavviano se si verifica un'eccezione. |
Dati della cronologia di esecuzione rimossi dopo 90 giorni. I nomi dei flussi di lavoro possono essere riutilizzati dopo la rimozione dei dati di out-of-date esecuzione. Per soddisfare i requisiti di conformità, organizzativi o normativi, è possibile ridurre il periodo di conservazione della cronologia di esecuzione a 30 giorni inviando una richiesta di quota. A tale scopo, utilizza AWS Support Center Console e crea un nuovo caso. |
La cronologia delle esecuzioni non viene acquisita da Step Functions. La registrazione deve essere abilitata tramite Amazon CloudWatch Logs. | La cronologia delle esecuzioni non viene acquisita da Step Functions. La registrazione deve essere abilitata tramite Amazon CloudWatch Logs. |