Saga modelis: ceļvedis izkliedēto transakciju koordinēšanai

Mūsdienu programmatūras arhitektūras jomā, īpaši līdz ar mikropakalpojumu parādīšanos, datu konsekvences pārvaldība starp vairākiem pakalpojumiem ir kļuvusi par būtisku izaicinājumu. Tradicionālās ACID (Atomiskums, Konsekvence, Izolācija, Izturība) transakcijas, kas labi darbojas vienā datubāzē, bieži vien neizdodas izkliedētā vidē. Saga modelis parādās kā spēcīgs risinājums transakciju orķestrēšanai starp vairākiem pakalpojumiem, nodrošinot datu konsekvenci un noturību.

Kas ir Saga modelis?

Saga modelis ir dizaina modelis, kas palīdz pārvaldīt izkliedētās transakcijas mikropakalpojumu arhitektūrā. Tā vietā, lai paļautos uz vienu, lielu ACID transakciju, Saga sadala biznesa transakciju virknē mazākām, lokālām transakcijām. Katra lokālā transakcija atjaunina datus vienā pakalpojumā un pēc tam iedarbina nākamo transakciju secībā. Ja viena no lokālajām transakcijām neizdodas, Saga izpilda kompensējošo transakciju sēriju, lai atceltu iepriekšējo transakciju efektus, nodrošinot datu konsekvenci visā sistēmā.

Domājiet par to kā par domino virkni. Katrs domino pārstāv lokālu transakciju noteiktā mikropakalpojumā. Kad viens domino krīt (transakcija pabeigta), tas iedarbina nākamo. Ja domino nekrīt (transakcija neizdodas), jums ir uzmanīgi jāstumj jau nokritušie domino atpakaļ (kompensējošās transakcijas).

Kāpēc izmantot Saga modeli?

Lūk, kāpēc Saga modelis ir būtisks mikropakalpojumu arhitektūrām:

• Izkliedētās transakcijas: Tas ļauj pārvaldīt transakcijas, kas aptver vairākus pakalpojumus, nepaļaujoties uz izkliedētiem divfāzu apstiprināšanas (2PC) protokoliem, kas var būt sarežģīti un ieviest veiktspējas problēmas.
• Galīgā konsekvence: Tas nodrošina galīgo konsekvenci starp pakalpojumiem. Dati var nebūt nekavējoties konsekventi visos pakalpojumos, bet tie galu galā sasniegs konsekventu stāvokli.
• Kļūdu tolerance: Īstenojot kompensējošās transakcijas, Saga modelis uzlabo kļūdu toleranci. Ja pakalpojums neizdodas, sistēma var veiksmīgi atgūties, atceļot izmaiņas, ko veikušas iepriekšējās transakcijas.
• Atvienošana: Tas veicina pakalpojumu brīvu savienojumu. Katrs pakalpojums ir atbildīgs par savu lokālo transakciju, samazinot atkarības starp pakalpojumiem.
• Mērogojamība: Tas atbalsta mērogojamību, ļaujot katru pakalpojumu mērogot neatkarīgi.

Saga modeļu veidi

Ir divi galvenie veidi, kā ieviest Saga modeli:

1. Uz horeogrāfiju balstīts Saga

Horeogrāfijā balstītā Saga katrs pakalpojums klausās citu pakalpojumu publicētos notikumus un izlemj, vai rīkoties, pamatojoties uz šiem notikumiem. Nav centrālā orķestrētāja, kas pārvaldītu Saga. Tā vietā katrs pakalpojums piedalās Sagā, reaģējot uz notikumiem un publicējot jaunus notikumus.

Kā tas darbojas:

1. Iniciējošais pakalpojums sāk Saga, veicot savu lokālo transakciju un publicējot notikumu.
2. Citi pakalpojumi abonē šo notikumu un, to saņemot, veic savas lokālās transakcijas un publicē jaunus notikumus.
3. Ja kāda transakcija neizdodas, attiecīgais pakalpojums publicē kompensējošo notikumu.
4. Citi pakalpojumi klausās kompensējošos notikumus un izpilda savas kompensējošās transakcijas, lai atceltu savas iepriekšējās darbības.

Piemērs:

Apsveriet e-komercijas pasūtījuma izpildes procesu, kurā ir iesaistīti trīs pakalpojumi: pasūtījumu pakalpojums, maksājumu pakalpojums un krājumu pakalpojums.

1. Pasūtījumu pakalpojums: Saņem jaunu pasūtījumu un publicē notikumu `OrderCreated`.
2. Maksājumu pakalpojums: Abonē `OrderCreated`, apstrādā maksājumu un publicē notikumu `PaymentProcessed`.
3. Krājumu pakalpojums: Abonē `PaymentProcessed`, rezervē krājumus un publicē notikumu `InventoryReserved`.
4. Ja Krājumu pakalpojums neizdodas rezervēt krājumus, tas publicē notikumu `InventoryReservationFailed`.
5. Maksājumu pakalpojums: Abonē `InventoryReservationFailed`, atmaksā maksājumu un publicē notikumu `PaymentRefunded`.
6. Pasūtījumu pakalpojums: Abonē `PaymentRefunded` un atceļ pasūtījumu.

Priekšrocības:

• Vienkāršība: Viegli ieviest vienkāršām Sagām ar dažiem dalībniekiem.
• Brīvs savienojums: Pakalpojumi ir brīvi savienoti un var attīstīties neatkarīgi.

Trūkumi:

• Sarežģītība: Kļūst grūti pārvaldīt sarežģītas Sagas ar daudziem dalībniekiem.
• Izsekošana: Grūti izsekot Sagas progresam un atkļūdot problēmas.
• Cikliskas atkarības: Var novest pie cikliskiem atkarībām starp pakalpojumiem.

2. Uz orķestrāciju balstīts Saga

Orķestrācijā balstītā Sagā centrālais orķestrētāja pakalpojums pārvalda Sagas izpildi. Orķestrētāja pakalpojums katram pakalpojumam norāda, kad jāveic lokālā transakcija un kad nepieciešamības gadījumā jāizpilda kompensējošās transakcijas.

Kā tas darbojas:

1. Orķestrētāja pakalpojums saņem pieprasījumu sākt Saga.
2. Tas nosūta komandas katram pakalpojumam, lai veiktu savu lokālo transakciju.
3. Orķestrētājs uzrauga katras transakcijas rezultātu.
4. Ja visas transakcijas ir veiksmīgas, Saga ir pabeigta.
5. Ja kāda transakcija neizdodas, orķestrētājs nosūta kompensējošās komandas attiecīgajiem pakalpojumiem, lai atceltu iepriekšējo transakciju efektus.

Piemērs:

Izmantojot to pašu e-komercijas pasūtījuma izpildes procesu, orķestrētāja pakalpojums (Saga Orķestrētājs) koordinētu šos soļus:

1. Saga Orķestrētājs: Saņem jaunu pasūtījuma pieprasījumu.
2. Saga Orķestrētājs: Nosūta komandu `ProcessOrder` Pasūtījumu pakalpojumam.
3. Pasūtījumu pakalpojums: Apstrādā pasūtījumu un paziņo Saga Orķestrētājam par panākumiem vai neveiksmi.
4. Saga Orķestrētājs: Nosūta komandu `ProcessPayment` Maksājumu pakalpojumam.
5. Maksājumu pakalpojums: Apstrādā maksājumu un paziņo Saga Orķestrētājam par panākumiem vai neveiksmi.
6. Saga Orķestrētājs: Nosūta komandu `ReserveInventory` Krājumu pakalpojumam.
7. Krājumu pakalpojums: Rezervē krājumus un paziņo Saga Orķestrētājam par panākumiem vai neveiksmi.
8. Ja Krājumu pakalpojums neizdodas, tas paziņo Saga Orķestrētājam.
9. Saga Orķestrētājs: Nosūta komandu `RefundPayment` Maksājumu pakalpojumam.
10. Maksājumu pakalpojums: Atmaksā maksājumu un paziņo Saga Orķestrētājam.
11. Saga Orķestrētājs: Nosūta komandu `CancelOrder` Pasūtījumu pakalpojumam.
12. Pasūtījumu pakalpojums: Atceļ pasūtījumu un paziņo Saga Orķestrētājam.

Priekšrocības:

• Centralizēta pārvaldība: Viegli pārvaldīt sarežģītas Sagas ar daudziem dalībniekiem.
• Uzlabota izsekošana: Viegli izsekot Sagas progresam un atkļūdot problēmas.
• Samazinātas atkarības: Samazina ciklisko atkarību starp pakalpojumiem.

Trūkumi:

• Paaugstināta sarežģītība: Nepieciešams centrālais orķestrētāja pakalpojums, kas palielina arhitektūras sarežģītību.
• Vienots kļūmes punkts: Orķestrētāja pakalpojums var kļūt par vienotu kļūmes punktu.

Izvēle starp horeogrāfiju un orķestrāciju

Izvēle starp horeogrāfiju un orķestrāciju ir atkarīga no Sagas sarežģītības un iesaistīto pakalpojumu skaita. Šeit ir vispārējas vadlīnijas:

• Horeogrāfija: Piemērota vienkāršām Sagām ar nelielu dalībnieku skaitu, kur pakalpojumi ir relatīvi neatkarīgi. Labi piemērots scenārijiem, piemēram, pamata konta izveidei vai vienkāršiem e-komercijas darījumiem.
• Orķestrācija: Piemērota sarežģītām Sagām ar lielu dalībnieku skaitu vai tad, kad nepieciešama centralizēta kontrole un redzamība pār Sagas izpildi. Ideāli piemērots sarežģītiem finanšu darījumiem, piegādes ķēdes pārvaldībai vai jebkuram procesam ar sarežģītām atkarībām un atcelšanas prasībām.

Saga modeļa ieviešana

Saga modeļa ieviešana prasa rūpīgu plānošanu un vairāku faktoru apsvēršanu.

1. Definējiet Saga soļus

Identificējiet atsevišķas lokālās transakcijas, kas veido Sagu. Katrai transakcijai definējiet šādus elementus:

• Pakalpojums: Pakalpojums, kas atbild par transakcijas veikšanu.
• Darbība: Darbība, kas jāveic transakcijai.
• Dati: Dati, kas nepieciešami transakcijas veikšanai.
• Kompensējošā darbība: Darbība, kas jāveic, lai atceltu transakcijas efektus.

2. Izvēlieties ieviešanas pieeju

Izlemiet, vai izmantot horeogrāfiju vai orķestrāciju. Apsveriet Sagas sarežģītību un kompromisus starp centralizētu kontroli un izkliedētu atbildību.

3. Ieviesiet kompensējošās transakcijas

Ieviesiet kompensējošās transakcijas katrai lokālajai transakcijai. Kompensējošām transakcijām ir jāatceļ sākotnējās transakcijas efekti un jāatjauno sistēma konsekventā stāvoklī.

Svarīgi 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, neizraisot nevēlamus blakusefektus. Tas ir ļoti svarīgi, jo kompensējošā transakcija var tikt mēģināta vēlreiz, ja tā sākotnēji neizdodas.
• Atomiskums: Ideālā gadījumā kompensējošai transakcijai jābūt atomiskai. Tomēr reālas atomiskuma panākšana izkliedētā vidē var būt izaicinājums. Centieties panākt pēc iespējas labāku atomiskuma aproksimāciju.
• Izturība: Nodrošiniet, ka kompensējošās transakcijas ir izturīgas, kas nozīmē, ka to efekti tiek saglabāti pat tad, ja pakalpojums avarē.

4. Rīkojieties ar kļūmēm un mēģinājumiem vēlreiz

Ieviesiet robustu kļūdu apstrādi un atkārtošanas mehānismus, lai veiksmīgi apstrādātu kļūmes. Apsveriet iespēju izmantot šādas metodes:

• Eksponenciāla atgriešanās: Mēģiniet vēlreiz neveiksmīgās transakcijas ar arvien lielākiem kavējumiem, lai izvairītos no sistēmas pārslogošanas.
• Ķēdes pārtraucējs: Neļaujiet pakalpojumam atkārtoti zvanīt uz neveiksmīgu pakalpojumu, lai izvairītos no kaskādes kļūmēm.
• Mirušo vēstuļu rinda: Nosūtiet neveiksmīgās ziņas uz mirušo vēstuļu rindu turpmākai analīzei un atkārtotai apstrādei.

5. Nodrošiniet idempotenci

Nodrošiniet, ka visas lokālās transakcijas un kompensējošās transakcijas ir idempotentas. Tas ir ļoti svarīgi, lai apstrādātu atkārtojumus un nodrošinātu datu konsekvenci.

6. Uzraugiet un izsekojiet Sagas

Ieviesiet uzraudzību un izsekošanu, lai izsekotu Sagas progresam un identificētu potenciālās problēmas. Izmantojiet izkliedētās izsekošanas rīkus, lai korelētu notikumus starp vairākiem pakalpojumiem.

Saga modeļa ieviešanas tehnoloģijas

Vairākas tehnoloģijas var palīdzēt Saga modeļa ieviešanā:

• Ziņojumu rindas (RabbitMQ, Kafka): Atvieglo asinhrono saziņu starp pakalpojumiem, nodrošinot notikumu virzītas Sagas.
• Notikumu izcelsme: Saglabājiet lietojumprogrammas stāvokli kā notikumu secību, nodrošinot pilnīgu revīzijas ceļu un iespēju atkārtoti atskaņot notikumus atkopšanas nolūkos.
• Saga orķestrēšanas ietvari: Ietvari, piemēram, Apache Camel, Netflix Conductor un Temporal, nodrošina rīkus un abstrakcijas Sagas veidošanai un pārvaldībai.
• Datubāzes transakciju pārvaldnieki (lokālām transakcijām): Relāciju datubāzes (piemēram, PostgreSQL, MySQL) un NoSQL datubāzes piedāvā transakciju pārvaldniekus, lai nodrošinātu ACID īpašības vienā pakalpojumā.

Saga modeļa izmantošanas izaicinājumi

Lai gan Saga modelis piedāvā ievērojamas priekšrocības, tas rada arī noteiktus izaicinājumus:

• Sarežģītība: Saga modeļa ieviešana var būt sarežģīta, īpaši sarežģītiem biznesa procesiem.
• Galīgā konsekvence: Rīcība ar galīgo konsekvenci prasa rūpīgu potenciālo sacensību apstākļu un datu nekonsekvences apsvēršanu.
• Testēšana: Sagu testēšana var būt izaicinājums, ņemot vērā to izkliedēto raksturu un nepieciešamību simulēt kļūmes.
• Atkļūdošana: Sagu atkļūdošana var būt sarežģīta, īpaši horeogrāfijā balstītās ieviešanās, kur nav centrālā orķestrētāja.
• Idempotence: Transakciju un kompensējošo transakciju idempotences nodrošināšana ir ļoti svarīga, taču var būt izaicinājums to ieviest.

Labākā prakse Saga modeļa ieviešanai

Lai mazinātu izaicinājumus un nodrošinātu veiksmīgu Saga modeļa ieviešanu, apsveriet šādas labākās prakses:

• Sāciet no maziem: Sāciet ar vienkāršām Sagām un pakāpeniski palieliniet sarežģītību, gūstot pieredzi.
• Definējiet skaidras robežas: Skaidri definējiet katra pakalpojuma robežas un nodrošiniet, ka katrs pakalpojums ir atbildīgs par saviem datiem.
• Izmantojiet domēna notikumus: Izmantojiet domēna notikumus, lai sazinātos starp pakalpojumiem un iedarbinātu Saga soļus.
• Ieviesiet kompensējošās transakcijas rūpīgi: Nodrošiniet, ka kompensējošās transakcijas ir idempotentas, atomiskas un izturīgas.
• Uzraugiet un izsekojiet Sagas: Ieviesiet visaptverošu uzraudzību un izsekošanu, lai izsekotu Sagas progresam un identificētu potenciālās problēmas.
• Projektējiet kļūmēm: Izstrādājiet savu sistēmu tā, lai tā veiksmīgi tiktu galā ar kļūmēm un nodrošinātu, ka sistēma var atgūties no kļūmēm, nezaudējot datus.
• Dokumentējiet visu: Rūpīgi dokumentējiet Sagas dizainu, ieviešanu un testēšanas procedūras.

Reālās dzīves Saga modeļa piemēri darbībā

Saga modelis tiek izmantots dažādās nozarēs, lai pārvaldītu izkliedētās transakcijas sarežģītos biznesa procesos. Šeit ir daži piemēri:

• E-komercija: Pasūtījumu izpilde, maksājumu apstrāde, krājumu pārvaldība un piegāde. Piemēram, kad klients veic pasūtījumu, Saga pārvalda krājumu rezervēšanas, maksājuma apstrādes un sūtījuma izveides procesu. Ja kāds no soļiem neizdodas (piemēram, nepietiekams krājumu daudzums), Saga kompensē, atbrīvojot rezervētos krājumus un atmaksājot maksājumu. Alibaba, globālais e-komercijas gigants, savā plašajā tirgū plaši izmanto Saga modeļus, lai nodrošinātu transakciju konsekvenci starp daudziem mikropakalpojumiem.
• Finanšu pakalpojumi: Līdzekļu pārskaitījumi, aizdevuma pieteikumi un kredītkaršu darījumi. Apsveriet pārrobežu naudas pārskaitījumu: Saga varētu koordinēt debetus no viena konta, valūtas konvertēšanu un kredītus uz citu kontu. Ja valūtas konvertēšana neizdodas, kompensējošās transakcijas atceļ debetu un novērš nekonsekvences. TransferWise (tagad Wise), finanšu tehnoloģiju uzņēmums, kas specializējas starptautiskos naudas pārskaitījumos, paļaujas uz Saga modeļiem, lai garantētu savu darījumu uzticamību un konsekvenci dažādās banku sistēmās visā pasaulē.
• Veselības aprūpe: Pacientu reģistrācija, tikšanās plānošana un medicīnisko ierakstu atjaunināšana. Kad pacients reģistrējas uz tikšanos, Saga varētu pārvaldīt jauna pacienta ieraksta izveides, tikšanās plānošanas un attiecīgo veselības aprūpes sniedzēju paziņošanas procesu. Ja tikšanās plānošana neizdodas, kompensējošās transakcijas noņem tikšanos un paziņo pacientam.
• Piegādes ķēdes pārvaldība: Pasūtījumu apstrāde, noliktavu pārvaldība un piegādes plānošana. Kad pasūtījums ir saņemts, Saga varētu pārvaldīt krājumu rezervēšanu, preču iepakošanu, piegādes plānošanu un klienta paziņošanu. Ja viens no šiem soļiem neizdodas, kompensējošā darbība var tikt izmantota, lai atceltu pasūtījumu, atgrieztu preces krājumā un paziņotu klientam par atcelšanu.

Secinājums

Saga modelis ir vērtīgs rīks izkliedēto transakciju pārvaldīšanai mikropakalpojumu arhitektūrās. Sadalot biznesa transakcijas lokālo transakciju secībā un ieviešot kompensējošās transakcijas, jūs varat nodrošināt datu konsekvenci un noturību izkliedētā vidē. Lai gan Saga modelis rada noteiktus izaicinājumus, sekojot labākajai praksei un izmantojot atbilstošās tehnoloģijas, jūs varat veiksmīgi to ieviest un izveidot robustas, mērogojamas un kļūdu tolerantas lietojumprogrammas.

Tā kā mikropakalpojumi kļūst arvien izplatītāki, Saga modelis turpinās spēlēt būtisku lomu izkliedēto transakciju pārvaldībā un datu konsekvences nodrošināšanā sarežģītās sistēmās. Saga modeļa pieņemšana ir galvenais solis ceļā uz modernu, noturīgu un mērogojamu lietojumprogrammu izstrādi, kas var apmierināt mūsdienu biznesa ainavas prasības.