Dubultā rakstīšanas problēma  Lai izveidotu uzticamu, ļoti pieejamu, mērogojamu sadalīto sistēmu, ir jāievēro noteiktas metodes, principi un modeļi. Šādu sistēmu projektēšana ietver neskaitāmu problēmu risināšanu. Viena no visizplatītākajām un pamata problēmām ir   . dubultā rakstīšanas problēma    ir problēma, kas rodas sadalītās sistēmās, galvenokārt, strādājot ar vairākiem datu avotiem vai datu bāzēm, kuras ir jāsaglabā sinhronizācijā. Tas attiecas uz grūtībām nodrošināt, ka datu izmaiņas tiek konsekventi ierakstītas dažādos datu krātuvēs, piemēram, datu bāzēs vai kešatmiņā, neradot tādas problēmas kā datu neatbilstības, konflikti vai veiktspējas vājās vietas. “Divkāršās rakstīšanas problēma”  Mikropakalpojumu arhitektūra un modeļu datubāze katram pakalpojumam sniedz daudzas priekšrocības, piemēram, neatkarīgu izvietošanu un mērogošanu, izolētas kļūmes un potenciālu attīstības ātruma palielinājumu. Tomēr operācijām ir nepieciešamas izmaiņas starp vairākiem mikropakalpojumiem, liekot jums domāt par uzticamu risinājumu šīs problēmas risināšanai.   Gandrīz reāls piemērs  Apskatīsim scenāriju, kurā mūsu domēns ietver aizdevuma pieteikumu pieņemšanu, to izvērtēšanu un pēc tam paziņojumu brīdinājumu nosūtīšanu klientiem.  Atbilstoši vienotās atbildības principam, Konveja likumam un uz domēnu orientētai dizaina pieejai pēc vairākām notikumu vētras sesijām viss domēns tika sadalīts trīs apakšdomēnos ar definētiem ierobežotiem kontekstiem ar skaidrām robežām, domēna modeļiem un visuresošu valodu.    uzdevums ir iekļauties un apkopot jaunus aizdevuma pieteikumus.   sistēma izvērtē šos pieteikumus un pieņem lēmumus, pamatojoties uz sniegtajiem datiem. Šis novērtēšanas process, tostarp KYC/KYB, krāpšanas apkarošana un kredītriska pārbaudes, var būt laikietilpīgs, tādēļ ir nepieciešama iespēja vienlaikus apstrādāt tūkstošiem pieteikumu. Līdz ar to šī funkcionalitāte ir deleģēta īpašam mikropakalpojumam ar savu datu bāzi, kas ļauj veikt neatkarīgu mērogošanu. Pirmā Otrā  Turklāt šīs apakšsistēmas pārvalda divas dažādas komandas, katrai no tām ir savi izlaišanas cikli, pakalpojumu līmeņa līgumi (SLA) un mērogojamības prasības.    , ir izveidots specializēts paziņojumu pakalpojums, lai nosūtītu brīdinājumus klientiem.  Visbeidzot Šeit ir precizēts sistēmas primārās lietošanas gadījuma apraksts:  Klients iesniedz kredīta pieteikumu.  Aizdevuma pieteikumu dienests fiksē jauno pieteikumu ar statusu "Gaida" un uzsāk vērtēšanas procesu, pārsūtot pieteikumu Vērtēšanas dienestam.  Novērtēšanas dienests izvērtē ienākošo aizdevuma pieteikumu un pēc tam informē Aizdevuma pieteikumu dienestu par lēmumu.  Saņemot lēmumu, Aizdevuma pieteikumu dienests attiecīgi atjaunina aizdevuma pieteikuma statusu un iedarbina Paziņojumu dienestu, lai informētu klientu par iznākumu.  Paziņojumu pakalpojums apstrādā šo pieprasījumu un nosūta paziņojumus klientam pa e-pastu, SMS vai citām vēlamajām saziņas metodēm atbilstoši klienta iestatījumiem.  No pirmā acu uzmetiena tā ir diezgan vienkārša un primitīva sistēma, taču iedziļināsimies tajā, kā Aizdevuma pieteikumu dienests apstrādā aizdevuma pieteikuma iesniegšanas komandu.  Mēs varam apsvērt divas pieejas pakalpojumu mijiedarbībai:    izmantojot šo pieeju, pakalpojums atjaunina savu lokālo datu bāzi (apņemas) un pēc tam publicē notikumu vai ziņojumu citiem pakalpojumiem. First-Local-Commit-Then-Publish:    otrādi, šī metode ietver notikuma vai ziņojuma publicēšanu pirms izmaiņu veikšanas vietējā datu bāzē. Vispirms publicējiet, pēc tam lokāli apstipriniet:  Abām metodēm ir savi trūkumi, un tās ir tikai daļēji drošas saziņai sadalītajās sistēmās.     Šī ir pirmās pieejas piemērošanas secības diagramma.  Šajā scenārijā aizdevuma pieteikuma pakalpojums izmanto pieeju   , kur tas vispirms veic darījumu un pēc tam mēģina nosūtīt paziņojumu citai sistēmai. Tomēr šis process var neizdoties, ja, piemēram, rodas tīkla problēmas, Novērtējuma pakalpojums nav pieejams vai aizdevuma pieteikuma pakalpojums konstatē Trūkst atmiņas (OOM) kļūdu un avarē. Šādos gadījumos ziņojums tiktu pazaudēts, atstājot Novērtējumu bez brīdinājuma par jauno aizdevuma pieteikumu, ja vien netiks īstenoti papildu pasākumi. First-Local-commit-then-Publish     Un otrais.  Scenārijā   , aizdevuma pieteikuma pakalpojums saskaras ar nozīmīgākiem riskiem. Tas var informēt novērtēšanas dienestu par jaunu lietojumprogrammu, bet nevar saglabāt šo atjauninājumu lokāli tādu problēmu dēļ kā datu bāzes problēmas, atmiņas kļūdas vai koda kļūdas. Šāda pieeja var radīt būtiskas datu neatbilstības, kas var radīt nopietnas problēmas atkarībā no tā, kā Kredīta pārskatīšanas pakalpojums apstrādā ienākošos pieteikumus. vispirms publicējiet, pēc tam vietējās saistības  Tāpēc mums ir jāidentificē risinājums, kas piedāvā stabilu mehānismu notikumu publicēšanai ārējiem patērētājiem. Bet, pirms iedziļināties potenciālajos risinājumos, mums vispirms ir jānoskaidro izplatītajās sistēmās sasniedzamo ziņojumu piegādes garantiju veidi.  Ziņu piegādes garantijas  Mēs varam sasniegt četru veidu garantijas.  Nekādu garantiju  Nav garantijas, ka ziņojums tiks piegādāts galamērķim. Pieeja   ir tieši par to. Patērētāji var saņemt ziņojumus vienu reizi, vairākas reizes vai vispār nesaņemt. First-Local-Commit-Then-Publish  Piegāde ne vairāk kā vienreiz  Ne vairāk kā vienreizēja piegāde nozīmē, ka ziņa tiks piegādāta galamērķim ne vairāk kā 1 reizi. Pieeju   var īstenot arī šādā veidā, izmantojot mēģinājumu atkārtošanas politiku ar vērtību viens. First-Local-Commit-Then-Publish  Vismaz vienu reizi piegāde\Patērētāji saņems un apstrādās katru ziņojumu, taču vienu un to pašu ziņojumu var saņemt vairāk nekā vienu reizi.  Precīzi vienreiz piegāde\Tieši vienreiz piegāde nozīmē, ka patērētājs ziņojumu saņems vienu reizi.  Tehniski to iespējams panākt ar Kafkas darījumiem un specifisku idempotentu ražotāja un patērētāja ieviešanu.  Vairumā gadījumu   piegādes garantijas risina daudzas problēmas, nodrošinot, ka ziņojumi tiek piegādāti vismaz vienu reizi, taču patērētājiem ir jābūt nespējīgiem. Tomēr, ņemot vērā nenovēršamās tīkla atteices, visai patērētāju loģikai ir jābūt idempotai, lai izvairītos no dublētu ziņojumu apstrādes neatkarīgi no ražotāja garantijām. Tāpēc šī prasība ir ne tik daudz trūkums, cik tā atspoguļo realitāti. “vismaz vienreizējas”  Risinājumi  Šai problēmai ir daudz risinājumu, kuriem ir savas priekšrocības un trūkumi.   Divu fāžu apņemšanās  Saskaņā ar Wikipedia teikto, divu fāžu apņemšanās (2PC) ir izplatīts transakciju protokols, ko izmanto datorzinātnēs un datu bāzu pārvaldības sistēmās, lai nodrošinātu izplatīto darījumu konsekvenci un uzticamību. Tas ir paredzēts situācijām, kad vienā transakcijā ir jāpiedalās vairākiem resursiem (piemēram, datu bāzēm), un tas nodrošina, ka vai nu visi no tiem veic darījumu, vai arī visi to pārtrauc, tādējādi saglabājot datu konsekvenci. Tas izklausās tieši tas, kas mums nepieciešams, taču divu fāzu ieviešanai ir vairāki trūkumi:  Ja kāds iesaistītais resurss nereaģē vai rodas kļūme, visu procesu var bloķēt, līdz problēma tiek atrisināta. Tas var izraisīt iespējamās veiktspējas un pieejamības problēmas.  Divfāžu apstiprināšana nenodrošina iebūvētus kļūdu pielaides mehānismus. Tas paļaujas uz ārējiem mehānismiem vai manuālu iejaukšanos, lai novērstu kļūmes.  Ne visas mūsdienu datu bāzes atbalsta divu fāzu apstiprināšanu.   Koplietojama datu bāze  Acīmredzamākais risinājums mikropakalpojumu arhitektūrai ir izmantot modeli (vai pat dažreiz anti-paternu) — koplietotu datu bāzi. Šī pieeja ir ļoti intuitīva, ja jums ir nepieciešama darījumu konsekvence vairākās tabulās dažādās datu bāzēs, vienkārši izmantojiet vienu koplietotu datu bāzi šiem mikropakalpojumiem.  Šīs pieejas trūkumi ietver viena atteices punkta ieviešanu, neatkarīgas datu bāzes mērogošanas kavēšanu un iespēju ierobežošanu izmantot dažādus datu bāzes risinājumus, kas ir vislabāk piemēroti konkrētām prasībām un lietošanas gadījumiem. Turklāt, lai atbalstītu šādu izplatītu darījumu veidu, būtu nepieciešamas izmaiņas mikropakalpojumu kodu bāzēs.   Darījumu izsūtne    ir dizaina modelis, ko izmanto sadalītās sistēmās, lai nodrošinātu uzticamu ziņojumu izplatīšanu pat neuzticamu ziņojumapmaiņas sistēmu gadījumā. Tas ietver notikumu glabāšanu norādītajā “OutboxEvents” tabulā tajā pašā darījumā, kurā tiek veikta pati operācija. Šī pieeja labi saskan ar relāciju datu bāzu ACID īpašībām. Turpretim daudzas datu bāzes bez SQL pilnībā neatbalsta ACID rekvizītus, tā vietā izvēloties CAP teorēmas un BASE filozofijas principus, kuros prioritāte ir pieejamība un iespējamā konsekvence, nevis stingra konsekvence. Transakciju izsūtne  Darījumu izsūtne nodrošina   , un to var ieviest ar vairākām pieejām: vismaz vienu garantiju  Darījumu žurnāla astes  Aptauju izdevējs    pieeja paredz izmantot datu bāzei specifiskus risinājumus, piemēram, CDC (Change Data Capture). Šīs pieejas galvenie trūkumi ir: Darījumu žurnāla slāņošanas  Datu bāzēm specifiski risinājumi  Palielināts latentums CDC ieviešanas specifikas dēļ  Vēl viena metode ir   , kas atvieglo izsūtnes izkraušanu, aptaujājot izsūtnes tabulu. Šīs pieejas galvenais trūkums ir iespēja palielināt datubāzes slodzi, kas var radīt lielākas izmaksas. Turklāt ne visas datu bāzes bez SQL atbalsta efektīvu konkrētu dokumentu segmentu vaicāšanu. Tāpēc visu dokumentu izvilkšana var izraisīt veiktspējas pasliktināšanos. Polling Publisher  Šeit ir neliela secības diagramma, kas izskaidro, kā tas darbojas.    Ieklausies sevī  Transakciju izsūtnes modeļa galvenais izaicinājums ir tā atkarība no datu bāzes ACID īpašībām. Tipiskās OLTP datu bāzēs tas varētu būt vienkārši, taču tas rada problēmas NoSQL jomā. Lai to atrisinātu, potenciāls risinājums ir izmantot pievienošanas žurnālu (piemēram, Kafka) tieši no pieprasījuma apstrādes uzsākšanas.  Tā vietā, lai tieši apstrādātu komandu “iesniegt aizdevuma pieteikumu”, mēs to nekavējoties nosūtām iekšējai Kafka tēmai un pēc tam atgriežam klientam “akceptētu” rezultātu. Tomēr, tā kā ir ļoti iespējams, ka komanda joprojām ir jāapstrādā, mēs nevaram nekavējoties informēt klientu par rezultātu. Lai pārvaldītu šo iespējamo konsekvenci, mēs varam izmantot tādas metodes kā ilgstoša aptauja, klienta iniciēta aptauja, optimistiski lietotāja saskarnes atjauninājumi vai WebSockets vai Server-Sent Events izmantošana paziņojumiem. Tomēr šī ir pavisam atsevišķa tēma, tāpēc atgriezīsimies pie sākotnējās tēmas.  Mēs nosūtījām ziņojumu par iekšējo Kafkas tēmu. Pēc tam aizdevuma pieteikuma pakalpojums izmanto šo ziņojumu — to pašu komandu, ko tas saņēma no klienta — un sāk apstrādi. Pirmkārt, tas izpilda kādu biznesa loģiku; tikai pēc tam, kad šī loģika ir veiksmīgi izpildīta un rezultāti tiek saglabāti, tas publicē jaunus ziņojumus par publisku Kafkas tēmu.  Apskatīsim mazliet pseidokodu.   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(); }    Neuztraucieties, jo kompensācija vēl nav veikta, ziņojums tiks mēģināts vēlreiz. Ko darīt, ja biznesa loģikas apstrāde neizdodas?    Neuztraucieties, jo biznesa loģika ir idempota, tāpēc tas neradīs aizdevuma pieteikuma dublikātu. Tā vietā tas mēģinās atkārtoti nosūtīt ziņojumus publiskajai Kafkas tēmai. Ko darīt, ja jaunu notikumu nosūtīšana Kafkai neizdodas?    Neuztraucieties, jo biznesa loģika ir idempota, tāpēc tas neradīs aizdevuma pieteikuma dublikātu. Tā vietā tas atkārtoti nosūtīs ziņojumus publiskajai Kafkas tēmai un cer, ka kompensācijas apņemšanās šoreiz izdosies. Ko darīt, ja ziņojumi tiek nosūtīti Kafkai, bet kompensācijas apņemšanās neizdodas?  Šīs pieejas galvenie trūkumi ietver papildu sarežģītību, kas saistīta ar jaunu programmēšanas stilu, iespējamo konsekvenci (jo klients uzreiz neuzzinās rezultātu) un prasību, lai visa biznesa loģika būtu idempotenta.  Pasākumu piegāde  Kas ir notikumu piegāde, un kā to varētu izmantot šeit? Notikumu iegūšana ir programmatūras arhitektūras modelis, ko izmanto, lai modelētu sistēmas stāvokli, tverot visas izmaiņas tās datos kā nemainīgu notikumu virkni. Šie notikumi atspoguļo faktus vai stāvokļa pārejas un kalpo kā vienīgais patiesības avots sistēmas pašreizējam stāvoklim. Tātad tehniski, ieviešot notikumu avotu sistēmu, mums jau ir EventStore visi notikumi, un šo EventStore patērētāji var izmantot kā vienotu patiesības avotu par notikušo. Nav nepieciešams īpašs datu bāzes risinājums, lai izsekotu visas izmaiņas vai bažas par pasūtīšanu, vienīgā problēma ir sēdēšana lasīšanas pusē, jo, lai varētu iegūt faktisko entītijas stāvokli, ir nepieciešams atkārtoti atskaņot visus notikumus.  Secinājums  Šajā rakstā mēs apskatījām vairākas pieejas uzticamas ziņojumapmaiņas izveidei sadalītās sistēmās. Ir vairāki ieteikumi, kurus mēs varētu apsvērt, veidojot sistēmas ar šīm īpašībām  Vienmēr attīstiet idempotentus patērētājus, jo tīkla kļūme ir neizbēgama.  Uzmanīgi izmantojiet   skaidri izprotot garantijas prasības. First-Local-Commit-Then-Publish,  Nekad neizmantojiet pieeju   jo tas var izraisīt nopietnu datu nekonsekvenci jūsu sistēmā. vispirms publicējiet, pēc tam lokāli,  Ja pastāvošais datu bāzes izvēles lēmums, ļoti iespējams, var mainīties vai tehniskā stratēģija paredz problēmas risināšanai izvēlēties labāko krātuves risinājumu, neveidojiet koplietojamas bibliotēkas, piesaistot datu bāzes risinājumus, piemēram,   . CDC  Izmantojiet   pieeju kā standarta risinājumu, lai vismaz vienreiz iegūtu garantijas. Transakciju izsūtnes  Apsveriet iespēju izmantot pieeju   ja tiek izmantotas datu bāzes bez SQL. Klausieties sevi,  Nākamajā reizē mēs apskatīsim praktiskāku transakciju izsūtnes ieviešanas piemēru. Skat  tu!

Read My Stories

Šis audio ir izveidots stāsta oriģinālvalodā!

Pārāk ilgi; Lasīt

Make resilience your competitive advantage

Uzticama ziņojumapmaiņa izplatītajās sistēmās

About Author

KOMENTĀRI

PAKARINĀT TAGUS

ŠIS RAKSTS TIKS PĀRSTRĀDĀTS

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps