Step Functions: Orkestrera serverlösa arbetsflöden

AWS Step Functions är en fullständigt hanterad tjänst för arbetsflödesorkestrering som samordnar distribuerade applikationer som en serie steg definierade i en tillståndsmaskin. Varje steg i tillståndsmaskinen är ett tillstånd — ett Lambda-anrop, ett AWS SDK-anrop, en väntetid, en parallell gren eller ett val (if/else). Step Functions hanterar tillstånd, hanterar nya försök och tillhandahåller en visuell körningshistorik, så att ni slipper skriva orkestreringslogik i applikationskoden.

Tillståndsmaskiner definieras i Amazon States Language (ASL), ett JSON-baserat språk. Varje tillstånd har en Type (Task, Choice, Wait, Parallel, Map, Pass, Succeed, Fail) och övergår till nästa tillstånd med Next eller avslutas. Fältet Resource i ett Task-tillstånd anger vilken AWS-tjänst som ska anropas — en ARN för Lambda eller en optimerad ARN för tjänsteintegrationer för fler än 200 AWS-tjänster utan en mellanliggande Lambda.

Step Functions har två typer av arbetsflöden. Standard Workflows: beständiga, kan köras i upp till 1 år, har exakt-en-gång-semantik och lagrar fullständig körningshistorik i 90 dagar — lämpliga för långvariga affärsprocesser. Express Workflows: hög genomströmning (över 100 000 körningar per sekund), kan köras i upp till 5 minuter, har minst-en-gång-semantik och skickar loggar till CloudWatch — lämpliga för händelsebearbetning i realtid och IoT-datapipelines. Välj utifrån krav på varaktighet, genomströmning och idempotens.

Task-tillstånd i Step Functions stöder två integrationsmönster. Request-Response: anropa en AWS-tjänst och fortsätt omedelbart (fire-and-forget). Sync Integration: anropa en tjänst och vänta tills den är klar innan ni går vidare till nästa tillstånd (t.ex. vänta på att en ECS-uppgift ska slutföras, ett Glue-jobb ska bli klart eller ett SageMaker-träningsjobb ska avslutas). Synkron integration använder suffixet :sync:2 i resursens ARN och eliminerar behovet av avfrågningslogik.

Ett Choice-tillstånd implementerar villkorsstyrd förgrening — arbetsflödesmotsvarigheten till en if/else- eller switch-sats. Ni definierar Choices som en array med villkor; det första villkoret som matchar avgör nästa tillstånd. Ett Default-tillstånd hanterar fall som inte matchar något villkor. Choice-tillstånd gör det möjligt att dirigera en order till olika leveransflöden baserat på produkttyp, kundnivå eller betalningsstatus, utan att skriva villkorslogik i Lambda.

Ett Parallel-tillstånd kör flera grenar samtidigt och väntar på att alla ska slutföras innan arbetsflödet fortsätter — användbart för samtidiga uppgifter som att köra en kreditkontroll och en lagerkontroll samtidigt. Ett Map-tillstånd itererar över en array i indata och tillämpar samma uppsättning tillstånd på varje element parallellt — användbart för att bearbeta en batch med objekt som returnerats av ett tidigare steg, till exempel för att ändra storlek på flera uppladdade bilder.

Varje Task-tillstånd i Step Functions kan ha blocken Retry och Catch för robust felhantering. Retry anger vilka feltyper som ska utlösa automatiska nya försök, med konfigurerbara IntervalSeconds, MaxAttempts och BackoffRate (multiplikator för exponentiell backoff). Catch anger reservtillstånd för fel som inte kan återställas. Denna deklarativa felhantering eliminerar behovet av upprepade try/catch-block i Lambda-funktioner.

Ett Wait-tillstånd pausar körningen av arbetsflödet under en fast tidsperiod eller tills en specifik tidsstämpel infaller. Ett Callback-mönster (med .waitForTaskToken) pausar körningen tills ett externt system anropar SendTaskSuccess eller SendTaskFailure med token. Så modellerar Step Functions steg som kräver mänskligt godkännande: skicka ett e-postmeddelande med task token, så återupptas arbetsflödet när en person klickar på en länk för att godkänna eller avslå i sitt e-postprogram.

Körningar i Step Functions kan startas av EventBridge-regler, vilket gör det enkelt att utlösa arbetsflöden som svar på händelser från AWS-tjänster. Exempelvis utlöser en S3-ObjectCreated-händelse en EventBridge-regel som startar ett bildbearbetningsarbetsflöde i Step Functions. Step Functions kan också publicera egna händelser till EventBridge när körningar lyckas eller misslyckas, vilket möjliggör övervakning och aviseringar nedströms utan att Step Functions API behöver avfrågas.

Step Functions-konsolen innehåller ett visuellt diagram över arbetsflödets körning som visar vilket tillstånd som lyckades, vilket som körs och vilket som misslyckades — färgkodat i realtid. Varje körning lagrar hela sin indata- och utdatahistorik för Standard Workflows (90 dagars lagring). För Express Workflows skickas loggar till CloudWatch Logs. Använd X-Ray tracing för att spåra svarstid från början till slut genom Lambda-funktioner och andra tjänster som anropas i arbetsflödet.

Att veta när Step Functions ska användas i stället för SQS eller EventBridge är en vanlig beslutspunkt på provet. Använd Step Functions när ni behöver synlig, tillståndsbaserad orkestrering av en process i flera steg, med felhantering och förgreningar. Använd SQS för tillförlitlig asynkron punkt-till-punkt-meddelandehantering mellan två tjänster, med nya försök via synlighetstimeout. Använd EventBridge för händelsedirigering till flera prenumeranter baserat på innehållsmönster. Ett Step Functions-arbetsflöde kan integrera alla tre: vänta på ett SQS-meddelande via en task token, publicera slutförandet till EventBridge och kedja samman Lambda- och SDK-anrop.

I den här lektionen har Ni lärt Er att: Step Functions orkestrerar arbetsflöden som tillståndsmaskiner med tillstånden Task, Choice, Parallel, Map, Wait och Catch, Standard Workflows stöder upp till ett år med fullständig körningshistorik, medan Express Workflows hanterar arbetsbelastningar med hög genomströmning och en varaktighet på under fem minuter, samt att Callback-mönstret med aktivitetstokens möjliggör godkännandesteg där en människa ingår i processen. Härnäst utforskar vi Kinesis Data Streams för realtidsbearbetning av händelser med hög genomströmning.