Sagos modelis: paskirstytųjų transakcijų įgyvendinimas mikroservisams

Mikroservisų pasaulyje duomenų nuoseklumo palaikymas keliose tarnybose gali būti didelis iššūkis. Tradicinės ACID (atomiškumo, nuoseklumo, izoliacijos, patvarumo) transakcijos, dažnai naudojamos monolitinėse programose, dažnai netinka paskirstytosioms aplinkoms. Būtent čia pasitarnauja Sagos modelis, suteikiantis patikimą sprendimą valdyti paskirstytąsias transakcijas ir užtikrinti duomenų vientisumą mikroservisuose.

Kas yra Sagos modelis?

Sagos modelis yra projektavimo šablonas, naudojamas valdyti lokalių transakcijų seką keliuose mikroservisuose. Jis suteikia būdą pasiekti galutinį nuoseklumą, o tai reiškia, kad nors duomenys laikinai gali būti nenuoseklūs, galiausiai jie pasieks nuoseklią būseną. Užuot rėmęsis viena, atomine transakcija, apimančia kelias tarnybas, Sagos modelis suskaido transakciją į eilę mažesnių, nepriklausomų transakcijų, kurių kiekvieną atlieka viena tarnyba.

Kiekviena lokali Sagos transakcija atnaujina vieno mikroserviso duomenų bazę. Jei viena iš transakcijų nepavyksta, Saga įvykdo kompensacinių transakcijų seriją, kad anuliuotų ankstesnių transakcijų atliktus pakeitimus, efektyviai atšaukdama bendrą operaciją.

Kodėl naudoti Sagos modelį?

Keletas veiksnių daro Sagos modelį vertingu įrankiu valdant transakcijas mikroservisų architektūrose:

• Atsiejimas: Sagos skatina silpną mikroservisų susiejimą, leidžiant joms vystytis nepriklausomai, nepaveikiant kitų tarnybų. Tai yra pagrindinis mikroservisų architektūrų privalumas.
• Mastelio keitimas: Vengdamos ilgalaikių, paskirstytųjų transakcijų, Sagos gerina mastelio keitimą ir našumą. Kiekvienas mikroservisas gali savarankiškai tvarkyti savo transakcijas, mažindamas konkurenciją ir didindamas pralaidumą.
• Atsparumas: Sagos yra sukurtos taip, kad būtų atsparios gedimams. Jei transakcija nepavyksta, Sagą galima atšaukti, išvengiant duomenų nenuoseklumo ir užtikrinant, kad sistema išliktų nuoseklioje būsenoje.
• Lankstumas: Sagos modelis suteikia lankstumo valdant sudėtingus verslo procesus, apimančius kelias tarnybas. Jis leidžia apibrėžti transakcijų seką ir kompensacinius veiksmus, kurių reikia imtis gedimo atveju.

ACID ir BASE palyginimas

Norint nuspręsti, ar naudoti Sagos modelį, labai svarbu suprasti skirtumą tarp ACID ir BASE (Basically Available, Soft state, Eventually consistent – iš esmės pasiekiamas, lanksti būsena, galiausiai nuoseklus).

• ACID (atomiškumas, nuoseklumas, izoliacija, patvarumas): Užtikrina, kad transakcijos būtų apdorojamos patikimai. Atomiškumas užtikrina, kad arba visos operacijos transakcijoje pavyksta, arba nė viena. Nuoseklumas užtikrina, kad transakcija perveda duomenų bazę iš vienos galiojančios būsenos į kitą. Izoliacija užtikrina, kad lygiagrečios transakcijos netrukdytų viena kitai. Patvarumas užtikrina, kad kai transakcija yra patvirtinta, ji tokia ir lieka net ir sistemos gedimo atveju.
• BASE (iš esmės pasiekiamas, lanksti būsena, galiausiai nuoseklus): Tai kitoks požiūris, skirtas paskirstytosioms sistemoms. Iš esmės pasiekiamas reiškia, kad sistema veikia didžiąją laiko dalį. Lanksti būsena reiškia, kad sistemos būsena gali keistis laikui bėgant, net ir be įvesties. Galiausiai nuoseklus reiškia, kad sistema galiausiai taps nuosekli, kai nustos gauti įvestį. Sagos modelis atitinka BASE principus.

Dvi pagrindinės Sagos įgyvendinimo strategijos

Yra du pagrindiniai būdai įgyvendinti Sagos modelį: choreografija ir orkestravimas.

1. Choreografija pagrįsta Saga

Choreografija pagrįstoje Sagoje kiekvienas mikroservisas dalyvauja Sagoje, klausydamasis kitų mikroservisų skelbiamų įvykių ir atitinkamai reaguodamas. Nėra centrinio orkestratoriaus; kiekviena tarnyba žino savo atsakomybes ir kada atlikti savo veiksmus.

Kaip tai veikia:

1. Saga prasideda, kai mikroservisas paskelbia įvykį, nurodantį transakcijos pradžią.
2. Kiti mikroservisai prenumeruoja šį įvykį ir, jį gavę, atlieka savo lokalią transakciją.
3. Užbaigę savo transakciją, kiekvienas mikroservisas paskelbia kitą įvykį, nurodantį jo operacijos sėkmę ar nesėkmę.
4. Kiti mikroservisai klauso šių įvykių ir imasi atitinkamų veiksmų: arba pereina prie kito Sagos žingsnio, arba, įvykus klaidai, inicijuoja kompensacines transakcijas.

Pavyzdys: el. prekybos užsakymo pateikimas (choreografija)

1. Užsakymų tarnyba: Gauna naujo užsakymo užklausą ir paskelbia `OrderCreated` (UžsakymasSukurtas) įvykį.
2. Atsargų tarnyba: Prenumeruoja `OrderCreated`. Gavusi įvykį, patikrina atsargas. Jei pakanka, rezervuoja prekes ir paskelbia `InventoryReserved` (AtsargosRezervuotos). Jei nepakanka, paskelbia `InventoryReservationFailed` (AtsargųRezervacijaNepavyko).
3. Mokėjimų tarnyba: Prenumeruoja `InventoryReserved`. Gavusi įvykį, apdoroja mokėjimą. Jei sėkmingai, paskelbia `PaymentProcessed` (MokėjimasApdorotas). Jei nepavyksta, paskelbia `PaymentFailed` (MokėjimasNepavyko).
4. Pristatymo tarnyba: Prenumeruoja `PaymentProcessed`. Gavusi įvykį, paruošia siuntą ir paskelbia `ShipmentPrepared` (SiuntaParuošta).
5. Užsakymų tarnyba: Prenumeruoja `ShipmentPrepared`. Gavusi įvykį, pažymi užsakymą kaip įvykdytą.
6. Kompensacija: Jei paskelbiamas `PaymentFailed` arba `InventoryReservationFailed` įvykis, kitos tarnybos klauso ir atlieka kompensacines transakcijas (pvz., atlaisvina rezervuotas atsargas).

Choreografijos privalumai:

• Paprastumas: Lengviau įgyvendinti paprastoms darbo eigoms.
• Decentralizacija: Skatina silpną susiejimą ir nepriklausomą mikroservisų vystymąsi.

Choreografijos trūkumai:

• Sudėtingumas: Gali tapti sudėtinga valdyti, kai Sagos dalyvių skaičius didėja.
• Matomumas: Sunku sekti bendrą Sagos eigą ir būseną.
• Susiejimas: Nors skatinamas silpnas susiejimas, tarnybos vis tiek turi žinoti apie kitų tarnybų skelbiamus įvykius.

2. Orkestravimu pagrįsta Saga

Orkestravimu pagrįstoje Sagoje centrinis orkestratorius (dažnai įgyvendinamas kaip dedikuota tarnyba arba būsenų mašina) valdo Sagą ir koordinuoja lokalių transakcijų vykdymą dalyvaujančiuose mikroservisuose. Orkestratorius nurodo kiekvienai tarnybai, ką ir kada daryti.

Kaip tai veikia:

1. Saga prasideda, kai klientas paprašo orkestratoriaus inicijuoti transakciją.
2. Orkestratorius siunčia komandas dalyvaujantiems mikroservisams atlikti jų lokalias transakcijas.
3. Kiekvienas mikroservisas atlieka savo transakciją ir praneša orkestratoriui apie sėkmę ar nesėkmę.
4. Remdamasis rezultatu, orkestratorius nusprendžia, ar pereiti prie kito žingsnio, ar inicijuoti kompensacines transakcijas.

Pavyzdys: el. prekybos užsakymo pateikimas (orkestravimas)

1. Užsakymų orkestratorius: Gauna naujo užsakymo užklausą.
2. Užsakymų orkestratorius: Siunčia komandą Atsargų tarnybai rezervuoti prekes.
3. Atsargų tarnyba: Rezervuoja prekes ir praneša Užsakymų orkestratoriui.
4. Užsakymų orkestratorius: Siunčia komandą Mokėjimų tarnybai apdoroti mokėjimą.
5. Mokėjimų tarnyba: Apdoroja mokėjimą ir praneša Užsakymų orkestratoriui.
6. Užsakymų orkestratorius: Siunčia komandą Pristatymo tarnybai paruošti siuntą.
7. Pristatymo tarnyba: Paruošia siuntą ir praneša Užsakymų orkestratoriui.
8. Užsakymų orkestratorius: Pažymi užsakymą kaip įvykdytą.
9. Kompensacija: Jei kuris nors žingsnis nepavyksta, Užsakymų orkestratorius siunčia kompensacines komandas atitinkamoms tarnyboms (pvz., atlaisvinti rezervuotas atsargas).

Orkestravimo privalumai:

• Centralizuotas valdymas: Lengviau valdyti ir stebėti Sagą iš vieno centrinio taško.
• Geresnis matomumas: Orkestratorius suteikia aiškų vaizdą apie bendrą Sagos eigą ir būseną.
• Sumažintas susiejimas: Mikroservisams reikia bendrauti tik su orkestratoriumi, taip sumažinant tiesiogines priklausomybes tarp jų.

Orkestravimo trūkumai:

• Sudėtingumas: Iš pradžių gali būti sudėtingiau įgyvendinti, ypač paprastoms darbo eigoms.
• Vienintelis gedimo taškas: Orkestratorius gali tapti vieninteliu gedimo tašku, nors tai galima sušvelninti naudojant perteklinumo ir atsparumo gedimams priemones.

Kompensacinių transakcijų įgyvendinimas

Svarbus Sagos modelio aspektas yra kompensacinių transakcijų įgyvendinimas. Šios transakcijos vykdomos siekiant anuliuoti anksčiau užbaigtų transakcijų poveikį gedimo atveju. Tikslas – sugrąžinti sistemą į nuoseklią būseną, net jei visos Sagos negalima užbaigti.

Pagrindiniai aspektai, į kuriuos reikia atsižvelgti įgyvendinant kompensacines transakcijas:

• Idempotentiškumas: Kompensacinės transakcijos turėtų būti idempotentiškos, t. y. jas galima vykdyti kelis kartus nepakeičiant rezultato. Tai svarbu, nes gedimai gali įvykti bet kuriame taške, ir kompensacinė transakcija gali būti bandoma pakartotinai.
• Gedimų tvarkymas: Kompensacinės transakcijos taip pat gali nepavykti. Reikia turėti strategiją, kaip tvarkyti kompensacinių transakcijų gedimus, pavyzdžiui, bandyti iš naujo, registruoti klaidas ir įspėti administratorius.
• Duomenų nuoseklumas: Kompensacinės transakcijos turėtų užtikrinti, kad duomenys išliktų nuoseklūs. Tai gali apimti duomenų atkūrimą į ankstesnę būseną, naujai sukurtų duomenų ištrynimą arba duomenų atnaujinimą, atspindintį transakcijos atšaukimą.

Kompensacinių transakcijų pavyzdžiai:

• Atsargų tarnyba: Jei Atsargų tarnyba rezervavo prekes, bet mokėjimas nepavyko, kompensacinė transakcija būtų atlaisvinti rezervuotas prekes.
• Mokėjimų tarnyba: Jei Mokėjimų tarnyba apdorojo mokėjimą, bet pristatymas nepavyko, kompensacinė transakcija galėtų apimti pinigų grąžinimą.

Iššūkiai ir svarstymai

Nors Sagos modelis siūlo reikšmingų privalumų, jis taip pat kelia tam tikrų iššūkių ir reikalauja apsvarstyti kelis aspektus:

• Sudėtingumas: Sagos modelio įgyvendinimas gali būti sudėtingas, ypač sudėtingiems verslo procesams. Būtinas kruopštus planavimas ir projektavimas.
• Galutinis nuoseklumas: Sagos modelis suteikia galutinį nuoseklumą, o tai reiškia, kad duomenys gali būti laikinai nenuoseklūs. Tai gali kelti susirūpinimą programoms, kurioms reikalingos griežtos nuoseklumo garantijos.
• Testavimas: Sagų testavimas gali būti sudėtingas dėl jų paskirstyto pobūdžio ir galimybės gedimams įvykti įvairiuose taškuose.
• Stebėsena: Sagų eigos ir būsenos stebėjimas yra labai svarbus norint nustatyti ir išspręsti problemas. Reikia turėti tinkamus stebėjimo įrankius ir procesus.
• Idempotentiškumas: Užtikrinti, kad transakcijos ir kompensacinės transakcijos būtų idempotentiškos, yra labai svarbu norint išvengti duomenų nenuoseklumo.
• Izoliacija: Kadangi Sagos apima kelias lokalias transakcijas, izoliacija gali kelti susirūpinimą. Gali prireikti tokių strategijų kaip semantiniai užraktai ar optimistinis blokavimas.

Panaudojimo atvejai ir pavyzdžiai

Sagos modelis puikiai tinka įvairiems panaudojimo atvejams, ypač paskirstytosiose sistemose ir mikroservisų architektūrose. Štai keletas įprastų pavyzdžių:

• El. prekybos užsakymų valdymas: Kaip parodyta aukščiau pateiktuose pavyzdžiuose, Sagos modelis gali būti naudojamas valdyti visą užsakymo ciklą, nuo užsakymo sukūrimo iki mokėjimo apdorojimo ir pristatymo.
• Finansinės transakcijos: Sagos modelis gali būti naudojamas valdyti sudėtingas finansines transakcijas, kurios apima kelias sistemas, pavyzdžiui, lėšų pervedimus, paskolų paraiškas ir draudimo išmokas.
• Tiekimo grandinės valdymas: Sagos modelis gali būti naudojamas koordinuoti veiklą tarp kelių tiekimo grandinės subjektų, pavyzdžiui, gamintojų, platintojų ir mažmenininkų.
• Sveikatos apsaugos sistemos: Sagos modelis gali būti naudojamas valdyti pacientų įrašus ir koordinuoti priežiūrą tarp skirtingų skyrių ir paslaugų teikėjų.

Pavyzdys: pasaulinė bankinė transakcija

Įsivaizduokite scenarijų, apimantį pasaulinę bankinę transakciją tarp dviejų skirtingų bankų, esančių skirtingose šalyse, kuriems taikomi įvairūs reglamentai ir atitikties patikros. Sagos modelis gali užtikrinti, kad transakcija vyktų pagal nustatytus žingsnius:

1. Inicijuoti transakciją: Klientas inicijuoja lėšų pervedimą iš savo sąskaitos banke A (esančiame JAV) į gavėjo sąskaitą banke B (esančiame Vokietijoje).
2. Bankas A – sąskaitos patvirtinimas: Bankas A patvirtina kliento sąskaitą, patikrina, ar yra pakankamai lėšų, ir užtikrina, kad nėra jokių apribojimų.
3. Atitikties patikra (Bankas A): Bankas A atlieka atitikties patikrą, siekdamas užtikrinti, kad transakcija nepažeistų pinigų plovimo prevencijos (AML) reglamentų ar tarptautinių sankcijų.
4. Lėšų pervedimas (Bankas A): Bankas A nuskaito lėšas iš kliento sąskaitos ir siunčia jas į tarpuskaitos namus ar tarpininkaujantį banką.
5. Tarpuskaitos namų apdorojimas: Tarpuskaitos namai apdoroja transakciją, atlieka valiutos konvertavimą (USD į EUR) ir nukreipia lėšas į banką B.
6. Bankas B – sąskaitos patvirtinimas: Bankas B patvirtina gavėjo sąskaitą ir užtikrina, kad ji yra aktyvi ir gali priimti lėšas.
7. Atitikties patikra (Bankas B): Bankas B atlieka savo atitikties patikrą, laikydamasis Vokietijos ir ES reglamentų.
8. Įskaityti į sąskaitą (Bankas B): Bankas B įskaito lėšas į gavėjo sąskaitą.
9. Patvirtinimas: Bankas B siunčia patvirtinimo pranešimą bankui A, kuris tada praneša klientui, kad transakcija baigta.

Kompensacinės transakcijos:

• Jei atitikties patikra banke A nepavyksta, transakcija atšaukiama, o lėšos iš kliento sąskaitos nenuskaitomos.
• Jei atitikties patikra banke B nepavyksta, lėšos grąžinamos bankui A, o kliento sąskaita papildoma.
• Jei kyla problemų dėl valiutos konvertavimo ar maršruto parinkimo tarpuskaitos namuose, transakcija atšaukiama, o lėšos grąžinamos bankui A.

Įrankiai ir technologijos

Keletas įrankių ir technologijų gali padėti įgyvendinti Sagos modelį:

• Pranešimų eilės: Apache Kafka, RabbitMQ ir Amazon SQS gali būti naudojami skelbti ir prenumeruoti įvykius choreografija pagrįstoje Sagoje.
• Darbo eigų varikliai: Camunda, Zeebe ir Apache Airflow gali būti naudojami įgyvendinti orkestratorius ir valdyti sudėtingas darbo eigas.
• Įvykių šaltinis (Event Sourcing): Įvykių šaltinis gali būti naudojamas sekti Sagos įvykių istoriją ir palengvinti atšaukimą gedimo atveju.
• Paskirstytųjų transakcijų valdytojai: Kai kurie paskirstytųjų transakcijų valdytojai, pavyzdžiui, Atomikos, gali būti naudojami koordinuoti transakcijas keliose tarnybose. Tačiau jie gali netikti visoms mikroservisų architektūroms dėl savo prigimtinių apribojimų paskirstytosiose aplinkose.
• Sagos karkasai (Frameworks): Taip pat yra Sagos karkasų, kurie suteikia abstrakcijas ir įrankius Sagos modeliui įgyvendinti.

Geriausios Sagos modelio įgyvendinimo praktikos

Norėdami efektyviai įgyvendinti Sagos modelį, apsvarstykite šias geriausias praktikas:

• Kruopštus projektavimas: Išsamiai išanalizuokite savo verslo reikalavimus ir atitinkamai suprojektuokite Sagą. Nustatykite dalyvaujančius mikroservisus, transakcijų seką ir kompensacinius veiksmus.
• Idempotentiškumas: Užtikrinkite, kad visos transakcijos ir kompensacinės transakcijos būtų idempotentiškos.
• Klaidų tvarkymas: Įdiekite patikimus klaidų tvarkymo mechanizmus, kad susidorotumėte su gedimais bet kuriame Sagos etape.
• Stebėjimas ir registravimas: Įdiekite išsamią stebėjimo ir registravimo sistemą, kad galėtumėte sekti Sagų eigą ir būseną.
• Testavimas: Kruopščiai išbandykite savo Sagas, kad įsitikintumėte, jog jos veikia teisingai ir tinkamai tvarko gedimus.
• Semantiniai užraktai: Įgyvendinkite semantinius užraktus, kad išvengtumėte lygiagrečių tų pačių duomenų atnaujinimų skirtingose Sagose.
• Optimistinis blokavimas: Naudokite optimistinį blokavimą, kad aptiktumėte ir išvengtumėte konfliktų tarp lygiagrečių transakcijų.
• Pasirinkite tinkamą įgyvendinimo strategiją: Atidžiai apsvarstykite choreografijos ir orkestravimo kompromisus ir pasirinkite strategiją, kuri geriausiai atitinka jūsų poreikius.
• Apibrėžkite aiškias kompensavimo politikas: Nustatykite aiškias kompensavimo tvarkymo politikas, įskaitant sąlygas, kuriomis kompensacija yra inicijuojama, ir konkrečius veiksmus, kurių reikia imtis.

Išvada

Sagos modelis yra galingas įrankis valdyti paskirstytąsias transakcijas mikroservisų architektūrose. Suskaidydamas transakcijas į mažesnių, nepriklausomų transakcijų seriją ir suteikdamas mechanizmą gedimams kompensuoti, Sagos modelis leidžia palaikyti duomenų nuoseklumą ir kurti atsparias, mastelį keičiančias ir atsietas sistemas. Nors Sagos modelį gali būti sudėtinga įgyvendinti, jo teikiami privalumai lankstumo, mastelio keitimo ir atsparumo požiūriu daro jį vertingu turtu bet kuriai mikroservisų architektūrai.

Sagos modelio niuansų, choreografijos ir orkestravimo kompromisų bei kompensacinių transakcijų svarbos supratimas leis jums projektuoti ir įgyvendinti patikimas paskirstytąsias sistemas, atitinkančias šiandienos sudėtingų verslo aplinkų reikalavimus. Sagos modelio pritaikymas yra žingsnis link tikrai atsparių ir mastelį keičiančių mikroservisų architektūrų kūrimo, gebančių su pasitikėjimu valdyti net ir sudėtingiausias paskirstytąsias transakcijas. Taikydami šį modelį, nepamirškite atsižvelgti į savo konkrečius poreikius ir kontekstą bei nuolat tobulinti savo įgyvendinimą remdamiesi realia patirtimi ir grįžtamuoju ryšiu.