Kuidas ühendada riiklikke ja sündmustepõhiseid süsteeme (ja gorilla peksmine)

Teil on uus läikiv CQRS-süsteem, see on „valmis” ja hakkate integreerimise testimist. Ja ärkab üles see 800-naeline gorilla, mis teie domeeniarutelude ajal nurgas magas.

Ilma ühegi pilguta oma põhjalikele domeenidiagrammidele, kaasahaaravatele kasutajalugudele, kasutajaliidese maketidele või hästi dokumenteeritud vastuvõtmiskriteeriumidele puruneb see punktiirjoonega “kontekstipiirist”, mis pidi seda tagasi hoidma.

Gorilla märatseb ümber hoone purustavate üksuste, vähendades killustiku väärtust, viies täitematerjale üles ja hävitades üldiselt kogu projekti osas konsensuse. Gorilla, su nimi on Legacy Integration.

Kuule poisid! Ma ei jõua ära oodata, millal su RESTful mikroteenuse rakendus integreerub selle kolmekümneaastase ERP-süsteemiga! Loodan, et teile meeldib COBOL. (Pilt viisakalt „Naruto“ makaakist, kes pole gorilla).

Pärandsüsteemid ja protsesside integreerimine võivad vaevata muidu täiuslikult teostatud projekti. See on probleemi koletislik migreen, mida õpetatakse ainult raskete koputuste koolis. See on ka probleem, millega arendajana silmitsi seistes oma karjääris (kui te seda veel teinud ei ole) alustades koostööd piisavalt väljakujunenud ettevõtete ja domeenidega.

Muidugi, kui teil veab, pole te tegelikult veel kodeerimist alustanud - või vähemalt on see alles protsessi alguses - kui gorilla ärkab. Või kui sa oled nutikas, näed gorillat lambivarju all nurgas peidus ja hõõrudes oma viimase kohtumise arme, näed ette selle vältimatut märatsemist, integreerides selle oma arhitektuuri kohe alguses.

Tegelemine pärandsüsteemidega

UCLA teadusuuringute infosüsteemide büroo arhitektuuri abidirektorina vastutan paljude süsteemi- ja andmelünkade ületamise eest. UCLA-l on aastakümnete pikkune teadusuuringute ümber käimasolevate äriprotsesside ja süsteemide kogum, mis toetab igasuguseid katseid neid traditsioonilisi lähenemisviise uue tehnoloogiaga "häirida".

Kõige hirmutavamalt on see torujuhe ühendatud aeg-ajalt läbitungimatute pärandiandmete jäämäega, mis nõuab sageli reaalajas käperdamist.

Oh hea isand! Data-berg! Ei oodata, see on lihtsalt rasvake. Mul on hea meel, et otsustasin sanitaartehnika asemel karjääri teha koodiga. (Pildikrediit: Associated Press)

Minu kabinetis on meile tehtud ülesandeks integreerida need pärandsüsteemid üha kiiremini. Samuti suurendame oma kohandatud tehingusüsteeme väikeste äriprotsesside käsitlemiseks.

Oma süsteemide puhul järgime üldiselt mikroteenuste mustrit. Kaasame vajadusel keerulisemaid lahendusi, näiteks domeenipõhise disaini (DDD) ja sündmuste hankimise. Meie peamine väljakutse nende süsteemide jaoks on pärandi integreerimine riigi püsivussüsteemidesse.

Integratsiooni lähenemine

Järgnevates lõikudes kirjeldan meie lähenemisviisi. Nii oleme lahendanud ühe probleemist, mis tuleneb sündmustesüsteemi, eriti hübriidsete sündmuste süsteemi ühendamisest puhtalt riigi juhitud süsteemiga.

Üks võtmepõhimõte, millest rakendajad sageli ilma jäävad, on see, et sündmuste hankimist ei tohiks kõikjal kasutada. See on Greg Youngi sõnul, keda tunnustatakse tarkvara sündmuste hankimise tarkvara arhitektuurimudeli tutvustamise eest laialdaselt.

Oma süsteemides kasutame sündmuste hankimist konkreetsetele nõuetele vastamiseks. Mõnikord põhjustab see meie rakenduste olekut, mis võib asuda väljaspool sündmusevoogu. Lisaks pärinevad mõned meie sündmuste päästikud ebausaldusväärsetest allikasüsteemi oleku muutustest. See nõuaks palju post-hoc sündmuste korrigeerimist ja “tagasikerimine-kordus” parandamist, kui me peaksime sõltuma ainult sündmuste voost.

Skeptiline lahendus

Lahendus, mille me selle jaoks välja pakkusime, on üks, mida ma nimetan “Skeptiline abonent”. Skeptiline abonent tegeleb süsteemi ebausaldusväärsuse probleemiga vähemalt pärandseisundi masina seisukohast. Samuti on see suunatud süsteemidele, mis võivad välise pärandandmeprobleemide tõttu sündmuste genereerimisest ilma jääda:

  1. Sündmuseallikas võib genereerida sündmusi, mis ei põhjusta pärandseisundimasinaga seotud olekumuutusi. Tema vaatenurgast on need “valepositiivsed” sündmused
  2. Sündmuseallikas ei pruugi genereerida pärandseisundimasinaga seotud oleku muutuste sündmusi. Tema vaatevinklist on need sündmused, mis on mööda lastud või vahele jäetud
  3. Sündmusi ei pruugita üldse genereerida sündmuse algse allika vigade või vigade tõttu. Eriti juhtub see päringute andmehoidlatest väljavõtete-teisenduste koormuste (ETL) voogude puhul. Mis tahes vaatevinklist on need tõeliselt vahele jäetud sündmused

Skeptiline tellija lähenemisviis lahendab need probleemid, jäädes umbusalduseks sündmuste voo suhtes. Ta käsitleb sündmustevoogu ühe võimaliku päästikuna või teatisena, et olek on muutunud, kuid aktsepteerib ka muid võimalikke päästikuid. Samuti ei usu ta, et oleku muutumisest teatamine oleks õige.

Kui on teatatud, et olek võib olla muutunud, teatab abonent olekuväravale, mis küsib sündmusepõhise süsteemi olekust.

See olekuvärav hindab olekut viimase teadaoleva oleku suhtes (nagu telliv süsteem seda teadis).

Kui muudatus on asjakohane, värskendab see seejärel tellimissüsteemi olekut ja vajadusel algatab seotud tellimissüsteemi äriprotsessid.

Daamid ja mikroobe, skeptiline tellija!

Mõned nõuded

Selle lähenemisviisi kasutamiseks peab teie tellimissüsteem:

  1. Juba püsib või suudab tuletada sellest, millest see püsib, atribuut, mille eest ta hoolib, sündmuste hankimise süsteemist
  2. Laske teil uuesti teha, kuidas sisestate oleku muutuste andmeid

Teie sündmuste hankimise süsteem peab:

  1. Pakkuge päringuteenust, mis esindab usaldusväärselt süsteemi olekut ja sisaldab kõiki tellivas süsteemis nõutavaid olekuatribuute
  2. Esitage sündmustevoo kohta piisavalt andmeid päringuteenuse asjakohaste kirjete leidmiseks
  3. Toetage päringuteenuse loendit või muud pakkide päringut

Teie rakendatav skeptiline abonent peab sisaldama:

  1. Riigi värav, mis saab päringu teenuselt päringuid teha konkreetse kirje (sündmusepõhise) või kirjete loendi (muu päästik, vastamata sündmuste järelejõudmiseks) jaoks
  2. Riigi värav peab sisaldama domeenide võrdlemise loogikat tellimissüsteemi kontekstist, mis loobub kirjetest, kui tellitava domeeni osas pole need muutunud
  3. Sündmuse tellimise juurutamine, et helistada lüüsi sündmuste kogurekordile
  4. Võimalus tellitud süsteemi püsikihti värskendada muudatustega (nii et see ei värskenda sama kirjet järgmisel korral uuesti), näiteks hoidla kaudu

Skeptiline tellija võib abonendisüsteemis rakendada ka äriprotsesside käivitamist.

Kui see on puhtalt riigipõhine, võib see toimuda samaaegsete protsesside käivitamiseks uute püsiprotsesside kirjete abil. Vastasel juhul võib see helistada mis tahes protsessi API-le, mis on avatud.

Kui alustate neid äriprotsesse, peate ka lüüsi lukustama, nii et te ei kahekordista protsessi käivitamisel, kui ETL-protsessi ajal toimub sündmuse päästik.

Positiivsed tulemused

Pärandsüsteemide integreerimisega on seotud palju muid väljakutseid, eriti kui liikuda sündmustepõhise ja riikliku konteksti vahel. See muster aitab meil aga pärand- (ja täpsete) andmete tarbimisel minimeerida sündmuste hooldusega seotud tehnilist koormust.

Enne selle mustri järgimist töötasime rangelt sündmusest lähtuva lähenemisviisi järgi. Olime kaotanud kiire juurdepääsu tugiteenuste võimalustele, mida pakub otse redigeeritav olek. Selle mustriga oleme need võimalused taastanud. Kui pärandsüsteem käitub valesti, kuna talle ei meeldi sündmused, mida see saab, siis oleme sündmusevoo mingil viisil muutmise koormuse nihutanud lihtsale oleku muutmisele.

Lisasime ka lahtise siduri kihi, et isoleeriks tellimissüsteem üldiselt sündmuste otsese kokkupuute eest. See võimaldab teiste tellimissüsteemi päästikute ümbersuunamist.

Näiteks võib pärsitud ETL toimida esialgse oleku lüüsi päästikuna, kuni olete valmis üle minema sündmusevoogu. Ja me oleme teinud seda ilma, et oleksime CQRS-teenust liiga keeruliseks muutnud, rakendades vahereklaamilise abonendi iseseisva üksusena.

Siin on nõuanne andmeteadlastele ja neid teenindavatele inseneridele: kui rakendate tellivas repositooriumis polügloti püsivuse, saate üles ehitada ka dokumendipoe, mis filtreeritakse juba automaatselt andmemuutustele, mis kajastavad asjakohast äriprotsessi.

Lõpuks, kui sündmus jäetakse vahele või vahele, on meil lihtne tellitavat tugiteenust järgida. Kas teatame abonendile sellest rekordist uuesti (kui oleme teadlikud, millisest salvestisest sündmus jäi puudu) või teostame järelejõudmise täissüsteemi päringu (kui me pole selles kindlad).

Saame seda teha ilma, et peaksime sündmusevoogu puudutama. See tähendab, et tugiteenused ei mõjuta teisi tellivaid rakendusi.

Lõplikud mõtted

See ei sobi iga probleemi jaoks (või isegi enamiku probleemide jaoks). Kuid see on suurepärane lahendus sündmuste hankimise ja CQRS-i lahtise sidumise ja muude allavoolu eeliste ärakasutamiseks, minimeerides samal ajal pärandlike andmevoogude tõrkeotsingu toetamise üldkulusid. See võimaldab meie arendajatel kulutada rohkem aega uute rakenduste kirjutamisele ja suurendab meie väärtust meie tarbijate jaoks.

Kui teile see postitus meeldis, klõpsake alloleval nupul ja andke mulle mõned plaksutused, et rohkem inimesi seda näeks. Aitäh!

Jonathan on UCLA teadusuuringute infosüsteemide osakonna arhitektuuri ja operatsioonide abidirektor. Pärast füüsika kraadi omandamist Stanfordi ülikoolis töötas ta üle 10 aasta infosüsteemide arhitektuuri, andmepõhise äriprotsesside parendamise ja organisatsiooni juhtimise alal. Ta on ka ettevõtte Peach Pie Apps Workshop asutaja, mis keskendub mittetulunduslikele andmelahenduste ehitamisele.