Saga Modelis: Izkliedētu Transakciju Ieviešana Mikropakalpojumiem

Mikropakalpojumu pasaulē datu konsekvences uzturēšana starp vairākiem pakalpojumiem var būt ievērojams izaicinājums. Tradicionālās ACID (Atomitāte, Konsekvence, Izolācija, Izturība) transakcijas, ko parasti izmanto monolītās lietojumprogrammās, bieži vien nav piemērotas izkliedētām vidēm. Tieši šeit noder Saga modelis, kas nodrošina stabilu risinājumu izkliedētu transakciju pārvaldībai un datu integritātes nodrošināšanai starp mikropakalpojumiem.

Kas ir Saga modelis?

Saga modelis ir dizaina šablons, ko izmanto, lai pārvaldītu lokālu transakciju secību vairākos mikropakalpojumos. Tas nodrošina veidu, kā sasniegt galīgo konsekvenci (eventual consistency), kas nozīmē, ka, lai gan dati īslaicīgi var būt nekonsekventi, tie galu galā nonāks konsekventā stāvoklī. Tā vietā, lai paļautos uz vienu, atomāru transakciju, kas aptver vairākus pakalpojumus, Saga modelis sadala transakciju mazākās, neatkarīgās transakcijās, katru no kurām veic viens pakalpojums.

Katra lokālā transakcija Sagas ietvaros atjaunina viena mikropakalpojuma datubāzi. Ja kāda no transakcijām neizdodas, Saga izpilda kompensējošo transakciju sēriju, lai atceltu iepriekšējo transakciju veiktās izmaiņas, tādējādi faktiski atritinot kopējo operāciju.

Kāpēc izmantot Saga modeli?

Vairāki faktori padara Saga modeli par vērtīgu rīku transakciju pārvaldībai mikropakalpojumu arhitektūrās:

• Atvienošana (Decoupling): Sagas veicina vāju sasaisti starp mikropakalpojumiem, ļaujot tiem attīstīties neatkarīgi, neietekmējot citus pakalpojumus. Tā ir galvenā mikropakalpojumu arhitektūru priekšrocība.
• Mērogojamība: Izvairoties no ilgstošām, izkliedētām transakcijām, Sagas uzlabo mērogojamību un veiktspēju. Katrs mikropakalpojums var neatkarīgi apstrādāt savas transakcijas, samazinot konkurenci un uzlabojot caurlaidspēju.
• Noturība (Resilience): Sagas ir izstrādātas, lai būtu noturīgas pret kļūmēm. Ja transakcija neizdodas, Sagu var atritināt, novēršot datu nekonsekvenci un nodrošinot, ka sistēma paliek konsekventā stāvoklī.
• Elastīgums: Saga modelis nodrošina elastīgumu, pārvaldot sarežģītus biznesa procesus, kas aptver vairākus pakalpojumus. Tas ļauj definēt transakciju secību un kompensējošās darbības, kas jāveic kļūmes gadījumā.

ACID pret BASE

Izpratne par atšķirību starp ACID un BASE (Basically Available, Soft state, Eventually consistent) ir būtiska, lemjot, vai izmantot Saga modeli.

• ACID (Atomitāte, Konsekvence, Izolācija, Izturība): Garantē, ka transakcijas tiek apstrādātas uzticami. Atomitāte nodrošina, ka vai nu visas operācijas transakcijā ir veiksmīgas, vai neviena. Konsekvence nodrošina, ka transakcija pārveido datubāzi no viena derīga stāvokļa uz citu. Izolācija nodrošina, ka vienlaicīgas transakcijas netraucē viena otrai. Izturība nodrošina, ka, tiklīdz transakcija ir apstiprināta, tā tāda paliek pat sistēmas kļūmes gadījumā.
• BASE (Basically Available, Soft state, Eventually consistent): Šī ir atšķirīga pieeja, kas paredzēta izkliedētām sistēmām. Basically Available (pamatā pieejams) nozīmē, ka sistēma ir pieejama lielāko daļu laika. Soft state (mīksts stāvoklis) nozīmē, ka sistēmas stāvoklis laika gaitā var mainīties pat bez ievades. Eventually consistent (galu galā konsekvents) nozīmē, ka sistēma galu galā kļūs konsekventa, kad tā pārstās saņemt ievadi. Saga modelis atbilst BASE principiem.

Divas Galvenās Saga Ieviešanas Stratēģijas

Ir divi galvenie veidi, kā ieviest Saga modeli: horeogrāfija un orķestrēšana.

1. Horeogrāfijā Balstīta Saga

Horeogrāfijā balstītā Sagā katrs mikropakalpojums piedalās Sagā, klausoties notikumus, ko publicē citi mikropakalpojumi, un attiecīgi reaģējot. Nav centrālā orķestratora; katrs pakalpojums zina savus pienākumus un to, kad veikt savas darbības.

Kā tas darbojas:

1. Saga sākas, kad mikropakalpojums publicē notikumu, kas norāda uz transakcijas sākumu.
2. Citi mikropakalpojumi abonē šo notikumu un, to saņemot, veic savu lokālo transakciju.
3. Pēc savas transakcijas pabeigšanas katrs mikropakalpojums publicē citu notikumu, kas norāda uz operācijas veiksmīgu vai neveiksmīgu iznākumu.
4. Citi mikropakalpojumi klausās šos notikumus un veic atbilstošas darbības, vai nu turpinot nākamo soli Sagā, vai uzsākot kompensējošas transakcijas, ja rodas kļūda.

Piemērs: E-komercijas pasūtījuma veikšana (Horeogrāfija)

1. Pasūtījumu serviss: Saņem jaunu pasūtījuma pieprasījumu un publicē `OrderCreated` (PasūtījumsIzveidots) notikumu.
2. Inventāra serviss: Abonē `OrderCreated`. Saņemot notikumu, tas pārbauda inventāru. Ja pietiek, tas rezervē preces un publicē `InventoryReserved` (InventārsRezervēts). Ja nepietiek, tas publicē `InventoryReservationFailed` (InventāraRezervācijaNeizdevās).
3. Maksājumu serviss: Abonē `InventoryReserved`. Saņemot notikumu, tas apstrādā maksājumu. Ja veiksmīgi, tas publicē `PaymentProcessed` (MaksājumsApstrādāts). Ja neizdodas, tas publicē `PaymentFailed` (MaksājumsNeizdevās).
4. Piegādes serviss: Abonē `PaymentProcessed`. Saņemot notikumu, tas sagatavo sūtījumu un publicē `ShipmentPrepared` (SūtījumsSagatavots).
5. Pasūtījumu serviss: Abonē `ShipmentPrepared`. Saņemot notikumu, tas atzīmē pasūtījumu kā pabeigtu.
6. Kompensācija: Ja tiek publicēts `PaymentFailed` vai `InventoryReservationFailed`, citi servisi klausās un veic kompensējošas transakcijas (piemēram, atbrīvojot rezervēto inventāru).

Horeogrāfijas plusi:

• Vienkāršība: Vieglāk ieviest vienkāršām darba plūsmām.
• Decentralizācija: Veicina vāju sasaisti un neatkarīgu mikropakalpojumu attīstību.

Horeogrāfijas mīnusi:

• Sarežģītība: Var kļūt sarežģīti pārvaldīt, palielinoties dalībnieku skaitam Sagā.
• Pārredzamība: Grūti izsekot Sagas kopējam progresam un stāvoklim.
• Sasaiste: Lai gan tiek veicināta vāja sasaiste, pakalpojumiem joprojām jābūt informētiem par citu pakalpojumu publicētajiem notikumiem.

2. Orķestrēšanā Balstīta Saga

Orķestrēšanā balstītā Sagā centrālais orķestrators (bieži ieviests kā atsevišķs pakalpojums vai stāvokļu mašīna) pārvalda Sagu un koordinē lokālo transakciju izpildi, ko veic iesaistītie mikropakalpojumi. Orķestrators norāda katram pakalpojumam, ko un kad darīt.

Kā tas darbojas:

1. Saga sākas, kad klients pieprasa orķestratoram uzsākt transakciju.
2. Orķestrators nosūta komandas iesaistītajiem mikropakalpojumiem, lai veiktu to lokālās transakcijas.
3. Katrs mikropakalpojums veic savu transakciju un paziņo orķestratoram par panākumiem vai neveiksmi.
4. Pamatojoties uz rezultātu, orķestrators izlemj, vai turpināt nākamo soli vai uzsākt kompensējošas transakcijas.

Piemērs: E-komercijas pasūtījuma veikšana (Orķestrēšana)

1. Pasūtījumu orķestrators: Saņem jaunu pasūtījuma pieprasījumu.
2. Pasūtījumu orķestrators: Nosūta komandu Inventāra servisam rezervēt preces.
3. Inventāra serviss: Rezervē preces un paziņo Pasūtījumu orķestratoram.
4. Pasūtījumu orķestrators: Nosūta komandu Maksājumu servisam apstrādāt maksājumu.
5. Maksājumu serviss: Apstrādā maksājumu un paziņo Pasūtījumu orķestratoram.
6. Pasūtījumu orķestrators: Nosūta komandu Piegādes servisam sagatavot sūtījumu.
7. Piegādes serviss: Sagatavo sūtījumu un paziņo Pasūtījumu orķestratoram.
8. Pasūtījumu orķestrators: Atzīmē pasūtījumu kā pabeigtu.
9. Kompensācija: Ja kāds solis neizdodas, Pasūtījumu orķestrators nosūta kompensējošas komandas attiecīgajiem servisiem (piemēram, atbrīvojot rezervēto inventāru).

Orķestrēšanas plusi:

• Centralizēta kontrole: Vieglāk pārvaldīt un uzraudzīt Sagu no centrālā punkta.
• Uzlabota pārredzamība: Orķestrators nodrošina skaidru priekšstatu par Sagas kopējo progresu un stāvokli.
• Samazināta sasaiste: Mikropakalpojumiem nepieciešams sazināties tikai ar orķestratoru, samazinot tiešās atkarības starp tiem.

Orķestrēšanas mīnusi:

• Sarežģītība: Sākotnēji var būt sarežģītāk ieviest, īpaši vienkāršām darba plūsmām.
• Viens kļūmes punkts (Single Point of Failure): Orķestrators var kļūt par vienu kļūmes punktu, lai gan to var mazināt ar redundanci un kļūmju tolerances pasākumiem.

Kompensējošo Transakciju Ieviešana

Svarīgs Saga modeļa aspekts ir kompensējošo transakciju ieviešana. Šīs transakcijas tiek izpildītas, lai atceltu iepriekš pabeigto transakciju sekas kļūmes gadījumā. Mērķis ir atgriezt sistēmu konsekventā stāvoklī, pat ja kopējo Sagu nevar pabeigt.

Galvenie apsvērumi kompensējošām transakcijām:

• Idempotence: Kompensējošām transakcijām jābūt idempotentām, kas nozīmē, ka tās var izpildīt vairākas reizes, nemainot rezultātu. Tas ir svarīgi, jo kļūmes var notikt jebkurā brīdī, un kompensējošā transakcija var tikt mēģināta atkārtoti.
• Kļūmju apstrāde: Arī kompensējošās transakcijas var neizdoties. Jums ir jābūt stratēģijai, kā rīkoties ar kļūmēm kompensējošās transakcijās, piemēram, atkārtoti mēģinot, reģistrējot kļūdas un brīdinot administratorus.
• Datu konsekvence: Kompensējošām transakcijām jānodrošina datu konsekvence. Tas var ietvert datu atjaunošanu iepriekšējā stāvoklī, jaunizveidoto datu dzēšanu vai datu atjaunināšanu, lai atspoguļotu transakcijas atcelšanu.

Kompensējošo transakciju piemēri:

• Inventāra serviss: Ja Inventāra serviss rezervēja preces, bet maksājums neizdevās, kompensējošā transakcija būtu atbrīvot rezervētās preces.
• Maksājumu serviss: Ja Maksājumu serviss apstrādāja maksājumu, bet piegāde neizdevās, kompensējošā transakcija varētu ietvert naudas atmaksu.

Izaicinājumi un Apsvērumi

Lai gan Saga modelis piedāvā ievērojamas priekšrocības, tas rada arī dažus izaicinājumus un apsvērumus:

• Sarežģītība: Saga modeļa ieviešana var būt sarežģīta, īpaši sarežģītiem biznesa procesiem. Būtiska ir rūpīga plānošana un projektēšana.
• Galīgā konsekvence: Saga modelis nodrošina galīgo konsekvenci, kas nozīmē, ka dati īslaicīgi var būt nekonsekventi. Tas var radīt bažas lietojumprogrammām, kurām nepieciešamas stingras konsekvences garantijas.
• Testēšana: Sagu testēšana var būt izaicinājums to izkliedētās dabas un kļūmju iespējamības dēļ dažādos punktos.
• Monitorings: Sagu progresa un stāvokļa uzraudzība ir būtiska, lai identificētu un atrisinātu problēmas. Jums ir jābūt ieviestiem atbilstošiem monitoringa rīkiem un procesiem.
• Idempotence: Ir ļoti svarīgi nodrošināt, ka transakcijas un kompensējošās transakcijas ir idempotentas, lai novērstu datu nekonsekvenci.
• Izolācija: Tā kā Sagas ietver vairākas lokālas transakcijas, izolācija var radīt bažas. Var būt nepieciešamas tādas stratēģijas kā semantiskās slēdzenes vai optimistiskā bloķēšana.

Lietošanas Gadījumi un Piemēri

Saga modelis ir labi piemērots dažādiem lietošanas gadījumiem, īpaši izkliedētās sistēmās un mikropakalpojumu arhitektūrās. Šeit ir daži bieži sastopami piemēri:

• E-komercijas pasūtījumu pārvaldība: Kā parādīts iepriekšējos piemēros, Saga modeli var izmantot, lai pārvaldītu visu pasūtījuma dzīves ciklu, sākot no pasūtījuma izveides līdz maksājumu apstrādei un piegādei.
• Finanšu transakcijas: Saga modeli var izmantot, lai pārvaldītu sarežģītas finanšu transakcijas, kas ietver vairākas sistēmas, piemēram, naudas pārskaitījumus, aizdevumu pieteikumus un apdrošināšanas prasības.
• Piegādes ķēdes pārvaldība: Saga modeli var izmantot, lai koordinētu darbības starp vairākām struktūrvienībām piegādes ķēdē, piemēram, ražotājiem, izplatītājiem un mazumtirgotājiem.
• Veselības aprūpes sistēmas: Saga modeli var izmantot, lai pārvaldītu pacientu datus un koordinētu aprūpi starp dažādām nodaļām un pakalpojumu sniedzējiem.

Piemērs: Globāla bankas transakcija

Iedomājieties scenāriju, kas ietver globālu bankas transakciju starp divām dažādām bankām, kas atrodas dažādās valstīs un pakļautas dažādiem noteikumiem un atbilstības pārbaudēm. Saga modelis var nodrošināt, ka transakcija notiek saskaņā ar definētajiem soļiem:

1. Uzsākt transakciju: Klients uzsāk naudas pārskaitījumu no sava konta Bankā A (atrodas ASV) uz saņēmēja kontu Bankā B (atrodas Vācijā).
2. Banka A - Konta validācija: Banka A apstiprina klienta kontu, pārbauda pietiekamus līdzekļus un pārliecinās, ka nav nekādu aizturējumu vai ierobežojumu.
3. Atbilstības pārbaude (Banka A): Banka A veic atbilstības pārbaudi, lai nodrošinātu, ka transakcija nepārkāpj naudas atmazgāšanas novēršanas (AML) noteikumus vai starptautiskās sankcijas.
4. Līdzekļu pārskaitījums (Banka A): Banka A debetē klienta kontu un nosūta līdzekļus uz klīringa namu vai starpniekbanku.
5. Klīringa nama apstrāde: Klīringa nams apstrādā transakciju, veic valūtas konvertāciju (no USD uz EUR) un novirza līdzekļus uz Banku B.
6. Banka B - Konta validācija: Banka B apstiprina saņēmēja kontu un nodrošina, ka tas ir aktīvs un tiesīgs saņemt līdzekļus.
7. Atbilstības pārbaude (Banka B): Banka B veic savu atbilstības pārbaudi, ievērojot Vācijas un ES noteikumus.
8. Ieskaitīt kontā (Banka B): Banka B ieskaita līdzekļus saņēmēja kontā.
9. Apstiprinājums: Banka B nosūta apstiprinājuma ziņojumu Bankai A, kas pēc tam paziņo klientam, ka transakcija ir pabeigta.

Kompensējošās transakcijas:

• Ja atbilstības pārbaude Bankā A neizdodas, transakcija tiek atcelta, un klienta konts netiek debetēts.
• Ja atbilstības pārbaude Bankā B neizdodas, līdzekļi tiek atgriezti Bankai A, un klienta kontā tiek ieskaitīta nauda atpakaļ.
• Ja rodas problēmas ar valūtas konvertāciju vai maršrutēšanu klīringa namā, transakcija tiek atcelta, un līdzekļi tiek atgriezti Bankai A.

Rīki un Tehnoloģijas

Vairāki rīki un tehnoloģijas var palīdzēt ieviest Saga modeli:

• Ziņojumapmaiņas rindas: Apache Kafka, RabbitMQ un Amazon SQS var izmantot, lai publicētu un abonētu notikumus horeogrāfijā balstītā Sagā.
• Darbplūsmu dzinēji: Camunda, Zeebe un Apache Airflow var izmantot, lai ieviestu orķestratorus un pārvaldītu sarežģītas darbplūsmas.
• Notikumu avotošana (Event Sourcing): Notikumu avotošanu var izmantot, lai izsekotu notikumu vēsturi Sagā un atvieglotu atritināšanu kļūmes gadījumā.
• Izkliedētu transakciju pārvaldnieki: Dažus izkliedētu transakciju pārvaldniekus, piemēram, Atomikos, var izmantot, lai koordinētu transakcijas starp vairākiem pakalpojumiem. Tomēr tie var nebūt piemēroti visām mikropakalpojumu arhitektūrām to raksturīgo ierobežojumu dēļ izkliedētās vidēs.
• Saga ietvari: Pastāv arī Saga ietvari, kas nodrošina abstrakcijas un rīkus Saga modeļa ieviešanai.

Labākā Prakse Saga Modeļa Ieviešanai

Lai efektīvi ieviestu Saga modeli, apsveriet šādas labākās prakses:

• Rūpīga projektēšana: Rūpīgi analizējiet savas biznesa prasības un atbilstoši projektējiet Sagu. Identificējiet iesaistītos mikropakalpojumus, transakciju secību un kompensējošās darbības.
• Idempotence: Nodrošiniet, ka visas transakcijas un kompensējošās transakcijas ir idempotentas.
• Kļūdu apstrāde: Ieviesiet stabilus kļūdu apstrādes mehānismus, lai risinātu kļūmes jebkurā Sagas posmā.
• Monitorings un reģistrēšana: Ieviesiet visaptverošu monitoringu un reģistrēšanu, lai izsekotu Sagu progresam un stāvoklim.
• Testēšana: Rūpīgi testējiet savas Sagas, lai nodrošinātu, ka tās darbojas pareizi un graciozi apstrādā kļūmes.
• Semantiskās slēdzenes: Ieviesiet semantiskās slēdzenes, lai novērstu vienlaicīgus atjauninājumus vieniem un tiem pašiem datiem dažādās Sagās.
• Optimistiskā bloķēšana: Izmantojiet optimistisko bloķēšanu, lai atklātu un novērstu konfliktus starp vienlaicīgām transakcijām.
• Izvēlieties pareizo ieviešanas stratēģiju: Rūpīgi apsveriet kompromisus starp horeogrāfiju un orķestrēšanu un izvēlieties stratēģiju, kas vislabāk atbilst jūsu vajadzībām.
• Definējiet skaidras kompensācijas politikas: Izveidojiet skaidras politikas kompensācijas pārvaldībai, ieskaitot nosacījumus, kad kompensācija tiek aktivizēta, un konkrētās darbības, kas jāveic.

Noslēgums

Saga modelis ir spēcīgs rīks izkliedētu transakciju pārvaldībai mikropakalpojumu arhitektūrās. Sadalot transakcijas mazākās, neatkarīgās transakcijās un nodrošinot mehānismu kļūmju kompensēšanai, Saga modelis ļauj uzturēt datu konsekvenci un veidot noturīgas, mērogojamas un vāji saistītas sistēmas. Lai gan Saga modeļa ieviešana var būt sarežģīta, tā piedāvātās priekšrocības elastīguma, mērogojamības un noturības ziņā padara to par vērtīgu ieguvumu jebkurai mikropakalpojumu arhitektūrai.

Izpratne par Saga modeļa niansēm, kompromisiem starp horeogrāfiju un orķestrēšanu, kā arī kompensējošo transakciju nozīmi dos jums iespēju projektēt un ieviest stabilas izkliedētas sistēmas, kas atbilst mūsdienu sarežģīto biznesa vidi prasībām. Saga modeļa pieņemšana ir solis ceļā uz patiesi noturīgu un mērogojamu mikropakalpojumu arhitektūru veidošanu, kas spēj ar pārliecību apstrādāt pat vissarežģītākās izkliedētās transakcijas. Atcerieties, piemērojot šo modeli, ņemt vērā savas specifiskās vajadzības un kontekstu, un nepārtraukti pilnveidot savu ieviešanu, balstoties uz reālās pasaules pieredzi un atsauksmēm.