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

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 .

“Divkāršās 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.

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.

Pirmā uzdevums ir iekļauties un apkopot jaunus aizdevuma pieteikumus. Otrā 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.

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.

Visbeidzot , ir izveidots specializēts paziņojumu pakalpojums, lai nosūtītu brīdinājumus klientiem.

Šeit ir precizēts sistēmas primārās lietošanas gadījuma apraksts:

1. Klients iesniedz kredīta pieteikumu.
2. Aizdevuma pieteikumu dienests fiksē jauno pieteikumu ar statusu "Gaida" un uzsāk vērtēšanas procesu, pārsūtot pieteikumu Vērtēšanas dienestam.
3. Novērtēšanas dienests izvērtē ienākošo aizdevuma pieteikumu un pēc tam informē Aizdevuma pieteikumu dienestu par lēmumu.
4. 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.
5. 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:

1. First-Local-Commit-Then-Publish: izmantojot šo pieeju, pakalpojums atjaunina savu lokālo datu bāzi (apņemas) un pēc tam publicē notikumu vai ziņojumu citiem pakalpojumiem.

2. Vispirms publicējiet, pēc tam lokāli apstipriniet: otrādi, šī metode ietver notikuma vai ziņojuma publicēšanu pirms izmaiņu veikšanas vietējā datu bāzē.

   
   

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 First-Local-commit-then-Publish , 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.

Un otrais.

Scenārijā vispirms publicējiet, pēc tam vietējās saistības , 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.

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.

1. Nekādu garantiju
   Nav garantijas, ka ziņojums tiks piegādāts galamērķim. Pieeja First-Local-Commit-Then-Publish ir tieši par to. Patērētāji var saņemt ziņojumus vienu reizi, vairākas reizes vai vispār nesaņemt.

2. 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 First-Local-Commit-Then-Publish var īstenot arī šādā veidā, izmantojot mēģinājumu atkārtošanas politiku ar vērtību viens.

3. 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.

4. 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 “vismaz vienreizējas” 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.

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

Transakciju 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.

Darījumu izsūtne nodrošina vismaz vienu garantiju , un to var ieviest ar vairākām pieejām:

1. Darījumu žurnāla astes

2. Aptauju izdevējs

   
   

Darījumu žurnāla slāņošanas pieeja paredz izmantot datu bāzei specifiskus risinājumus, piemēram, CDC (Change Data Capture). Šīs pieejas galvenie trūkumi ir:

• Datu bāzēm specifiski risinājumi

• Palielināts latentums CDC ieviešanas specifikas dēļ

  
  

Vēl viena metode ir Polling Publisher , 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.

Š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(); }

Ko darīt, ja biznesa loģikas apstrāde neizdodas? Neuztraucieties, jo kompensācija vēl nav veikta, ziņojums tiks mēģināts vēlreiz.

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 mēģinās atkārtoti nosūtīt ziņojumus publiskajai Kafkas tēmai.

Ko darīt, ja ziņojumi tiek nosūtīti Kafkai, bet kompensācijas apņemšanās 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.

Šī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

1. Vienmēr attīstiet idempotentus patērētājus, jo tīkla kļūme ir neizbēgama.
2. Uzmanīgi izmantojiet First-Local-Commit-Then-Publish, skaidri izprotot garantijas prasības.
3. Nekad neizmantojiet pieeju vispirms publicējiet, pēc tam lokāli, jo tas var izraisīt nopietnu datu nekonsekvenci jūsu sistēmā.
4. 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 .
5. Izmantojiet Transakciju izsūtnes pieeju kā standarta risinājumu, lai vismaz vienreiz iegūtu garantijas.
6. Apsveriet iespēju izmantot pieeju Klausieties sevi, ja tiek izmantotas datu bāzes bez SQL.

Nākamajā reizē mēs apskatīsim praktiskāku transakciju izsūtnes ieviešanas piemēru. Skat

tu!