Įvykiais Grįsta Architektūra: Mastelio Keitimui Pritaikytų Sistemų Pranešimų Šablonų Įvaldymas

Įvykiais Grįsta Architektūra (ĮGA) yra programinės įrangos architektūros paradigma, kurios pagrindas – įvykių generavimas, aptikimas ir vartojimas. Užuot naudojus glaudžiai susietas paslaugų sąveikas, ĮGA skatina asinchroninį ryšį, kuris leidžia kurti mastelio keitimui labiau pritaikytas, atsparesnes ir atsietas sistemas. Pagrindinis ĮGA komponentas yra efektyvus pranešimų šablonų naudojimas. Šiame vadove nagrinėjami įvairūs ĮGA dažniausiai naudojami pranešimų šablonai, pateikiami praktiniai pavyzdžiai ir gerosios praktikos gairės pasaulinėms kūrėjų komandoms.

Kas yra Įvykiais Grįsta Architektūra?

Tradicinėje užklausos/atsakymo architektūroje paslaugos tiesiogiai iškviečia viena kitą. Šis glaudus susiejimas gali sukelti sistemos apkrovas ir padaryti sistemas trapias. Kita vertus, ĮGA atsieją paslaugas, įvesdama įvykių magistralę arba pranešimų brokerį. Paslaugos bendrauja publikuodamos įvykius magistralėje, o kitos paslaugos prenumeruoja jas dominančius įvykius. Šis asinchroninis ryšys leidžia paslaugoms veikti nepriklausomai, pagerindamas mastelio keitimo galimybes ir atsparumą gedimams.

Pagrindiniai ĮGA Privalumai

• Atsiejimas: Paslaugos yra nepriklausomos ir joms nereikia žinoti viena apie kitą.
• Mastelio keitimas: Atskiros paslaugos gali būti keičiamos masteliu nepriklausomai, atsižvelgiant į poreikį.
• Atsparumas: Vienos paslaugos gedimas nebūtinai paveikia kitas paslaugas.
• Lankstumas: Naujos paslaugos gali būti pridedamos arba pašalinamos nepaveikiant esamų.
• Reagavimas realiuoju laiku: Paslaugos gali reaguoti į įvykius beveik realiuoju laiku.

Dažniausiai Pasitaikantys Pranešimų Šablonai Įvykiais Grįstoje Architektūroje

ĮGA gali būti naudojami keli pranešimų šablonai, kurių kiekvienas turi savo privalumų ir trūkumų. Tinkamo šablono pasirinkimas priklauso nuo konkrečių jūsų programos reikalavimų.

1. Publikavimas-Prenumerata (Pub-Sub)

Publikavimo-prenumeratos šablonas yra vienas iš pagrindinių pranešimų šablonų ĮGA. Pagal šį šabloną, publikuotojai siunčia pranešimus į temą arba keitimosi tašką (exchange), o prenumeratoriai registruoja savo susidomėjimą konkrečiomis temomis. Tada pranešimų brokeris nukreipia pranešimus iš publikuotojų visiems suinteresuotiems prenumeratoriams.

Pavyzdys

Įsivaizduokite el. prekybos platformą. Kai klientas pateikia užsakymą, „Orders“ temoje publikuojamas „OrderCreated“ įvykis. Tokios paslaugos kaip atsargų, mokėjimų ir pristatymo paslaugos prenumeruoja „Orders“ temą ir atitinkamai apdoroja įvykį.

Įgyvendinimas

Pub-Sub galima įgyvendinti naudojant pranešimų brokerius, tokius kaip Apache Kafka, RabbitMQ, arba debesijos pranešimų paslaugas, tokias kaip AWS SNS/SQS ar Azure Service Bus. Konkrečios įgyvendinimo detalės priklauso nuo pasirinktos technologijos.

Privalumai

• Atsiejimas: Publikuotojai ir prenumeratoriai yra visiškai atsieti.
• Mastelio keitimas: Prenumeratoriai gali būti pridedami arba šalinami nepaveikiant publikuotojų.
• Lankstumas: Nauji įvykių tipai gali būti įvedami nereikalaujant pakeitimų esamose paslaugose.

Trūkumai

• Sudėtingumas: Didelėse sistemose temų ir prenumeratų valdymas gali tapti sudėtingas.
• Galutinis suderinamumas: Prenumeratoriai gali negauti įvykių iš karto, kas lemia galutinį suderinamumą.

2. Įvykių Kaupimas (Event Sourcing)

Įvykių kaupimas yra šablonas, pagal kurį visi programos būsenos pakeitimai fiksuojami kaip įvykių seka. Užuot saugojus dabartinę esybės būseną, programa saugo įvykių, kurie lėmė tą būseną, istoriją. Dabartinę būseną galima atkurti atkuriant įvykius.

Pavyzdys

Įsivaizduokite bankininkystės programą. Užuot saugojus dabartinį sąskaitos likutį, programa saugo tokius įvykius kaip „Indėlis“, „Išėmimas“ ir „Pervedimas“. Dabartinis likutis gali būti apskaičiuotas atkuriant šiuos įvykius eilės tvarka.

Įgyvendinimas

Įvykių kaupimas paprastai apima įvykių saugojimą įvykių saugykloje (event store), kuri yra specializuota duomenų bazė, optimizuota įvykiams saugoti ir gauti. Apache Kafka dažnai naudojama kaip įvykių saugykla dėl jos gebėjimo apdoroti didelius įvykių kiekius ir užtikrinti griežtas eiliškumo garantijas.

Privalumai

• Audito galimybė: Prieinama visa pakeitimų istorija.
• Derinimas: Lengviau derinti problemas atkuriant įvykius.
• Laikinės užklausos: Galimybė pateikti užklausą apie programos būseną bet kuriuo laiko momentu.
• Atkuriamumas: Galimybė atkurti įvykius, siekiant atstatyti būseną ar sukurti naujas projekcijas.

Trūkumai

• Sudėtingumas: Įvykių kaupimo įgyvendinimas gali būti sudėtingas.
• Saugojimas: Reikia saugoti didelį kiekį įvykių duomenų.
• Užklausos: Užklausų teikimas įvykių saugyklai gali būti sudėtingas.

3. Komandų ir Užklausų Atsakomybių Atskyrimas (CQRS)

CQRS yra šablonas, kuris atskiria duomenų saugyklos skaitymo ir rašymo operacijas. Jis apibrėžia du skirtingus modelius: komandų modelį rašymo operacijoms tvarkyti ir užklausų modelį skaitymo operacijoms tvarkyti. Šis atskyrimas leidžia optimizuoti kiekvieną modelį pagal jo konkretų tikslą.

Pavyzdys

El. prekybos programoje komandų modelis galėtų tvarkyti tokias operacijas kaip užsakymų kūrimas, produkto informacijos atnaujinimas ir mokėjimų apdorojimas. Užklausų modelis galėtų tvarkyti tokias operacijas kaip produktų sąrašų rodymas, užsakymų istorijos rodymas ir ataskaitų generavimas.

Įgyvendinimas

CQRS dažnai naudojamas kartu su įvykių kaupimu. Komandos naudojamos įvykiams sukelti, kurie vėliau naudojami skaitymo modeliams atnaujinti. Skaitymo modeliai gali būti optimizuoti konkretiems užklausų šablonams, užtikrinant greitesnį ir efektyvesnį skaitymo našumą.

Privalumai

• Našumas: Skaitymo ir rašymo operacijos gali būti optimizuojamos nepriklausomai.
• Mastelio keitimas: Skaitymo ir rašymo modelių mastelį galima keisti nepriklausomai.
• Lankstumas: Skaitymo ir rašymo modeliai gali vystytis nepriklausomai.

Trūkumai

• Sudėtingumas: CQRS įgyvendinimas gali žymiai padidinti sudėtingumą.
• Galutinis suderinamumas: Skaitymo modeliai gali būti ne iš karto suderinami su rašymo modeliu.

4. Užklausa-Atsakymas

Nors ĮGA skatina asinchroninį ryšį, yra scenarijų, kai užklausos-atsakymo šablonas vis dar yra būtinas. Pagal šį šabloną, viena paslauga siunčia užklausos pranešimą kitai paslaugai ir laukia atsakymo pranešimo.

Pavyzdys

Vartotojo sąsaja gali siųsti užklausą į posistemę (backend), kad gautų vartotojo profilio informaciją. Posistemė apdoroja užklausą ir siunčia atsakymą su vartotojo profilio duomenimis.

Įgyvendinimas

Užklausos-atsakymo šabloną galima įgyvendinti naudojant pranešimų brokerius, kurie palaiko užklausos-atsakymo semantiką, pavyzdžiui, RabbitMQ. Užklausos pranešime paprastai yra koreliacijos ID, kuris naudojamas atsakymo pranešimui suderinti su pradine užklausa.

Privalumai

• Paprastumas: Santykinai paprasta įgyvendinti, palyginti su kitais pranešimų šablonais.
• Sinchroniškumo imitacija: Suteikia sinchroniškumą primenančią sąveiką per asinchroninę pranešimų infrastruktūrą.

Trūkumai

• Glaudus susiejimas: Paslaugos yra glaudžiau susietos, palyginti su grynai asinchroniniais šablonais.
• Blokavimas: Užklausą teikianti paslauga blokuojama, kol laukia atsakymo.

5. Saga

Saga yra šablonas, skirtas ilgalaikėms transakcijoms, apimančioms kelias paslaugas, valdyti. Paskirstytoje sistemoje viena transakcija gali apimti atnaujinimus keliose duomenų bazėse ar paslaugose. Saga užtikrina, kad šie atnaujinimai būtų atlikti nuosekliai, net ir esant gedimams.

Pavyzdys

Apsvarstykite el. prekybos užsakymų apdorojimo scenarijų. Saga gali apimti šiuos veiksmus: 1. Sukurti užsakymą užsakymų paslaugoje. 2. Rezervuoti atsargas atsargų paslaugoje. 3. Apdoroti mokėjimą mokėjimų paslaugoje. 4. Išsiųsti užsakymą pristatymo paslaugoje.

Jei kuris nors iš šių veiksmų nepavyksta, saga turi kompensuoti ankstesnius veiksmus, kad sistema išliktų nuoseklioje būsenoje. Pavyzdžiui, jei mokėjimas nepavyksta, saga turi atšaukti užsakymą ir atlaisvinti rezervuotas atsargas.

Įgyvendinimas

Yra du pagrindiniai sagų įgyvendinimo būdai: 1. Choreografija paremta saga: Kiekviena sagoje dalyvaujanti paslauga yra atsakinga už įvykių, kurie sukelia kitą sagos žingsnį, publikavimą. Nėra centrinio orkestratoriaus. 2. Orkestracija paremta saga: Centrinė orkestratoriaus paslauga valdo sagą ir koordinuoja susijusius veiksmus. Orkestratorius siunčia komandas dalyvaujančioms paslaugoms ir laukia įvykių, rodančių kiekvieno žingsnio sėkmę ar nesėkmę.

Privalumai

• Nuoseklumas: Užtikrina duomenų nuoseklumą tarp kelių paslaugų.
• Atsparumas gedimams: Sklandžiai tvarko gedimus ir užtikrina, kad sistema atsigautų į nuoseklią būseną.

Trūkumai

• Sudėtingumas: Sagų įgyvendinimas gali būti sudėtingas, ypač ilgalaikėms transakcijoms.
• Kompensavimo logika: Reikia įgyvendinti kompensavimo logiką, kad būtų atšaukti nepavykusių žingsnių padariniai.

Tinkamo Pranešimų Šablono Pasirinkimas

Pranešimų šablono pasirinkimas priklauso nuo konkrečių jūsų programos reikalavimų. Priimdami sprendimą, atsižvelkite į šiuos veiksnius:

• Nuoseklumo reikalavimai: Ar jums reikia griežto nuoseklumo, ar galutinio suderinamumo?
• Uždelsimo reikalavimai: Kaip greitai paslaugos turi reaguoti į įvykius?
• Sudėtingumas: Kiek sudėtinga įgyvendinti ir palaikyti šabloną?
• Mastelio keitimas: Kaip gerai šablonas pritaikomas dideliems įvykių kiekiams apdoroti?
• Atsparumas gedimams: Kaip gerai šablonas tvarkosi su gedimais?

Štai lentelė, apibendrinanti pagrindines kiekvieno pranešimų šablono charakteristikas:

Šablonas	Aprašymas	Suderinamumas	Sudėtingumas	Panaudojimo Atvejai
Pub-Sub	Publikuotojai siunčia pranešimus į temas, prenumeratoriai gauna pranešimus iš temų.	Galutinis	Vidutinis	Pranešimai, įvykių paskirstymas, paslaugų atsiejimas.
Įvykių Kaupimas	Saugoti visus programos būsenos pakeitimus kaip įvykių seką.	Griežtas	Aukštas	Auditas, derinimas, laikinės užklausos, būsenos atkūrimas.
CQRS	Atskirti skaitymo ir rašymo operacijas į skirtingus modelius.	Galutinis (skaitymo modeliams)	Aukštas	Skaitymo ir rašymo našumo optimizavimas, skaitymo ir rašymo operacijų mastelio keitimas nepriklausomai.
Užklausa-Atsakymas	Paslauga siunčia užklausą ir laukia atsakymo.	Iš karto	Paprastas	Sinchroniškumą primenančios sąveikos per asinchroninę pranešimų sistemą.
Saga	Valdyti ilgalaikes transakcijas, apimančias kelias paslaugas.	Galutinis	Aukštas	Paskirstytosios transakcijos, užtikrinančios duomenų nuoseklumą tarp kelių paslaugų.

Geroji Praktika Įgyvendinant ĮGA Pranešimų Šablonus

Štai keletas gerosios praktikos gairių, į kurias reikėtų atsižvelgti įgyvendinant ĮGA pranešimų šablonus:

• Pasirinkite tinkamą pranešimų brokerį: Pasirinkite pranešimų brokerį, kuris atitinka jūsų programos reikalavimus. Atsižvelkite į tokius veiksnius kaip mastelio keitimas, patikimumas ir funkcijų rinkinys. Populiarūs pasirinkimai yra Apache Kafka, RabbitMQ ir debesijos pranešimų paslaugos.
• Apibrėžkite aiškias įvykių schemas: Apibrėžkite aiškias ir gerai apibrėžtas įvykių schemas, kad paslaugos galėtų teisingai suprasti ir apdoroti įvykius. Naudokite schemų registrus įvykių schemoms valdyti ir tikrinti.
• Įgyvendinkite idempotentinius vartotojus: Užtikrinkite, kad jūsų vartotojai būtų idempotentūs, t. y. galėtų apdoroti tą patį įvykį kelis kartus, nesukeldami nenumatytų šalutinių poveikių. Tai svarbu tvarkant gedimus ir užtikrinant patikimą įvykių apdorojimą.
• Stebėkite savo sistemą: Stebėkite savo sistemą, kad aptiktumėte ir diagnozuotumėte problemas. Sekite pagrindinius rodiklius, tokius kaip įvykių uždelsimas, pranešimų pralaidumas ir klaidų dažnis.
• Naudokite paskirstytąjį sekimą: Naudokite paskirstytąjį sekimą (distributed tracing), kad galėtumėte sekti įvykius, kai jie keliauja per jūsų sistemą. Tai gali padėti nustatyti našumo kliūtis ir šalinti problemas.
• Atsižvelkite į saugumą: Apsaugokite savo įvykių magistralę ir pranešimų eiles, kad apsisaugotumėte nuo neteisėtos prieigos. Naudokite autentifikavimą ir autorizavimą, kad kontroliuotumėte, kas gali publikuoti ir prenumeruoti įvykius.
• Sklandžiai tvarkykite klaidas: Įdiekite klaidų tvarkymo mechanizmus, kad galėtumėte tvarkyti gedimus ir užtikrinti patikimą įvykių apdorojimą. Naudokite „dead-letter“ eiles neapdorojamiems įvykiams saugoti.

Pavyzdžiai iš Realaus Pasaulio

ĮGA ir su ja susiję pranešimų šablonai naudojami įvairiose pramonės šakose ir programose. Štai keletas pavyzdžių:

• El. prekyba: Užsakymų apdorojimas, atsargų valdymas, pranešimai apie pristatymą.
• Finansinės paslaugos: Sukčiavimo aptikimas, transakcijų apdorojimas, rizikos valdymas.
• Sveikatos apsauga: Pacientų stebėjimas, vizitų planavimas, medicininių įrašų valdymas.
• Daiktų internetas (IoT): Jutiklių duomenų apdorojimas, įrenginių valdymas, nuotolinis valdymas.
• Socialiniai tinklai: Naujienų srauto atnaujinimai, pranešimai, vartotojų veiklos sekimas.

Pavyzdžiui, pasaulinė maisto pristatymo paslauga gali naudoti ĮGA užsakymams valdyti. Kai klientas pateikia užsakymą, publikuojamas `OrderCreated` įvykis. Restorano paslauga prenumeruoja šį įvykį, kad paruoštų maistą. Pristatymo paslauga prenumeruoja šį įvykį, kad priskirtų vairuotoją. Mokėjimų paslauga prenumeruoja šį įvykį, kad apdorotų mokėjimą. Kiekviena paslauga veikia nepriklausomai ir asinchroniškai, leisdama sistemai efektyviai apdoroti didelį užsakymų skaičių.

Išvados

Įvykiais Grįsta Architektūra yra galinga paradigma, skirta kurti mastelio keitimui pritaikytas, atsparias ir atsietas sistemas. Suprasdami ir efektyviai naudodami pranešimų šablonus, kūrėjai gali kurti tvirtas ir lanksčias programas, kurios gali prisitaikyti prie kintančių verslo reikalavimų. Šiame vadove pateikta ĮGA dažniausiai naudojamų pranešimų šablonų apžvalga, kartu su praktiniais pavyzdžiais ir gerosios praktikos gairėmis. Tinkamo šablono pasirinkimas atsižvelgiant į konkrečius poreikius yra labai svarbus kuriant sėkmingas įvykiais grįstas sistemas. Priimdami sprendimą, nepamirškite atsižvelgti į nuoseklumą, uždelsimą, sudėtingumą, mastelio keitimą ir atsparumą gedimams. Pasinaudokite asinchroninio ryšio galia ir atskleiskite visą savo programų potencialą.