Mønstre for koreografi kontra orkestrering

Når mikrotjenester må samarbeide for å fullføre en forretningsprosess, finnes det to grunnleggende koordineringsmønstre. Orchestration bruker en sentral koordinator (for eksempel Step Functions) som uttrykkelig styrer hver tjeneste. Choreography har ingen sentral koordinator — tjenestene lytter etter hendelser og reagerer uavhengig av hverandre. Å forstå hvilket mønster som bør brukes, og når de bør kombineres, er en viktig arkitektferdighet som testes på SAA-C03-eksamen.

I orchestration styrer en sentral tjeneste (orkestratoren) rekkefølgen på operasjonene. Den kaller Tjeneste A, venter på svaret, kaller deretter Tjeneste B og så videre. Orkestratoren har full oversikt over prosessens tilstand, håndterer feil og nye forsøk og kan ta beslutninger basert på mellomliggende resultater. På AWS er Step Functions den kanoniske orkestratoren — den definerer hele arbeidsflyten som en tilstandsmaskin og driver hvert trinn.

I choreography kommuniserer tjenestene gjennom hendelser uten en sentral koordinator. Tjeneste A fullfører oppgaven sin og publiserer en hendelse (for eksempel OrderValidated) til en hendelsesbuss eller et topic. Tjeneste B lytter etter OrderValidated-hendelser og behandler betalingen, før den publiserer PaymentCharged. Tjeneste C lytter etter PaymentCharged og sender ordren. Hver tjeneste er autonom og løst koblet — den kjenner bare til hendelsene den konsumerer og produserer, ikke til de andre tjenestene.

På AWS er Step Functions det primære verktøyet for orchestration. For choreography er de viktigste verktøyene Amazon EventBridge (for ruting av hendelser mellom tjenester med innholdsbasert filtrering), Amazon SNS (for enkel fan-out) og Amazon SQS (for punkt-til-punkt-meldingsutveksling mellom tjenester). De kan kombinere mønstrene: bruk EventBridge til choreography på tvers av domener mellom avgrensede kontekster, og Step Functions til å orkestrere trinn innenfor ett enkelt domene.

Orchestration gir sentralisert oversikt — kjøringshistorikken i Step Functions viser nøyaktig hvor en arbeidsflyt befinner seg, hvor lang tid hvert trinn tok og hva som feilet. Feilsøking er enkelt. Choreography fordeler oversikten på flere tjenester og hendelsesbusser — sporing av én enkelt forretningstransaksjon krever at logger og hendelser fra mange tjenester sammenstilles. Derfor er choreography-systemer sterkt avhengige av korrelasjons-ID-er og distribuert sporing (AWS X-Ray) for oversikt fra ende til ende.

Choreography gir løsere kobling — å legge til en ny tjeneste som lytter etter eksisterende hendelser, krever ingen endringer i eksisterende tjenester. Hvis De for eksempel legger til en analysetjeneste som lytter etter OrderPlaced-hendelser, påvirker det ikke ordre- eller betalingstjenesten. Orchestration innfører tettere kobling mellom orkestratoren og alle tjenestene den kaller — å legge til et nytt trinn krever at tilstandsmaskindefinisjonen endres, selv om de enkelte tjenestene fortsatt er isolert.

Orchestration gjør feilhåndteringen eksplisitt — Catch-blokker i Step Functions definerer reservetilstander for hver feiltype, og hele arbeidsflytens historikk viser konteksten for feilen. I choreography er feilhåndteringen distribuert — hver tjeneste må håndtere sine egne feil og kan eventuelt publisere en feilhendelse som andre kan reagere på. Implementering av sagaer (kompenserende transaksjoner som omgjør arbeid når et trinn feiler) er langt mer komplisert i choreography enn i orchestration.

Foretrekk orchestration når: forretningsprosessen har en tydelig lineær sekvens eller forgreninger med eksplisitte resultater for suksess og feil; De trenger sentralisert oversikt over prosessstatus av hensyn til drift eller samsvarskrav; feilhåndteringen innebærer kompleks kompensasjonslogikk; eller arbeidsflyten kjører lenge og må tåle omstarter av tjenester. Eksempler er ordreoppfyllelse, onboarding av pasienter og behandling av forsikringskrav — arbeidsflyter som alle har tydelige krav til start, slutt og revisjonsspor.

Foretrekk choreography når: tjenestene eies av ulike team som ikke bør koordineres tett; systemet skal kunne utvides med nye tjenester uten at eksisterende tjenester endres; hendelser representerer fakta snarere enn kommandoer (for eksempel «OrderShipped», ikke «ShipOrder»); eller De ønsker maksimal skalerbarhet siden det ikke finnes noen sentral flaskehals. Eksempler er inntak av analysedata, utsending av varsler og revisjonslogging — tilfeller der flere uavhengige konsumenter reagerer på den samme hendelsen.

De fleste AWS-arkitekturer i den virkelige verden bruker begge mønstrene på ulike detaljnivåer. Et vanlig hybridoppsett er å bruke EventBridge choreography til å koble fra avgrensede kontekster (for eksempel at Order-domenet sender ut hendelser, mens Inventory-, Payment- og Shipping-domenene svarer uavhengig av hverandre), og samtidig bruke Step Functions orchestration i Payment-domenet til å koordinere trinnene i den interne betalingsarbeidsflyten (belaste, kontrollere svindel, autorisere og gjennomføre oppgjør). Dette gir løs kobling mellom domenene og tydelighet i de interne prosessene.

Se etter disse signalene på eksamen. Nøkkelord for choreography: «løst koblet», «tjenester reagerer på hendelser», «team eier uavhengige tjenester», «distribusjon til flere konsumenter», «legg til en ny tjeneste uten å endre eksisterende tjenester». Nøkkelord for orchestration: «koordiner trinn i en sekvens», «spor arbeidsflytens tilstand», «håndter delvise feil med kompenserende handlinger», «trinn som krever menneskelig godkjenning», «langvarig prosess med feilhåndtering». En oppgave som beskriver en sentral koordinator som styrer andre tjenester, handler alltid om orchestration.

I denne leksjonen har De lært at orchestration bruker en sentral koordinator (Step Functions) for eksplisitt og synlig kontroll over arbeidsflyten, at choreography bruker hendelser (EventBridge) for løs kobling og utvidbarhet, og at de fleste produksjonsarkitekturer kombinerer begge mønstrene på ulike detaljnivåer. Deretter skal vi se nærmere på formatet for SAA-C03-eksamen og hvordan De bør prioritere studietiden etter domenenes vekt.