CQRS: Komandų ir užklausų atsakomybės atskyrimo įvaldymas

Nuolat besikeičiančiame programinės įrangos architektūros pasaulyje programuotojai nuolat ieško šablonų ir praktikų, kurios skatina mastelio keitimą, prižiūrimumą ir našumą. Vienas iš tokių šablonų, kuris sulaukė didelio populiarumo, yra CQRS (Komandų ir užklausų atsakomybės atskyrimas). Šiame straipsnyje pateikiamas išsamus CQRS vadovas, nagrinėjantis jo principus, naudą, diegimo strategijas ir realaus pasaulio pritaikymą.

Kas yra CQRS?

CQRS yra architektūrinis šablonas, kuris atskiria duomenų saugyklos skaitymo ir rašymo operacijas. Jis siūlo naudoti skirtingus modelius komandoms (operacijoms, kurios keičia sistemos būseną) ir užklausoms (operacijoms, kurios nuskaito duomenis nekeičiant būsenos). Šis atskyrimas leidžia optimizuoti kiekvieną modelį atskirai, o tai lemia geresnį našumą, mastelio keitimą ir saugumą.

Tradicinės architektūros dažnai sujungia skaitymo ir rašymo operacijas viename modelyje. Nors iš pradžių tai yra paprasčiau įgyvendinti, toks požiūris gali sukelti keletą iššūkių, ypač kai sistema tampa sudėtingesnė:

Našumo problemos: Vienas duomenų modelis gali būti neoptimizuotas tiek skaitymo, tiek rašymo operacijoms. Sudėtingos užklausos gali sulėtinti rašymo operacijas ir atvirkščiai.
Mastelio keitimo apribojimai: Monolitinės duomenų saugyklos mastelio keitimas gali būti sudėtingas ir brangus.
Duomenų nuoseklumo problemos: Išlaikyti duomenų nuoseklumą visoje sistemoje gali tapti sudėtinga, ypač paskirstytose aplinkose.
Sudėtinga domeno logika: Skaitymo ir rašymo operacijų sujungimas gali lemti sudėtingą ir glaudžiai susijusį kodą, kurį sunkiau prižiūrėti ir tobulinti.

CQRS sprendžia šiuos iššūkius įvesdamas aiškų atsakomybių atskyrimą, leidžiantį programuotojams pritaikyti kiekvieną modelį pagal jo specifinius poreikius.

Pagrindiniai CQRS principai

CQRS grindžiamas keliais pagrindiniais principais:

Atsakomybių atskyrimas: Pagrindinis principas – atskirti komandų ir užklausų atsakomybes į skirtingus modelius.
Nepriklausomi modeliai: Komandų ir užklausų modeliai gali būti įgyvendinti naudojant skirtingas duomenų struktūras, technologijas ir net fizines duomenų bazes. Tai leidžia nepriklausomai optimizuoti ir keisti mastelį.
Duomenų sinchronizavimas: Kadangi skaitymo ir rašymo modeliai yra atskirti, duomenų sinchronizavimas yra labai svarbus. Paprastai tai pasiekiama naudojant asinchroninį pranešimų siuntimą arba įvykių šaltinio metodą.
Galutinis nuoseklumas: CQRS dažnai remiasi galutiniu nuoseklumu, o tai reiškia, kad duomenų atnaujinimai gali ne iš karto atsispindėti skaitymo modelyje. Tai leidžia pagerinti našumą ir mastelio keitimą, tačiau reikalauja atidžiai apsvarstyti galimą poveikį vartotojams.

CQRS nauda

CQRS diegimas gali suteikti daug naudos, įskaitant:

Geresnis našumas: Optimizuojant skaitymo ir rašymo modelius atskirai, CQRS gali žymiai pagerinti bendrą sistemos našumą. Skaitymo modeliai gali būti specialiai sukurti greitam duomenų gavimui, o rašymo modeliai gali būti skirti efektyviam duomenų atnaujinimui.
Patobulintas mastelio keitimas: Skaitymo ir rašymo modelių atskyrimas leidžia keisti jų mastelį nepriklausomai. Skaitymo replikos gali būti pridedamos siekiant valdyti padidėjusį užklausų krūvį, o rašymo operacijų mastelis gali būti keičiamas atskirai, naudojant tokias technikas kaip „sharding“.
Supaprastinta domeno logika: CQRS gali supaprastinti sudėtingą domeno logiką, atskiriant komandų apdorojimą nuo užklausų apdorojimo. Tai gali lemti lengviau prižiūrimą ir testuojamą kodą.
Didesnis lankstumas: Skirtingų technologijų naudojimas skaitymo ir rašymo modeliams suteikia daugiau lankstumo renkantis tinkamus įrankius kiekvienai užduočiai.
Geresnis saugumas: Komandų modelis gali būti sukurtas su griežtesniais saugumo apribojimais, o skaitymo modelis gali būti optimizuotas viešam naudojimui.
Geresnis auditas: Derinant su įvykių šaltinio metodu, CQRS suteikia išsamų visų sistemos būsenos pakeitimų audito seką.

Kada naudoti CQRS

Nors CQRS suteikia daug privalumų, tai nėra universalus sprendimas. Svarbu atidžiai apsvarstyti, ar CQRS yra tinkamas pasirinkimas konkrečiam projektui. CQRS yra naudingiausias šiais atvejais:

Sudėtingi domeno modeliai: Sistemos su sudėtingais domeno modeliais, kuriems reikalingi skirtingi duomenų vaizdai skaitymo ir rašymo operacijoms.
Didelis skaitymo/rašymo santykis: Programos, kuriose skaitymo operacijų apimtis yra žymiai didesnė nei rašymo.
Mastelio keitimo reikalavimai: Sistemos, kurioms reikalingas didelis mastelio keitimas ir našumas.
Integracija su įvykių šaltinio metodu: Projektai, kurie planuoja naudoti įvykių šaltinio metodą išsaugojimui ir auditui.
Nepriklausomos komandų atsakomybės: Situacijos, kai skirtingos komandos yra atsakingos už skaitymo ir rašymo dalis programoje.

Kita vertus, CQRS gali būti ne geriausias pasirinkimas paprastoms CRUD programoms ar sistemoms su mažais mastelio keitimo reikalavimais. Papildomas CQRS sudėtingumas tokiais atvejais gali nusverti jo naudą.

CQRS diegimas

CQRS diegimas apima keletą pagrindinių komponentų:

Komandos: Komandos reiškia ketinimą pakeisti sistemos būseną. Paprastai jos pavadinamos liepiamosios nuosakos veiksmažodžiais (pvz., `CreateCustomer`, `UpdateProduct`). Komandos siunčiamos komandų tvarkytojams apdoroti.
Komandų tvarkytojai: Komandų tvarkytojai yra atsakingi už komandų vykdymą. Paprastai jie sąveikauja su domeno modeliu, kad atnaujintų sistemos būseną.
Užklausos: Užklausos reiškia duomenų prašymus. Paprastai jos pavadinamos aprašomaisiais daiktavardžiais (pvz., `GetCustomerById`, `ListProducts`). Užklausos siunčiamos užklausų tvarkytojams apdoroti.
Užklausų tvarkytojai: Užklausų tvarkytojai yra atsakingi už duomenų gavimą. Paprastai jie sąveikauja su skaitymo modeliu, kad įvykdytų užklausą.
Komandų magistralė: Komandų magistralė yra tarpininkas, kuris nukreipia komandas atitinkamam komandų tvarkytojui.
Užklausų magistralė: Užklausų magistralė yra tarpininkas, kuris nukreipia užklausas atitinkamam užklausų tvarkytojui.
Skaitymo modelis: Skaitymo modelis yra duomenų saugykla, optimizuota skaitymo operacijoms. Tai gali būti denormalizuotas duomenų vaizdas, specialiai sukurtas užklausų našumui.
Rašymo modelis: Rašymo modelis yra domeno modelis, naudojamas sistemos būsenai atnaujinti. Paprastai jis yra normalizuotas ir optimizuotas rašymo operacijoms.
Įvykių magistralė (neprivaloma): Įvykių magistralė naudojama domeno įvykiams skelbti, kuriuos gali vartoti kitos sistemos dalys, įskaitant skaitymo modelį.

Pavyzdys: elektroninės prekybos programa

Apsvarstykime elektroninės prekybos programą. Tradicinėje architektūroje vienas `Product` objektas galėtų būti naudojamas tiek produkto informacijai rodyti, tiek produkto detalėms atnaujinti.

Įgyvendinant CQRS, atskirtume skaitymo ir rašymo modelius:

Komandų modelis:

`CreateProductCommand`: Sudėtyje yra informacija, reikalinga naujam produktui sukurti.
`UpdateProductPriceCommand`: Sudėtyje yra produkto ID ir nauja kaina.
`CreateProductCommandHandler`: Apdoroja `CreateProductCommand`, sukurdama naują `Product` agregatą rašymo modelyje.
`UpdateProductPriceCommandHandler`: Apdoroja `UpdateProductPriceCommand`, atnaujindama produkto kainą rašymo modelyje.

Užklausų modelis:

`GetProductDetailsQuery`: Sudėtyje yra produkto ID.
`ListProductsQuery`: Sudėtyje yra filtravimo ir puslapiavimo parametrai.
`GetProductDetailsQueryHandler`: Nuskaito produkto detales iš skaitymo modelio, optimizuoto rodymui.
`ListProductsQueryHandler`: Nuskaito produktų sąrašą iš skaitymo modelio, taikydama nurodytus filtrus ir puslapiavimą.

Skaitymo modelis gali būti denormalizuotas produkto duomenų vaizdas, kuriame yra tik rodymui reikalinga informacija, pvz., produkto pavadinimas, aprašymas, kaina ir vaizdai. Tai leidžia greitai gauti produkto detales, nereikalaujant sujungti kelių lentelių.

Kai įvykdoma `CreateProductCommand`, `CreateProductCommandHandler` sukuria naują `Product` agregatą rašymo modelyje. Šis agregatas tada iškelia `ProductCreatedEvent` įvykį, kuris yra paskelbiamas įvykių magistralėje. Atskiras procesas prenumeruoja šį įvykį ir atitinkamai atnaujina skaitymo modelį.

Duomenų sinchronizavimo strategijos

Norint sinchronizuoti duomenis tarp rašymo ir skaitymo modelių, galima naudoti kelias strategijas:

Įvykių šaltinio metodas: Įvykių šaltinio metodas išsaugo programos būseną kaip įvykių seką. Skaitymo modelis yra sukuriamas atkuriant šiuos įvykius. Šis metodas suteikia išsamų audito sekimą ir leidžia atkurti skaitymo modelį nuo nulio.
Asinchroninis pranešimų siuntimas: Asinchroninis pranešimų siuntimas apima įvykių skelbimą pranešimų eilėje ar tarpininkui. Skaitymo modelis prenumeruoja šiuos įvykius ir atitinkamai save atnaujina. Šis metodas užtikrina laisvą ryšį tarp rašymo ir skaitymo modelių.
Duomenų bazės replikacija: Duomenų bazės replikacija apima duomenų kopijavimą iš rašymo duomenų bazės į skaitymo duomenų bazę. Šį metodą lengviau įgyvendinti, tačiau jis gali sukelti vėlavimo ir nuoseklumo problemų.

CQRS ir įvykių šaltinio metodas

CQRS ir įvykių šaltinio metodas dažnai naudojami kartu, nes jie puikiai papildo vienas kitą. Įvykių šaltinio metodas suteikia natūralų būdą išsaugoti rašymo modelį ir generuoti įvykius skaitymo modeliui atnaujinti. Derinant CQRS ir įvykių šaltinio metodą, gaunama keletas privalumų:

Išsamus audito sekimas: Įvykių šaltinio metodas suteikia išsamų visų sistemos būsenos pakeitimų audito sekimą.
Derinimas „keliaujant laiku“: Įvykių šaltinio metodas leidžia atkurti įvykius, kad būtų galima rekonstruoti sistemos būseną bet kuriuo laiko momentu. Tai gali būti neįkainojama derinant ir audituojant.
Laikinės užklausos: Įvykių šaltinio metodas leidžia atlikti laikines užklausas, kurios leidžia gauti sistemos būseną, kokia ji buvo tam tikru laiko momentu.
Lengvas skaitymo modelio atkūrimas: Skaitymo modelį galima lengvai atkurti nuo nulio, atkuriant įvykius.

Tačiau įvykių šaltinio metodas taip pat prideda sudėtingumo sistemai. Reikalingas atidus įvykių versijavimo, schemų evoliucijos ir įvykių saugojimo svarstymas.

CQRS mikropaslaugų architektūroje

CQRS puikiai tinka mikropaslaugų architektūrai. Kiekviena mikropaslauga gali savarankiškai įgyvendinti CQRS, leidžiant optimizuoti skaitymo ir rašymo modelius kiekvienoje paslaugoje. Tai skatina laisvą ryšį, mastelio keitimą ir nepriklausomą diegimą.

Mikropaslaugų architektūroje įvykių magistralė dažnai įgyvendinama naudojant paskirstytą pranešimų eilę, tokią kaip Apache Kafka ar RabbitMQ. Tai leidžia asinchroniškai bendrauti tarp mikropaslaugų ir užtikrina, kad įvykiai būtų pristatomi patikimai.

Pavyzdys: pasaulinė elektroninės prekybos platforma

Apsvarstykite pasaulinę elektroninės prekybos platformą, sukurtą naudojant mikropaslaugas. Kiekviena mikropaslauga gali būti atsakinga už konkrečią domeno sritį, pavyzdžiui:

Produktų katalogas: Valdo produktų informaciją, įskaitant pavadinimą, aprašymą, kainą ir vaizdus.
Užsakymų valdymas: Valdo užsakymus, įskaitant kūrimą, apdorojimą ir įvykdymą.
Klientų valdymas: Valdo klientų informaciją, įskaitant profilius, adresus ir mokėjimo metodus.
Atsargų valdymas: Valdo atsargų lygius ir prieinamumą.

Kiekviena iš šių mikropaslaugų gali savarankiškai įgyvendinti CQRS. Pavyzdžiui, produktų katalogo mikropaslauga gali turėti atskirus skaitymo ir rašymo modelius produktų informacijai. Rašymo modelis gali būti normalizuota duomenų bazė, kurioje yra visi produkto atributai, o skaitymo modelis gali būti denormalizuotas vaizdas, optimizuotas produktų detalėms rodyti svetainėje.

Kai sukuriamas naujas produktas, produktų katalogo mikropaslauga paskelbia `ProductCreatedEvent` įvykį pranešimų eilėje. Užsakymų valdymo mikropaslauga prenumeruoja šį įvykį ir atnaujina savo vietinį skaitymo modelį, kad įtrauktų naują produktą į užsakymų suvestines. Panašiai, klientų valdymo mikropaslauga gali prenumeruoti `ProductCreatedEvent`, kad personalizuotų produktų rekomendacijas klientams.

CQRS iššūkiai

Nors CQRS suteikia daug naudos, jis taip pat kelia keletą iššūkių:

Padidėjęs sudėtingumas: CQRS prideda sudėtingumo sistemos architektūrai. Reikia atidaus planavimo ir projektavimo, kad būtų užtikrinta, jog skaitymo ir rašymo modeliai yra tinkamai sinchronizuojami.
Galutinis nuoseklumas: CQRS dažnai remiasi galutiniu nuoseklumu, kuris gali būti iššūkis vartotojams, tikintiems momentiniais duomenų atnaujinimais.
Duomenų sinchronizavimas: Duomenų sinchronizavimo palaikymas tarp skaitymo ir rašymo modelių gali būti sudėtingas ir reikalauja atidžiai apsvarstyti galimus duomenų nenuoseklumus.
Infrastruktūros reikalavimai: CQRS dažnai reikalauja papildomos infrastruktūros, tokios kaip pranešimų eilės ir įvykių saugyklos.
Mokymosi kreivė: Programuotojai turi išmokti naujų koncepcijų ir technikų, kad galėtų efektyviai įgyvendinti CQRS.

Geriausios CQRS praktikos

Norint sėkmingai įgyvendinti CQRS, svarbu laikytis šių geriausių praktikų:

Pradėkite paprastai: Nebandykite įdiegti CQRS visur iš karto. Pradėkite nuo mažos, izoliuotos sistemos srities ir palaipsniui plėskite jo naudojimą pagal poreikį.
Sutelkite dėmesį į verslo vertę: Pasirinkite sistemos sritis, kuriose CQRS gali suteikti didžiausią verslo vertę.
Naudokite įvykių šaltinio metodą protingai: Įvykių šaltinio metodas gali būti galingas įrankis, tačiau jis taip pat prideda sudėtingumo. Naudokite jį tik tada, kai nauda nusveria išlaidas.
Stebėkite ir matuokite: Stebėkite skaitymo ir rašymo modelių našumą ir prireikus atlikite koregavimus.
Automatizuokite duomenų sinchronizavimą: Automatizuokite duomenų sinchronizavimo procesą tarp skaitymo ir rašymo modelių, kad sumažintumėte galimus duomenų nenuoseklumus.
Bendraukite aiškiai: Aiškinai informuokite vartotojus apie galutinio nuoseklumo pasekmes.
Dokumentuokite išsamiai: Išsamiai dokumentuokite CQRS diegimą, kad kiti programuotojai galėtų jį suprasti ir prižiūrėti.

CQRS įrankiai ir karkasai

Keletas įrankių ir karkasų gali padėti supaprastinti CQRS diegimą:

MediatR (C#): Paprastas tarpininko diegimas .NET platformai, palaikantis komandas, užklausas ir įvykius.
Axon Framework (Java): Išsamus karkasas, skirtas kurti CQRS ir įvykių šaltinio metodu pagrįstas programas.
Broadway (PHP): CQRS ir įvykių šaltinio metodo biblioteka PHP kalbai.
EventStoreDB: Specialiai sukurta duomenų bazė įvykių šaltinio metodui.
Apache Kafka: Paskirstyta srautinio duomenų perdavimo platforma, kuri gali būti naudojama kaip įvykių magistralė.
RabbitMQ: Pranešimų tarpininkas, kuris gali būti naudojamas asinchroniniam ryšiui tarp mikropaslaugų.

Realūs CQRS pavyzdžiai

Daugelis didelių organizacijų naudoja CQRS kurdamos mastelio keitimui pritaikytas ir prižiūrimas sistemas. Štai keli pavyzdžiai:

Netflix: Netflix plačiai naudoja CQRS, kad valdytų savo didžiulį filmų ir TV laidų katalogą.
Amazon: Amazon naudoja CQRS savo elektroninės prekybos platformoje, kad apdorotų didelius transakcijų kiekius ir sudėtingą verslo logiką.
LinkedIn: LinkedIn naudoja CQRS savo socialinio tinklo platformoje, kad valdytų vartotojų profilius ir ryšius.
Microsoft: Microsoft naudoja CQRS savo debesijos paslaugose, tokiose kaip Azure ir Office 365.

Šie pavyzdžiai rodo, kad CQRS gali būti sėkmingai taikomas įvairiose srityse, nuo elektroninės prekybos platformų iki socialinių tinklų svetainių.

Išvada

CQRS yra galingas architektūrinis šablonas, kuris gali žymiai pagerinti sudėtingų sistemų mastelio keitimą, prižiūrimumą ir našumą. Atskirdamas skaitymo ir rašymo operacijas į skirtingus modelius, CQRS leidžia nepriklausomai optimizuoti ir keisti mastelį. Nors CQRS prideda papildomo sudėtingumo, daugeliu atvejų nauda gali nusverti išlaidas. Suprasdami CQRS principus, naudą ir iššūkius, programuotojai gali priimti pagrįstus sprendimus, kada ir kaip taikyti šį šabloną savo projektuose.

Nesvarbu, ar kuriate mikropaslaugų architektūrą, sudėtingą domeno modelį, ar didelio našumo programą, CQRS gali būti vertingas įrankis jūsų architektūriniame arsenale. Priimdami CQRS ir su juo susijusius šablonus, galite kurti sistemas, kurios yra geriau pritaikytos mastelio keitimui, lengviau prižiūrimos ir atsparesnės pokyčiams.

Tolimesniam mokymuisi

Martino Fowlerio straipsnis apie CQRS: https://martinfowler.com/bliki/CQRS.html
Grego Youngo CQRS dokumentai: Juos galima rasti ieškant „Greg Young CQRS“.
Microsoft dokumentacija: Ieškokite CQRS ir mikropaslaugų architektūros gairių Microsoft Docs svetainėje.

Šis CQRS tyrimas suteikia tvirtą pagrindą suprasti ir įgyvendinti šį galingą architektūrinį šabloną. Nepamirškite atsižvelgti į specifinius savo projekto poreikius ir kontekstą, kai sprendžiate, ar priimti CQRS. Sėkmės jūsų architektūrinėje kelionėje!