Kako premostiti izvanredne sustave i poticaje događaja (i pobijediti gorile)

Imate sjajan novi CQRS sustav, „kompletan je dev“, a vi ćete započeti testiranje integracije. A gorila od 800 kilograma koja je spavala u kutu za vrijeme rasprava o vašoj domeni budi se.

Bez ijednog pogleda na sveobuhvatne dijagrame domena, uključivanje korisničkih priča, UI obrazaca ili dobro dokumentirani kriterij prihvaćanja, probija se kroz „kontekstnu granicu“ isprekidane linije koja ga je trebala zadržati.

Gorile divljaju oko građevina koje razbijaju zgrade, smanjujući vrijednost ruševina, iskorjenjujući agregate i općenito uništavajući sav konsenzus o projektu. Gorilla, tvoje ime je Legacy Integration.

Bok ljudi! Jedva čekam da vidim kako se vaša RESTful mikro-usluga integrira s ovim tridesetogodišnjakom koji je u skladu s ERP sustavom! Nadam se da vam se sviđa COBOL. (Slika ljubaznosti makaka „Naruto“, koja nije gorila).

Naslijeđeni sustavi i integracija procesa mogu potopiti inače savršeno izveden projekt. To je čudovišna migrena problema koji se uči samo u školi tvrdih udaraca. Također je problem s kojim ćete se kao programer suočiti u svojoj karijeri (ako već niste) kada počnete raditi s dovoljno uspostavljenim tvrtkama i domenama.

Naravno, ako budete imali sreće, još niste započeli s kodiranjem - ili je bar još u toku procesa - kada se gorila probudi. Ili, ako ste pametni, vidite gorilu kako se skriva ispod sjenila u kutu i trljajući ožiljke svog posljednjeg susreta, otkrijete njegovo neizbježno divljanje ugrađujući ga u svoju arhitekturu od samog početka.

Suočavanje sa naslijeđenim sustavima

Kao pomoćnik direktora arhitekture u UCLA Uredu za istraživačke informacijske sustave odgovoran sam za premošćivanje mnogih nedostataka u sustavu i podacima. UCLA ima desetljećima niz naslijeđenih poslovnih procesa i sustava oko istraživanja koji se suprotstavljaju bilo kakvom pokušaju „narušavanja“ ovih tradicionalnih pristupa novom tehnologijom.

Najviše zastrašujući, ovaj cjevovod je zatrpan povremenim neprobojnim ledenim brijegom naslijeđenih podataka koji često zahtijevaju neslaganje u stvarnom vremenu.

Oh dobri gospodaru! Data-berg! Ne čekaj, ovo je samo fatberg. Drago mi je što sam se odlučio za karijeru u šifri umjesto sanitarije. (Kreditna slika: Associated Press)

U mom uredu imali smo zadatak pružiti integraciju u te naslijeđene sustave sve bržim tempom. Također smo u porastu naših transakcijskih sustava za rješavanje malih poslovnih procesa.

Za vlastite sustave uglavnom slijedimo obrazac mikro usluga. Uključujemo više složenosti, kao što su dizajn temeljen na domeni (DDD) i pronalaženje događaja, ako je potrebno. Naš ključni izazov za ove sustave je naslijeđena integracija u sustave postojanja države.

Približava se integraciji

Opisat ću naš pristup u sljedećih nekoliko odlomaka. Na ovaj način smo riješili jedan od problema koji proizlaze iz premošćivanja iz sustava događaja, posebno hibridnog sustava događaja, i onog koji je isključivo vođen državama.

Jedan ključni princip koji implementator često propusti je da se izvori događaja ne smiju koristiti svugdje. To je prema Gregu Youngu, za koga se uvelike zaslužuje uvođenje uzorka softverske arhitekture „izvor događaja“.

U našim sustavima koristimo izvor događaja kako bismo ispunili posebno ciljane zahtjeve. Ponekad to rezultira u tome da naše aplikacije imaju stanje koje može biti izvan toka događaja. Uz to, neki od naših pokretača događaja dolaze iz nepouzdanih promjena stanja izvornog sustava. To će zahtijevati mnogo naknadnih korekcija događaja i „premotavanja unatrag-ponoviti“ da se isprave ako bismo ovisili samo o streamu događaja.

Skeptično rješenje

Rješenje koje smo za to smislili jest jedno koje zovem "Skeptični pretplatnik". Skeptični pretplatnik rješava problem "nepouzdanosti" na strani sustava, barem iz perspektive naslijeđenog državnog stroja. Također se obraća sustavima koji mogu propustiti generiranje događaja zbog problema s vanjskim naslijeđenim podacima:

  1. Izvor događaja može generirati događaje koji ne rezultiraju promjenama stanja relevantnim za naslijeđeni državni stroj. Iz njegove perspektive, to su "lažno pozitivni" događaji
  2. Izvor događaja možda neće uspjeti generirati događaje za promjene stanja koje su relevantne za naslijeđeni državni stroj. Iz perspektive, to su događaji koji su „propušteni“ ili „preskočeni“
  3. Događaji se uopće ne mogu generirati zbog grešaka ili pogrešaka u izvornom izvoru događaja. To se posebno događa u tokovima ekstra-tranformnog opterećenja (ETL) iz naslijeđenih spremišta podataka. Iz bilo koje perspektive ovo su istinski "preskočeni" događaji

Skeptični pristup pretplatnika rješava ove probleme ostajući nepovjerljiv u tok događaja. Tok događaja tretira kao jedan mogući okidač ili obavijest da se stanje promijenilo, ali prihvaća i druge moguće okidače. Također vjeruje da su obavijesti o promjeni stanja točne.

Nakon što se obavijesti da se stanje možda promijenilo, pretplatnik obavještava gateway stanje koji pita stanje sustava temeljenog na događajima.

Ovaj mrežni prolaz procjenjuje stanje prema posljednjem poznatom stanju (kao što je sustav pretplata znao).

Ako je promjena relevantna, tada se ažurira stanje sustava pretplata i po potrebi pokreće povezani poslovni procesi pretplatničkog sustava.

Dame i germke, skeptični pretplatnik!

Neki zahtjevi

Kako bi se koristio ovaj pristup, vaš sustav pretplate mora:

  1. Već uporno postoji ili bi mogla proizaći iz onoga što postoji, državne atribute do kojih je stalo iz sustava za prikupljanje događaja
  2. Omogućuje vam da ponovite postupak ubrizgavanja podataka o promjenama stanja

Vaš sustav pretraživanja događaja treba:

  1. Nabavite uslugu upita koja pouzdano predstavlja stanje sustava i uključuje sve atribute stanja koje zahtijeva sustav pretplata
  2. Navedite dovoljno podataka u streamu događaja da biste pronašli odgovarajuće zapise u službi upita
  3. Podržite "popis" ili drugi skupni upit iz usluge upita

Skeptični pretplatnik kojeg implementirate mora sadržavati:

  1. State Gateway koji može zatražiti uslugu upita za određeni zapis (događaj vođen) ili za popis zapisa (drugi okidač, za nadoknadu "propuštenih" događaja)
  2. Državni Gateway mora sadržavati logiku usporedbe domena iz konteksta sustava pretplate koji odbacuje zapise ako se, što se tiče pretplatničke domene, nisu promijenile
  3. Implementacija pretplate na događaj za pozivanje pristupnika po zapisu iz događaja
  4. Mogućnost ažuriranja postojanog sloja pretplatničkog sustava s promjenama (tako da sljedeći put ne ponovno ažurira isti zapis), kao što je putem spremišta

Skeptični pretplatnik također može implementirati pokretanje poslovnih procesa u sustavu pretplate.

Ako je to isključivo država, to bi moglo biti ustrajavanjem novih zapisa procesa za pokretanje popratnih procesa. U suprotnom, može pozvati bez obzira na to je li izložen API procesa.

Ako pokrenete ove poslovne procese, također morate implementirati zaključavanje u gatewayu kako ne biste udvostručili pokretanje procesa ako se aktivira događaj tijekom ETL procesa.

Pozitivni rezultati

Postoji mnoštvo drugih izazova povezanih s integracijom naslijeđenih sustava, posebno kada se kreće između konteksta temeljenih na događajima i stanja. Ovaj obrazac, međutim, pomaže nam da umanjimo tehnički teret povezan s održavanjem događaja pri konzumiranju naslijeđenih (i mrljastih) podataka.

Prije nego što slijedimo ovaj obrazac, radili smo u strogo pristupanom pristupu. Izgubili smo brzi pristup mogućnostima podrške koji su nam se pružali izravnim uređivanjem države. Pomoću ovog obrasca povratili smo te mogućnosti. Kad se naslijeđeni sustav loše ponaša jer ne "voli" događaje koji se događaju, prebacili smo teret s modificiranja toka događaja na neki način na jednostavnu promjenu stanja.

Dodali smo i sloj labave spojnice da generalno izoliramo sustav pretplatu od izravnog izlaganja događajima. To omogućava preusmjeravanje ostalih okidača sustava pretplata.

Na primjer, naslijeđeni ETL može poslužiti kao polazni prekidač gateway stanja dok se ne budete spremni prebaciti na tok događaja. I to smo učinili bez previše kompliciranja CQRS usluge primjenom međuprostornog skeptičnog pretplatnika kao neovisnog entiteta.

Evo savjeta za znanstvenike s podacima i inženjere koji im služe: ako implementirate postojanost poliglota u pretplatničko skladište, također možete izgraditi spremište dokumenata koje je već automatski filtrirano u promjene podataka koje odražavaju smislen poslovni proces.

Konačno, u slučaju da se neki događaj "preskoči" ili "propusti", slijedit ćemo jednostavan put podrške na zahtjev. Ili ponovno obavještavamo pretplatnika o tom zapisu (ako smo svjesni u kojem je zapisu propušten događaj) ili vršimo „nadoknadu” cijeli sustav (ako nismo sigurni).

To možemo učiniti bez da dodirujemo struju događaja. To znači da aktivnost podrške neće utjecati na druge aplikacije za pretplatu.

Završne misli

To nije odgovarajuće rješenje za svaki problem (ili čak za većinu problema). No, to je sjajno rješenje za iskorištavanje labave spojke i ostalih prednosti daljnjeg prikazivanja događaja i CQRS, uz minimiziranje režijskih troškova za rješavanje problema protoka podataka koji su naslijeđeni. To omogućuje našim programerima da troše više vremena na pisanje novih aplikacija i povećavaju vrijednost za naše potrošače.

Ako vam se svidio ovaj post, kliknite gumb ispod i dajte mi nekoliko pljeskova kako bi ga više ljudi vidjelo. Hvala!

Jonathan je pomoćnik direktora za arhitekturu i poslovanje na UCLA-ovom odjelu za istraživačke informacijske sustave. Nakon sticanja diplome fizike na Sveučilištu Stanford nastavio je provesti više od 10 godina radeći u arhitekturi informacijskih sustava, poboljšanju podataka u poslovnim procesima i upravljanju organizacijama. Osnivač je i Peach Pie Apps Workshop, tvrtke koja se fokusira na izgradnju podatkovnih rješenja za neprofitne svrhe.