Kuinka yhdistää tilallisia ja tapahtumista lähteviä järjestelmiä (ja lyödä gorillaa)

Sinulla on uusi kiiltävä CQRS-järjestelmä, se on ”valmis”, ja olet aloittamassa integraatiotestausta. Ja 800-punnan gorilla, joka nukkui nurkassa verkkotunnuskeskustelujesi aikana, herää.

Ilman yhdellä silmäyksellä kattavista verkkotunnuskaavioistasi, kiinnostavista käyttäjäkerroista, käyttöliittymän malleista tai hyvin dokumentoiduista hyväksymiskriteereistä, se räjähtää katkoviivan ”kontekstirajan” läpi, jonka piti pidättää sitä.

Gorilla räjähtää rakennuksen ympärillä murskaavia kokonaisuuksia, vähentäen arvoa raunioiksi, juurten kiviaineksia ja tuhoaa yleensä kaiken konsensuksen projektista. Gorilla, sinun nimesi on Legacy Integration.

Hei kaverit! En voi odottaa nähdäksesi kuinka RESTful-mikropalvelusovelluksesi integroituu tähän 30-vuotiaan räätälöityyn ERP-järjestelmään! Toivottavasti pidät COBOLista. (Kuva kohteliaisuus

Vanhat järjestelmät ja prosessien integrointi voivat upottaa muuten täydellisesti toteutetun projektin. Se on hirviömäinen migreeni ongelmasta, jota opetetaan vain kovien iskujen koulussa. On myös ongelma, jonka joudut kehittäjänä kohtaamaan urallasi (jos et vielä ole), kun aloitat työskennellä riittävän vakiintuneiden yritysten ja verkkotunnusten kanssa.

Tietenkin, jos sinulla on onni, et ole vielä aloittanut koodausta - tai ainakin se on vielä prosessin varhaisessa vaiheessa - kun gorilla herää. Tai jos olet fiksu, näet gorillan piiloutuvan nurkassa lampunvarjostimen alle ja hankaamalla viimeisen kohtaamasi arpia, ennustat sen väistämätöntä raivoa sisällyttämällä se arkkitehtuuriinsi heti alusta alkaen.

Vanhojen järjestelmien käsittely

UCLA: n tutkimuksen tietojärjestelmien toimiston arkkitehtuurin apulaisjohtajana olen vastuussa monien järjestelmä- ja tietopuutteiden korjaamisesta. UCLA: lla on vuosikymmenten mittainen vanhojen liiketoimintaprosessien ja järjestelmien tutkimus, joka tukee kaikkia yrityksiä "häiritä" nämä perinteiset lähestymistavat uudella tekniikalla.

Pelottavaa, että tämä putkilinja on kytketty vanhanaikaisen datan satunnaisesti läpäisemättömään jäävuoreen, joka vaatii usein reaaliaikaista ryöstämistä.

Voi hyvä herra! Data-berg! Ei odota, tämä on vain fatberg. Olen iloinen, että olen valinnut koodin uran sanitaation sijaan. (Kuvaluotto: Associated Press)

Toimistossani meille on annettu tehtäväksi integroida nämä vanhat järjestelmät yhä nopeammin. Olemme myös nostamassa räätälöityjä transaktiojärjestelmiämme käsittelemään pieniä liiketoimintaprosesseja.

Omassa järjestelmässämme noudatamme yleensä mikropalvelumallia. Yhdistämme tarvittaessa entistä monimutkaisempia, kuten toimialuevetoista suunnittelua (DDD) ja tapahtumien hankintaa. Keskeinen haaste näille järjestelmille on vanha integraatio valtion pysyvyysjärjestelmiin.

Lähestymisessä integraatio

Aion hahmotella lähestymistapaamme seuraavissa muutamissa kappaleissa. Näin olemme ratkaisseet yhteen ongelmista, joita syntyy silloittamalla tapahtumajärjestelmä, erityisesti hybridi-tapahtumajärjestelmä, puhtaasti valtion johtamaan järjestelmään.

Yksi keskeinen periaate, jonka toteuttajat usein kaipaavat, on, että tapahtumien hankintaa ei tule käyttää kaikkialla. Tämä on Greg Youngin mukaan, jolle on annettu laaja tunnustus esittelemällä ”tapahtumien hankinta” -ohjelmistoarkkitehtuurimalli.

Järjestelmissämme käytämme tapahtumien hankintaa vastaamaan erityisesti kohdennettuja vaatimuksia. Joskus tämä johtaa siihen, että sovelluksissamme on tila, joka voi sijaita tapahtumavirran ulkopuolella. Lisäksi jotkut tapahtumalaukaisijoista tulevat epäluotettavista lähdejärjestelmän tilan muutoksista. Tämä vaatisi paljon post-hoc-tapahtumakorjausta ja ”kelaus taaksepäin” korjaamiseksi, jos olisimme riippuvaisia ​​vain tapahtumavirrasta.

Skeptinen ratkaisu

Ratkaisu, jonka keksimme tälle, on yksi, jota kutsun ”Skeptiseksi tilaajaksi”. Skeptinen tilaaja käsittelee ”epäluotettavuuden” ongelmaa järjestelmän tapahtumapuolella ainakin perintötilan koneen näkökulmasta. Se koskee myös järjestelmiä, jotka saattavat ohittaa tapahtumien luomisen ulkoisten vanhojen tietoongelmien vuoksi:

  1. Tapahtumalähde voi tuottaa tapahtumia, jotka eivät johda vanhojen tilakoneiden kannalta oleviin tilamuutoksiin. Sen näkökulmasta katsottuna nämä ovat ”vääriä positiivisia” tapahtumia
  2. Tapahtumalähde ei ehkä pysty generoimaan tapahtumia tilan muutoksille, jotka ovat merkityksellisiä vanhassa tilakoneessa. Sen näkökulmasta nämä ovat ”ohitetut” tai “ohitetut” tapahtumat
  3. Tapahtumia ei välttämättä luoda ollenkaan virheiden tai virheiden takia tapahtuman alkuperäisessä lähteessä. Tämä tapahtuu etenkin uutteen-muunnoskuorman (ETL) virroissa vanhoista tietovarastoista. Mistä tahansa näkökulmasta nämä ovat aidosti ohitetut tapahtumat

Skeptinen tilaaja -lähestymistapa vastaa näihin huolenaiheisiin pitämällä epäluotettavana tapahtumavirrasta. Se käsittelee tapahtumavirtaa yhtenä mahdollisena liipaisimena tai ilmoituksena siitä, että tila on muuttunut, mutta se hyväksyy myös muut mahdolliset liipaisimet. Se epäilee myös, että valtionmuutosta koskevat ilmoitukset ovat oikein.

Saatuaan ilmoituksen siitä, että tila on muuttunut, tilaaja ilmoittaa tilayhdyskäytävälle, joka kysyy tapahtumasta peräisin olevan järjestelmän tilasta.

Tämä tilayhdyskäytävä arvioi tilaa viimeksi tunnetusta tilasta (kuten tilaajajärjestelmä tiesi sen).

Jos muutos on merkityksellinen, se päivittää tilaamisen järjestelmän tilan ja aloittaa tarvittaessa liittyvät tilaamisen järjestelmän liiketoimintaprosessit.

Hyvät naiset ja bakteerit, skeptinen tilaaja!

Jotkut vaatimukset

Tätä lähestymistapaa käyttääksesi tilaamalla järjestelmän on:

  1. Valtio määrittelee sen jo huolehtivansa tapahtumien hankintajärjestelmästä tai pystyy jo päättämään siitä mitä se jatkuu.
  2. Antaa sinun tehdä uudelleen, kuinka pistät tilamuutostietoja

Tapahtumahankintajärjestelmän täytyy:

  1. Toimita kyselypalvelu, joka edustaa luotettavasti järjestelmän tilaa ja sisältää kaikki tilaamisjärjestelmän edellyttämät tilaattribuutit
  2. Syötä tapahtumavirrassa riittävästi tietoja asiaankuuluvien tietueiden löytämiseksi kyselypalvelussa
  3. Tue “luettelo” tai muu eräkysely kyselypalvelusta

Toteuttamasi skeptisen tilaajan tulee sisältää:

  1. Tilayhdyskäytävä, joka voi hakea kyselypalvelua tietyltä tietueelta (tapahtumapohjainen) tai tietuelista (muu liipaisin, jäljettömien tapahtumien seuraamiseksi)
  2. State Gatewayn on sisällytettävä verkkotunnusten vertailulogiikka tilaajajärjestelmän kontekstista, joka hylkää tietueet, elleivät tilaamisen toimialueen osalta ole muuttuneet
  3. Tapahtumitilauksen toteutus yhdyskäytävän kutsumiseksi tapahtumien per tietue
  4. Mahdollisuus päivittää tilaamisen järjestelmän pysyvyyskerros muutoksilla (jotta se ei päivitä samaa tietuetta seuraavan kerran), esimerkiksi arkiston kautta

Skeptinen tilaaja voi myös toteuttaa liiketoimintaprosessien aloittamisen tilaajajärjestelmässä.

Jos se on puhtaasti valtion ohjaama, tämä voi tapahtua pysyvien uusien prosessitietueiden avulla samanaikaisten prosessien käynnistämiseksi. Muutoin se voi kutsua mitä tahansa prosessin API-altistusta.

Jos aloitat nämä liiketoimintaprosessit, sinun on myös toteutettava lukitus yhdyskäytävässä, jotta et kaksinkertaistuisi prosessin aloittamisen yhteydessä, jos tapahtumalaukaisija tapahtuu ETL-prosessin aikana.

Positiiviset tulokset

Vanhojen järjestelmien integrointiin liittyy paljon muita haasteita, etenkin kun siirrytään tapahtumasta peräisin olevan ja tilallisen tilanteen välillä. Tämä malli auttaa meitä kuitenkin minimoimaan tapahtumien ylläpitoon liittyvän teknisen taakan kuluttaessamme vanhaa (ja täplikäs) tietoa.

Ennen tämän mallin noudattamista olimme työskennelleet tiukasti tapahtumaperusteisessa lähestymistavassa. Olimme menettäneet nopean pääsyn tukimahdollisuuksiin, joita tarjosi suora muokattava tila. Tämän mallin avulla olemme palauttaneet nämä mahdollisuudet. Kun vanha järjestelmä toimii huonosti, koska se ei pidä saamistaan ​​tapahtumista ”, olemme siirtäneet taakan tapahtumavirran modifioinnista jollain tavalla yksinkertaiseen tilanmuokkaamiseen.

Olemme lisänneet myös kerroksen löysästä kytkimestä, jotta tilausjärjestelmä yleensä eristettäisiin tapahtumien välittömältä altistumiselta. Tämä mahdollistaa muiden tilaamisen järjestelmän liipaisimien ohjaamisen uudelleen.

Esimerkiksi vanha ETL voi toimia alkuperäisen tilan yhdyskäytäväliipaisimena, kunnes olet valmis vaihtamaan tapahtumavirtaan. Ja olemme tehneet niin ilman, että mutkistamme CQRS-palvelua liiaksi ottamalla käyttöön skeptinen interstitiaalinen tilaaja itsenäisenä kokonaisuutena.

Tässä on ammattilaisten kärki tietojen tutkijoille ja heitä palveleville insinööreille: jos toteutat polyglot-pysyvyyden tilaamisessa varastossa, voit myös rakentaa asiakirjavaraston, joka suodatetaan jo automaattisesti tiedonmuutoksiin, jotka heijastavat merkityksellistä liiketoimintaprosessia.

Viimeinkin siinä tapauksessa, että tapahtuma ”ohitetaan” tai “ohitetaan”, meillä on helppo seurata tilauksen mukaista tukipolkua. Joko ilmoitamme tilaajalle uudestaan ​​kyseisestä tietueesta (jos tiedämme, mikä tietue ohitti tapahtuman), tai suoritamme "catch-up" -järjestelmän koko järjestelmäkyselyn (jos emme ole varmoja).

Voimme tehdä tämän tarvitsematta koskettaa tapahtumavirtaa. Tämä tarkoittaa, että tukitoiminta ei vaikuta muihin tilaamiin sovelluksiin.

Lopulliset ajatukset

Se ei ole oikein sopiva jokaiseen ongelmaan (tai edes useimpiin ongelmiin). Mutta se on loistava ratkaisu hyödyntääksesi tapahtumien hankinnan ja CQRS: n löysää kytkentää ja muita loppupään etuja hyödyntäen samalla minimoimalla vanhojen tietovirtojen vianetsinnän tuki. Tämä antaa kehittäjillemme viettää enemmän aikansa kirjoittamalla uusia sovelluksia ja lisää arvoamme kuluttajillemme.

Jos pidit tästä viestistä, napsauta alla olevaa painiketta ja anna minulle joitain claps, jotta useammat ihmiset näkevät sen. Kiitos!

Jonathan on UCLA: n tutkimuksen tietojärjestelmien osaston arkkitehtuurin ja toiminnan apulaisjohtaja. Saatuaan fysiikan tutkinnon Stanfordin yliopistosta hän vietti yli 10 vuotta työskentelemällä tietojärjestelmien arkkitehtuurilla, tietopohjaisen liiketoimintaprosessin parantamisella ja organisaation hallinnassa. Hän on myös perustaja Peach Pie Apps Workshop -yrityksen, joka keskittyy voittoa tavoittelemattomien tietoratkaisujen rakentamiseen.