Sistema banatuetan mezularitza fidagarria

Idazketa bikoitzeko arazoa

Banatutako sistema fidagarria, eskuragarria eta eskalagarria eraikitzeak teknika, printzipio eta eredu zehatzak betetzea eskatzen du. Sistema horien diseinuak hainbat erronkari aurre egitea dakar. Gai nagusi eta oinarrizkoenen artean idazketa bikoitzaren arazoa dago .

"Idazketa bikoitzeko arazoa" sistema banatuetan sortzen den erronka da, batez ere sinkronizatuta mantendu behar diren datu-iturri edo datu-base anitzekin aurre egitean. Datuen aldaketak koherentziaz idazten direla hainbat datu biltegitan, datu-baseetan edo cachean adibidez, datu-inkoherentziak, gatazkak edo errendimendu-lepoak bezalako arazoak sartu gabe ziurtatzeko zailtasunari egiten dio erreferentzia.

Zerbitzu bakoitzeko mikrozerbitzuen arkitektura eta ereduen datu-baseak onura asko dakarzkizu, hala nola inplementazio eta eskalatze independenteak, hutsegite isolatuak eta garapen-abiaduraren bultzada potentziala. Hala ere, eragiketak mikrozerbitzu anitzen artean aldaketak behar ditu, arazo honi aurre egiteko irtenbide fidagarri bat pentsatzera behartzen zaitu.

Ia benetako adibidea

Demagun gure domeinuak mailegu-eskaerak onartzea, ebaluatzea eta bezeroei jakinarazpen-abisuak bidaltzea suposatzen duen eszenatoki bat.

Erantzukizun bakarraren printzipioaren, Conway-ren legearen eta domeinuak bultzatutako diseinuaren ikuspegiaren arabera, hainbat gertaera-sorta-saioren ondoren, domeinu osoa hiru azpidomeinutan banatu zen, mugatutako testuinguru definituekin, muga argiak, domeinu-ereduak eta nonahiko hizkuntza.

Lehena mailegu-eskaera berriak barneratzeaz eta osatzeaz arduratzen da. Bigarren sistemak aplikazio hauek ebaluatzen ditu eta emandako datuen arabera erabakiak hartzen ditu. Ebaluazio prozesu honek, KYC/KYB, iruzurraren aurkako eta kreditu-arriskuaren egiaztapenak barne, denbora asko behar du, eta milaka aplikazio aldi berean kudeatzeko gaitasuna behar du. Ondorioz, funtzionalitate hau bere datu-base propioa duen mikrozerbitzu dedikatu batean eskuordetu da, eskalatze independentea ahalbidetuz.

Gainera, azpisistema hauek bi talde ezberdinek kudeatzen dituzte, bakoitza bere kaleratze-ziklo, zerbitzu-maila-hitzarmenak (SLA) eta eskalagarritasun-eskakizunekin.

Azkenik , jakinarazpen zerbitzu espezializatu bat dago bezeroei alertak bidaltzeko.

Hona hemen sistemaren lehen erabilera-kasuaren deskribapen zehatza:

1. Bezero batek mailegu eskaera bat aurkezten du.
2. Maileguak Eskatzeko Zerbitzuak eskaera berria "Zain" egoerarekin erregistratzen du eta balorazio-prozesua abiarazten du eskaera Ebaluazio Zerbitzura helaraziz.
3. Ebaluazio Zerbitzuak sarrerako mailegu-eskaera ebaluatzen du eta, ondoren, mailegu-eskaera-zerbitzuari ebazpenaren berri ematen dio.
4. Erabakia jasotzean, mailegu-eskaeraren zerbitzuak horren arabera eguneratzen du mailegu-eskaeraren egoera eta Jakinarazpen Zerbitzua abiarazten du bezeroari emaitzaren berri emateko.
5. Jakinarazpen Zerbitzuak eskaera hau prozesatzen du eta bezeroari jakinarazpenak bidaltzen dizkio posta elektroniko bidez, SMS bidez edo beste komunikazio-metodo hobetsi batzuen bidez, bezeroaren ezarpenen arabera.

Nahiko sistema sinple eta primitiboa da lehen begiratuan, baina ikus dezagun nola prozesatzen duen Mailegu eskaera zerbitzuak bidali mailegu eskaera komandoa.

Zerbitzuen interakziorako bi ikuspegi har ditzakegu:

1. Lehen-Tokiko-Konpromisoa-Gero-Argitaratu: Ikuspegi honetan, zerbitzuak bere datu-base lokala eguneratzen du (konpromisoak) eta gero gertaera edo mezu bat argitaratzen du beste zerbitzu batzuetara.

2. Lehen-Publikatu-Gero-Local-Konprometitua: Aldiz, metodo honek gertaera edo mezu bat argitaratzea dakar tokiko datu-basean aldaketak konprometitu aurretik.

   
   

Bi metodoek bere eragozpenak dituzte eta partzialki hutsegite-seguruak dira sistema banatuetan komunikatzeko.

Hau lehen hurbilketa aplikatzeko sekuentzia-diagrama bat da.

Eszenatoki honetan, Mailegu-eskaera Zerbitzuak Lehen-Tokiko Konpromisoa-Gero-Publikatu ikuspegia erabiltzen du, non lehenengo transakzio bat egiten duen eta gero jakinarazpen bat beste sistema batera bidaltzen saiatzen den. Dena den, prozesu honek huts egin dezake, adibidez, sare-arazoak badaude, Ebaluazio Zerbitzua erabilgarri ez badago edo Mailegu-eskaeraren Zerbitzuak Memoria Gabeko (OOM) errore bat aurkitzen badu eta huts egiten badu. Horrelakoetan, mezua galduko litzateke, Ebaluazioa mailegu-eskaera berriaren berririk gabe utziz, neurri osagarriak ezartzen ez badira.

Eta bigarrena.

Lehen-Argitaratu-Gero Tokiko-Konprometitutako eszenatokian, maileguak eskatzeko zerbitzuak arrisku nabarmenagoak ditu. Baliteke Ebaluazio Zerbitzuari aplikazio berri baten berri ematea, baina eguneraketa hau lokalean ez gordetzea ezin izango du gorde datu-base-arazoak, memoria-akatsak edo kode-akatsak direla eta. Planteamendu horrek datuetan deskoherentzia nabarmenak sor ditzake, eta horrek arazo larriak sor ditzake, Maileguak Berrikusteko Zerbitzuak sarrerako eskaerak kudeatzen dituenaren arabera.

Horregatik, kanpoko kontsumitzaileei ekitaldiak argitaratzeko mekanismo sendoa eskaintzen duen irtenbide bat identifikatu behar dugu. Baina, balizko irtenbideetan sakondu baino lehen, sistema banatuetan lor daitezkeen mezuak bidaltzeko berme motak argitu beharko genituzke.

Mezuak bidaltzeko bermeak

Lor genitzakeen lau berme mota daude.

1. Bermerik ez
   Ez dago bermerik mezua helmugara bidaliko denik. Lehen-Tokiko-Konprometitu-Gero-Argitaratu planteamendua horren ingurukoa da hain zuzen. Kontsumitzaileek mezuak behin, hainbat aldiz edo inoiz ez jaso ditzakete.

2. Gehienez behin entrega
   Gehienez behin bidaltzeak esan nahi du mezua helmugara gehienez 1 aldiz bidaliko dela. Lehen-Tokiko-Konpromisoa-Gero-Argitaratu ikuspegia modu honetan inplementa daiteke, baita bat balioa duten saiakeren berragiteko politikarekin ere.

3. Gutxienez behin entrega\Kontsumitzaileek mezu guztiak jasoko dituzte eta prozesatuko dituzte, baina baliteke mezu bera behin baino gehiagotan jasotzea.

4. Behin zehatz-mehatz bidaltzea \ Zehazki behin entregatzea esan nahi du kontsumitzaileak mezua eraginkortasunez jasoko duela behin.
   Teknikoki, posible da Kafka transakzioekin eta ekoizle eta kontsumitzaileen inplementazio idepotente zehatzekin.

   
   

Gehienetan, "gutxienez behin" bidalketa-bermeek arazo asko tratatzen dituzte, mezuak gutxienez behin entregatzen direla ziurtatuz, baina kontsumitzaileak ezinbestekoak izan behar dira. Hala ere, sarearen hutsegite saihestezinak kontuan hartuta, kontsumitzaileen logika guztiak idepotentzia izan behar du mezu bikoiztuak prozesatzea saihesteko, ekoizlearen bermeak kontuan hartu gabe. Beraz, eskakizun hau ez da errealitatea islatzen duen eragozpen bat.

Irtenbideak

Arazo honen konponbide ugari daude, abantailak eta desabantailak dituztenak.

Bi faseko konpromisoa

Wikipediaren arabera, Two-Phase Commit (2PC) informatika eta datu-baseak kudeatzeko sistemetan erabiltzen den transakzio banatuko protokolo bat da, banatutako transakzioen koherentzia eta fidagarritasuna bermatzeko. Baliabide anitzek (adibidez, datu-baseek) transakzio bakar batean parte hartu behar duten egoeretarako diseinatuta dago, eta guztiek transakzioa konprometitzen dutela edo denek bertan behera uzten dutela ziurtatzen du, eta horrela datuen koherentzia mantenduz. Behar duguna dirudi, baina Two-Phase Commit-ek hainbat eragozpen ditu:

• Parte hartzen duen baliabide batek erantzuten ez badu edo hutsegite bat jasaten badu, prozesu osoa blokeatu egin daiteke arazoa konpondu arte. Horrek errendimendu eta erabilgarritasun arazoak sor ditzake.
• Bi faseko konpromisoak ez du akatsen tolerantzia-mekanismorik barneratzen. Hutsegiteak kudeatzeko kanpoko mekanismoetan edo eskuzko esku-hartzean oinarritzen da.
• Datu-base moderno guztiek ez dute onartzen Bi faseko konpromisoa.

Partekatutako datu-basea

Mikrozerbitzuen arkitekturarako irtenbiderik agerikoena eredu bat (edo batzuetan ereduaren aurkakoa) aplikatzea da, partekatutako datu-base bat. Ikuspegi hau oso intuitiboa da datu-base desberdinetako hainbat taulatan transakzio-koherentzia behar baduzu, erabili partekatutako datu-base bat mikrozerbitzu hauetarako.

Ikuspegi honen eragozpenen artean, besteak beste, hutsegite puntu bakarra sartzea, datu-baseen eskalatze independentea eragoztea eta baldintza eta erabilera kasu zehatzetarako egokienak diren datu-baseen irtenbide desberdinak erabiltzeko gaitasuna mugatzea. Gainera, mikrozerbitzuen kode-oinarrietan aldaketak beharrezkoak izango lirateke banatutako transakzio mota hori onartzeko.

Transakzio-irteera-ontzia

' Transakzio-irteera-ontzia ' sistema banatuetan erabiltzen den diseinu-eredua da, mezuen hedapen fidagarria bermatzeko, baita fidagarritasunik gabeko mezularitza-sistemen aurrean ere. Gertaerak "OutboxEvents" izendatutako taula batean biltegiratzea dakar eragiketaren beraren transakzio berean. Ikuspegi hau ondo egokitzen da datu-base erlazionalen ACID propietateekin. Aitzitik, No-SQL datu-base askok ez dute guztiz onartzen ACID propietateak, CAP teorema eta BASE filosofiaren printzipioak aukeratuz, erabilgarritasuna eta koherentzia koherentzia zorrotzaren gainetik lehenesten baitute.

Transakzio-irteera-ontzi batek gutxienez behin bermea eskaintzen du eta hainbat ikuspegirekin inplementa daiteke:

1. Transakzioen erregistroaren amaiera

2. Inkesta argitaletxea

   
   

Transakzio-erregistroa biltzeko ikuspegiak CDC (Change Data Capture) bezalako datu-baseetarako irtenbide espezifikoak erabiltzea dakar. Ikuspegi horren eragozpen nagusiak hauek dira:

• Datu-basearen irtenbide espezifikoak

• Latentzia handitu da CDC inplementazioen berezitasunengatik

  
  

Beste metodo bat Polling Publisher da, irteerako ontzia deskargatzea errazten duena irteerako ontzia taula galdezkatuz. Ikuspegi honen eragozpen nagusia datu-baseen karga handitzeko potentziala da, eta horrek kostu handiagoak ekar ditzake. Gainera, No-SQL datu-base guztiek ez dute onartzen dokumentu-segmentu zehatzetarako kontsulta eraginkorra. Dokumentu osoak ateratzeak, beraz, errendimendua hondatzea eragin dezake.

Hona hemen nola funtzionatzen duen azaltzen duen sekuentzia-diagrama txiki bat.

Entzun zeure buruari

Transactional Outbox ereduaren erronka nagusia datu-basearen ACID propietateekiko menpekotasunean datza. Baliteke OLTP datu-base tipikoetan erraza izatea, baina erronkak ditu NoSQL eremuan. Horri aurre egiteko, irtenbide potentzial bat eranskinen erregistroa (adibidez, Kafka) aprobetxatzea da eskaera prozesatzen hasten denetik.

"Bidali mailegu eskaera" komandoa zuzenean prozesatu beharrean, berehala bidaliko diogu Kafka-ren barneko gai batera eta gero "onartutako" emaitza bat itzultzen diogu bezeroari. Hala ere, litekeena denez komandoa oraindik prozesatu behar izatea, ezin diogu berehala bezeroari emaitzaren berri eman. Behin betiko koherentzia hori kudeatzeko, teknikak erabil ditzakegu, hala nola, galdeketa luzea, bezeroak hasitako galdeketa, interfazearen eguneratze baikorrak edo WebSockets edo Server-Sent Events erabiliz jakinarazpenetarako. Hala ere, gai ezberdina da guztiz, beraz, itzul gaitezen hasierako gaira.

Kafka barneko gai bati buruzko mezua bidali dugu. Maileguaren Eskaera Zerbitzuak mezu hau kontsumitzen du —bezeroarengandik jasotako komando bera— eta prozesatzen hasten da. Lehenik eta behin, negozio-logika batzuk exekutatzen ditu; Logika hau arrakastaz exekutatu eta emaitzak mantendu ondoren soilik mezu berriak argitaratzen ditu Kafka gai publiko batean.

Ikus dezagun sasi-kode pixka bat.

 public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); }

Zer gertatzen da negozio-logikaren prozesamenduak huts egiten badu? Ez kezkatu, desplazamendua oraindik konprometitu ez denez, mezua berriro saiatuko da.

Kafkari gertaera berriak bidaltzeak huts egiten badu? Ez kezkatu, negozio-logika idempotentea denez, ez du mailegu-eskaera bikoiztua sortuko. Horren ordez, Kafka gai publikoari mezuak berriro bidaltzen saiatuko da.

Zer gertatzen da mezuak Kafkari bidaltzen badira, baina desplazamendu-konpromisoak huts egiten badu? Ez kezkatu, negozio-logika idempotentea denez, ez du mailegu-eskaera bikoiztua sortuko. Horren ordez, mezuak berriro bidaliko ditu Kafka gai publikora eta konpentsatzeko konpromisoak oraingoan arrakasta izatea espero du.

Ikuspegi honen eragozpen nagusiak honako hauek dira: programazio estilo berri bati lotutako konplexutasun gehigarria, behin-behineko koherentzia (bezeroak ez baitu berehala emaitzaren berri emango) eta negozio-logika guztiak idempotenteak izateko eskakizuna.

Gertaeren iturria

Zer da gertaeren hornikuntza, eta nola aplikatu liteke hemen? Gertaeren iturria sistema baten egoera modelatzeko erabiltzen den software-arkitektura-eredu bat da, bere datuen aldaketa guztiak gertaera aldaezinen sorta gisa harrapatzen dituena. Gertaera hauek gertakariak edo egoera-trantsizioak adierazten dituzte eta sistemaren egungo egoerarako egia iturri bakar gisa balio dute. Beraz, teknikoki, gertaerak biltzeko sistema bat ezarriz, dagoeneko ekitaldi guztiak ditugu EventStore-n, eta EventStore hau kontsumitzaileek gertatutakoari buruzko egia iturri bakar gisa erabil dezakete. Ez dago datu-baseko irtenbide espezifiko baten beharrik eskaerari buruzko aldaketa edo kezka guztiak jarraitzeko, arazo bakarra irakur aldean egotea da, entitatearen benetako egoera lortu ahal izateko gertaera guztiak errepikatzeko beharrezkoa baita.

Ondorioa

Artikulu honetan, sistema banatuetan mezu fidagarriak eraikitzeko hainbat ikuspegi berrikusi ditugu. Ezaugarri hauek dituzten sistemak eraikitzerakoan kontuan izan ditzakegun hainbat gomendio daude

1. Garatu beti kontsumitzaile idepotenteak sarearen hutsegite saihestezina baita.
2. Erabili arretaz Lehen-Tokiko-Konpromisoa-Gero-Argitaratu berme-eskakizunak argi ulertuta.
3. Ez erabili inoiz First-Publish-Then-Local-Commit ikuspegia, zure sisteman datu-inkoherentzia larria ekar dezakeelako.
4. Lehendik dagoen datu-basearen aukeraketa erabakia oso litekeena bada alda daiteke edo estrategia teknikoak arazorako biltegiratze-irtenbide onena hautatzea suposatzen badu - ez sortu liburutegi partekatuak CDC bezalako datu-baseen soluzioekin lotuz.
5. Erabili Transakzio Irteera-ontziaren ikuspegia irtenbide estandar gisa, gutxienez behin bermeak lortzeko.
6. Kontuan izan Entzun zeure buruari ikuspegia erabiltzea No-SQL datu-baseak aprobetxatzen direnean.

Hurrengoan, Transakzio Irteera-ontzia ezartzearen adibide praktikoago bat ikusiko dugu. Ikusi

zu!