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   dago . idazketa bikoitzaren 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. "Idazketa bikoitzeko arazoa"  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.    mailegu-eskaera berriak barneratzeaz eta osatzeaz arduratzen da.   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. Lehena Bigarren  Gainera, azpisistema hauek bi talde ezberdinek kudeatzen dituzte, bakoitza bere kaleratze-ziklo, zerbitzu-maila-hitzarmenak (SLA) eta eskalagarritasun-eskakizunekin.    , jakinarazpen zerbitzu espezializatu bat dago bezeroei alertak bidaltzeko.  Azkenik Hona hemen sistemaren lehen erabilera-kasuaren deskribapen zehatza:  Bezero batek mailegu eskaera bat aurkezten du.  Maileguak Eskatzeko Zerbitzuak eskaera berria "Zain" egoerarekin erregistratzen du eta balorazio-prozesua abiarazten du eskaera Ebaluazio Zerbitzura helaraziz.  Ebaluazio Zerbitzuak sarrerako mailegu-eskaera ebaluatzen du eta, ondoren, mailegu-eskaera-zerbitzuari ebazpenaren berri ematen dio.  Erabakia jasotzean, mailegu-eskaeraren zerbitzuak horren arabera eguneratzen du mailegu-eskaeraren egoera eta Jakinarazpen Zerbitzua abiarazten du bezeroari emaitzaren berri emateko.  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:    Ikuspegi honetan, zerbitzuak bere datu-base lokala eguneratzen du (konpromisoak) eta gero gertaera edo mezu bat argitaratzen du beste zerbitzu batzuetara. Lehen-Tokiko-Konpromisoa-Gero-Argitaratu:    Aldiz, metodo honek gertaera edo mezu bat argitaratzea dakar tokiko datu-basean aldaketak konprometitu aurretik. Lehen-Publikatu-Gero-Local-Konprometitua:  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   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. Lehen-Tokiko Konpromisoa-Gero-Publikatu     Eta bigarrena.    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. Lehen-Argitaratu-Gero Tokiko-Konprometitutako  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.  Bermerik ez  Ez dago bermerik mezua helmugara bidaliko denik.   planteamendua horren ingurukoa da hain zuzen. Kontsumitzaileek mezuak behin, hainbat aldiz edo inoiz ez jaso ditzakete. Lehen-Tokiko-Konprometitu-Gero-Argitaratu  Gehienez behin entrega  Gehienez behin bidaltzeak esan nahi du mezua helmugara gehienez 1 aldiz bidaliko dela.   ikuspegia modu honetan inplementa daiteke, baita bat balioa duten saiakeren berragiteko politikarekin ere. Lehen-Tokiko-Konpromisoa-Gero-Argitaratu  Gutxienez behin entrega\Kontsumitzaileek mezu guztiak jasoko dituzte eta prozesatuko dituzte, baina baliteke mezu bera behin baino gehiagotan jasotzea.  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,   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. "gutxienez behin"  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  '   ' 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-ontzia  Transakzio-irteera-ontzi batek   eskaintzen du eta hainbat ikuspegirekin inplementa daiteke: gutxienez behin bermea  Transakzioen erregistroaren amaiera  Inkesta argitaletxea    ikuspegiak CDC (Change Data Capture) bezalako datu-baseetarako irtenbide espezifikoak erabiltzea dakar. Ikuspegi horren eragozpen nagusiak hauek dira: Transakzio-erregistroa biltzeko  Datu-basearen irtenbide espezifikoak  Latentzia handitu da CDC inplementazioen berezitasunengatik  Beste metodo bat   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. Polling Publisher  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(); }    Ez kezkatu, desplazamendua oraindik konprometitu ez denez, mezua berriro saiatuko da. Zer gertatzen da negozio-logikaren prozesamenduak 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. Kafkari gertaera berriak bidaltzeak 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. Zer gertatzen da mezuak Kafkari bidaltzen badira, baina desplazamendu-konpromisoak huts egiten badu?  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  Garatu beti kontsumitzaile idepotenteak sarearen hutsegite saihestezina baita.  Erabili arretaz   berme-eskakizunak argi ulertuta. Lehen-Tokiko-Konpromisoa-Gero-Argitaratu  Ez erabili inoiz   ikuspegia, zure sisteman datu-inkoherentzia larria ekar dezakeelako. First-Publish-Then-Local-Commit  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   bezalako datu-baseen soluzioekin lotuz. CDC  Erabili   ikuspegia irtenbide estandar gisa, gutxienez behin bermeak lortzeko. Transakzio Irteera-ontziaren  Kontuan izan   ikuspegia erabiltzea No-SQL datu-baseak aprobetxatzen direnean. Entzun zeure buruari  Hurrengoan, Transakzio Irteera-ontzia ezartzearen adibide praktikoago bat ikusiko dugu. Ikusi  zu!

Read My Stories

Audio hau istorioaren jatorrizko hizkuntzan ekoitzi da!

Luzeegia; Irakurri

Make resilience your competitive advantage

Sistema banatuetan mezularitza fidagarria

About Author

IRUZKINAK

ESKEGI ETIKETAK

ARTIKULU HAU AURKEZTU ZEN

Related Stories

The Most Consequential Technology Stories of 2023, According to HackerNoon Editors

THE SWORD OF PEACE

"Crypto Payments Will Become Commonplace In the Next 5 Years" - CoinsPaid’s CMO Eugen Kuzin

SECONDARY SEXUAL CHARACTERS OF MAN

The Most Consequential Technology Stories of 2023, According to HackerNoon Editors

THE SWORD OF PEACE

"Crypto Payments Will Become Commonplace In the Next 5 Years" - CoinsPaid’s CMO Eugen Kuzin

SECONDARY SEXUAL CHARACTERS OF MAN

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps