Transaksjonshåndtering i mikrotjenester

I en monolittisk applikasjon håndterer én database alle transaksjoner og sikrer dataintegriteten med ACID-egenskaper (atomisitet, konsistens, isolasjon og varighet).

Med mikrotjenester er forretningslogikken delt opp på mange uavhengige tjenester, som ofte har hver sin database. Dette skaper betydelige utfordringer ved håndtering av transaksjoner som går på tvers av flere tjenester. Hvordan sikrer De at en operasjon som involverer flere tjenester, enten fullføres i sin helhet eller rulles helt tilbake?

I en monolittisk applikasjon sikrer én database transaksjonsintegriteten:

• Alle operasjoner i en forretningstransaksjon utføres i én database.
• Databasen garanterer ACID-egenskapene.

I mikrotjenester eies dataene vanligvis av hver enkelt tjeneste:

• En enkelt forretningstransaksjon kan involvere flere tjenester og databaser.
• Tradisjonelle ACID-transaksjoner kan ikke gå direkte på tvers av disse grensene.

ACID-egenskaper fungerer utmerket for enkle, sentraliserte databaser. De kan imidlertid ikke uten videre utvides til distribuerte systemer som mikrotjenester:

• Atomisitet: Det er vanskelig å garantere at alt eller ingenting skjer på tvers av uavhengige tjenester.
• Konsistens: Det er vanskelig å opprettholde umiddelbar konsistens på tvers av flere databaser.
• Isolasjon: Det er krevende å isolere samtidige endringer på tvers av tjenester.

Forsøk på å håndheve global ACID fører ofte til tett koblede tjenester og redusert skalerbarhet.

De lurer kanskje på om De ganske enkelt kan bruke en «global transaksjon» på tvers av alle mikrotjenestene. Det korte svaret er at dette vanligvis verken er praktisk eller anbefalt.

• Globale transaksjoner krever en koordinator som låser ressurser på tvers av flere databaser.
• Dette medfører betydelig belastning, reduserer ytelsen og skaper et enkelt feilpunkt.
• Det kobler tjenestene tett sammen og undergraver en sentral fordel med mikrotjenester: uavhengighet.

Denne tilnærmingen fører ofte til distribuerte vranglåser og dårlig tilgjengelighet.

I et distribuert system kan enhver tjeneste svikte når som helst, uavhengig av de andre. Dette kalles en delvis feil. Tenk på en nettbestilling:

• Order Service oppretter en bestilling.
• Payment Service behandler betalingen.
• Inventory Service trekker varen fra lagerbeholdningen.

Hvis Inventory Service svikter etter betalingen, men før lagerbeholdningen er trukket fra, er systemet i en inkonsistent tilstand: Betalingen er gjennomført, men ingen vare er trukket fra lageret.

Hvordan holder vi data konsistente på tvers av flere tjenester uten globale ACID-transaksjoner? Dette er et sentralt problem i mikrotjenester.

Tradisjonell «umiddelbar konsistens» (der alle data er konsistente rett etter en transaksjon) ofres ofte til fordel for tilgjengelighet og skalerbarhet. I stedet sikter vi ofte mot eventual konsistens.

Det betyr at dataene kan være midlertidig inkonsistente, men at systemet garanterer at de etter hvert blir konsistente.

Protokollen Two-Phase Commit (2PC) er en klassisk måte å oppnå atomiske transaksjoner på tvers av distribuerte databaser. Den består av to faser:

1. Forberedelsesfasen: En koordinator ber alle deltakerne om å forberede commit.
2. Commit-fasen: Hvis alle deltakerne er klare, ber koordinatoren dem om å utføre commit. Hvis ikke, ber den dem om å rulle tilbake.

Selv om 2PC sikrer atomisitet, har den betydelige ulemper i mikrotjenester: Den blokkerer, er treg og er utsatt for koordinatorfeil.

På grunn av begrensningene ved tradisjonell ACID og 2PC i distribuerte miljøer trenger mikrotjenestearkitekturer andre tilnærminger til håndtering av forretningstransaksjoner.

Disse alternative mønstrene innebærer ofte:

• Å dele opp store transaksjoner i mindre, uavhengige lokale transaksjoner.
• Å bruke asynkron kommunikasjon (for eksempel meldingskøer).
• Å implementere kompenserende transaksjoner for å angre handlinger hvis et senere trinn mislykkes.

Disse mønstrene prioriterer tilgjengelighet og oppdelingsrobusthet fremfor streng, umiddelbar konsistens.

Tenk på en nettbestilling som involverer flere tjenester:

1. Order Service mottar bestillingen.
2. Customer Service validerer kundens kreditt.
3. Payment Service belaster kunden.
4. Inventory Service reserverer varene.
5. Shipping Service sender bestillingen.

Hvis Inventory Service ikke klarer å reservere varene etter betalingen, trenger vi en måte å refundere kunden på. Det er her alternative mønstre kommer inn: De koordinerer disse trinnene og håndterer feil.

I denne leksjonen har vi utforsket de grunnleggende utfordringene ved håndtering av forretningstransaksjoner på tvers av flere mikrotjenester. Vi har lært at:

• Tradisjonelle ACID-egenskaper gjelder ikke direkte på tvers av tjenestegrenser.
• Globale transaksjoner (som 2PC) unngås ofte på grunn av kompleksitet, ytelsesflaskehalser og redusert tilgjengelighet.
• Delvise feil er en konstant trussel som kan føre til inkonsistente tilstander.

Disse utfordringene viser hvor viktig det er med alternative mønstre som Saga, som De skal lære om i kommende leksjoner, for å sikre datakonsistens i en distribuert verden.