Moderni Transaction Stack

Tapahtumatietokannat ovat pitkään olleet sovellussuunnittelun kriittisin komponentti. Miksi? Koska vankka tietokanta on yleensä perimmäinen oikeellisuuden valvontapiste sotkuisessa, hajautetussa maailmassa. Ilman niitä maksaisimme liikaa ja alimaksuisimme. Menettäisimme matkustajia, jotka yrittävät päästä kotiin lentokentältä, ja menetisimme tavarat ostoskärryissämme. Online-tilimme katoaisi, monistuisi tai vioittuisi ja muuttuisi käyttökelvottomiksi. 

Itse asiassa tapahtumatietokanta (yleisesti kutsuttu OLTP - lyhenne sanoista online-transaktioiden käsittely - tietokanta) on ollut niin keskeinen sovelluskehityksessä, että ajan myötä se kulutti yhä enemmän sovellustoimintoja. Mikropalvelut ja muut nykyaikaiset sovellusarkkitehtuurit toivat kuitenkin uusia monimutkaisia ​​sovelluksia sovellussuunnitteluun: kehittäjien piti hallita tietoja eri palveluissa ja varmistaa niiden välinen johdonmukaisuus, mikä pakotti heidät rakentamaan monimutkaisia ​​tietojen synkronointi- ja käsittelymekanismeja talon sisällä. 

Niinpä alamme on tietoinen siitä, että transaktiotakuita tarvitaan perinteisen mallin ulkopuolella. Me näemme järjestelmät, jotka laajentavat vahvat tapahtumatakuut tietokannan ulkopuolelle itse hajautettuihin sovelluksiin. 

Olemme seuranneet näitä ratkaisuja muutaman viime vuoden aikana. Yleensä ne pyrkivät mahdollistamaan tilan transaktiohallinnan suuressa hajautetussa sovelluksessa luomatta skaalaushaasteita ja tarjoamalla samalla modernin ohjelmointiympäristön. 

Mielestämme nämä ratkaisut jakautuvat karkeasti kahteen luokkaan. Yksi kategoria on työnkulun orkestrointi. Tämä takaa pohjimmiltaan sen, että koodilohko suoritetaan loppuun, jopa epäonnistuessa. Joten sitä voidaan käyttää hajautetun tilakoneen hallintaan deterministisesti ilman, että se tulee hämärtymään. Toinen luokka on tietokanta + työnkulku, joka laajentaa perinteistä OLTP-tietokannan suunnittelua mahdollistaen mielivaltaisen koodin suorittamisen samaan tarkoitukseen. 

Tämä on vielä hyvin syntymässä oleva alue, ja nimistössä on paljon sekaannusta, miten kutakin työkalua käytetään käytännössä ja kenen niitä tulisi käyttää. Auttaaksemme ymmärtämään paremmin, kysyimme johtavien suunnitteluorganisaatioiden toimijoilta heidän transaktiopinoistaan ​​ja siitä, kuinka he ajattelevat kolmesta tapahtumatyökuormien keskeisestä käsitteestä: sovelluksen tila, liiketoimintalogiikka ja liiketoimintatiedot. 

Ennen kuin tarkastelemme näitä uusia pinoja, tässä on nopea puolitekninen poikkeama, joka auttaa ymmärtämään, miten pääsimme tänne.

Tapahtumat, takuut ja modernit sovellukset 

Erittäin karkea versio on tämä: On joukko tehtäviä - tapahtumia -, jotka joko haluat tehdä kaikki tai et halua tehdä mitään. Kaikki siltä väliltä (jos se on osittain tehty) päättyy korruptoituneeseen tilaan. Sitä on vaikea taata mitään hajautetussa järjestelmässä, mutta tietokannat tekevät sen hyvin tapahtumien kanssa. Siksi helpoin tapa käsitellä takuita monissa järjestelmissä on vain tehdä useimmat tapahtumat ja antaa tietokannan käsitellä ne.

Nykyaikaiset sovellukset ovat suuria hajautettuja järjestelmiä, joissa monet käyttäjät tekevät monia asioita. Joten jopa sovelluksen tilan johdonmukainen pitäminen (kuten eri käyttäjien kirjautumisprosessin seuranta) muuttuu hajautetun tapahtuman ongelmaksi. Perinteisissä monoliittisissa arkkitehtuureissa tapahtumien hallinta SQL:n avulla OLTP-tietokannan kanssa oli jokseenkin tehokasta. Mutta uudessa, monimutkaisessa maailmassa, jossa mikropalvelut ovat vuorovaikutuksessa korkeamman tason API:iden (esim. REST tai gRPC) kautta, tapahtumatarpeet ovat hajautuneet luonteeltaan. 

Kuitenkin monet yritykset, jotka ovat matkalla mikropalveluihin, eivät ole tehneet paljon laajentaakseen vahvoja transaktiotakuita tietokannan ulkopuolelle. Ja käytännössä näin melkein aina OK. Mutta kun sovellukset laajenevat, epäjohdonmukaisuudet tiedoissa kasvavat, samoin kuin niistä johtuva buggeus ja yhteensovittamattomat virheet liiketoimintatiedoissa. Mikä tietysti voi olla suuri ongelma. Tämä pakottaa sovelluskehittäjät käsittelemään monia epäonnistumisskenaarioita ja konfliktien ratkaisustrategioita ja varmistamaan tilan johdonmukaisuuden kehittämällä omia strategioitaan erilaisten arkkitehtuurimallien avulla.

Määritelmät Yritystiedot ("data") viittaa liiketoiminnan kannalta kriittisiin tietoihin, jotka on perinteisesti tallennettu OLTP-tietokantaan pysyvyyttä ja käsittelyä varten (esim. käyttäjäprofiilitiedot, kuten nimi, osoite, luottopisteet jne.). Sovelluksen tila viittaa järjestelmän nykyiseen tilaan; sovelluksen tilan määrää tietotallennusjärjestelmään tallennettu arvo ja se, missä vaiheessa ohjelman suoritus on äärellisen tilan koneessa (esim. tilauksen tila, kuten "tilaus vastaanotettu", "varasto tarkistettu", "luotto tarkistettu" ”, “lähetetty”, “palautettu”). Liikelogiikka viittaa ohjelman siihen osaan, joka käsittelee sovelluksen todellista toimintaa tai mitä se tekee suoritustietojen sijaan (esim. "Jos käyttäjätulo > 100 650 $ & luottopiste > XNUMX ⇒ kiinnityshyväksytty = TOSI").

Tätä keskustelua varten on tärkeää erottaa sovelluksen tila ja liiketoimintatiedot. Esimerkiksi tieto siitä, että asiakas on syöttänyt luottokorttinsa mutta ei ole kirjautunut ulos, on hakemuksen tila. Luottokortin tiedot ja hakemuskorin tuotteet ovat yritystietoja. 

Tyypillisessä kulussa pyyntö tulee käyttöliittymästä, todennetaan ja reititetään sitten API-yhdyskäytävän tai GraphQL:n kautta asiaankuuluvaan päätepisteeseen. 

Tämän yhden API-päätepisteen on nyt organisoitava kymmeniä tai satoja mikropalveluita toimittaakseen liiketoimintatapahtuman loppuasiakkaalle. Täällä kehittäjät tyypillisesti yhdistävät kaiken liiketoimintalogiikkablobeiksi ja käyttävät sitten jonojen, välimuistien ja käsin koodattujen uudelleenyritysmekanismien yhdistelmää saadakseen tiedot tietokantaan – toivottavasti sitoutuneena täydellisenä tapahtumana.

Sovelluksen laajuuden kasvaessa jonojen ja välimuistien hallinnan monimutkaisuus sekä täsmäytyslogiikan terävien reunojen määrä lisääntyy ongelmien ilmetessä. 

Työnkulkukeskeisten ja tietokantakeskeisten tapahtumapinojen nousu

Ok, joten kaupat ovat tärkeitä. Tietokannan LAMP ei riittänyt mittakaavaan. Ja jättimäinen jonojen ja uudelleenyrityslogiikan hiuspallo on liian hauras. Tämän ratkaisemiseksi olemme nähneet muutaman viime vuoden aikana uusia ratkaisuja, jotka tuovat mielenterveyden takaisin tapahtumalogiikkaan. Ne voidaan karkeasti luokitella joko työnkulkukeskeisiksi lähestymistavoiksi tai tietokantakeskeisiksi lähestymistavoiksi.

Tähän mennessä työnkulkumoottorit toimivat ensisijaisesti sovelluksen tilassa eikä yritystietojen perusteella, ja ne vaativat usein monimutkaisuutta integroitaessa perinteisiin tietokantoihin. Tietokantakeskeiset lähestymistavat lisäävät sovelluslogiikkaa liiketoimintatietojen rinnalle, mutta niillä ei vielä ole samaa koodinsuorituskykyä kuin työnkulkumoottoreilla. 

Alla oleva kaavio tarjoaa karkean luonnoksen siitä, kuinka työnkulku- ja/tai tietokantakeskeisiä lähestymistapoja käytetään Javascript/Typescript-sovelluksessa, olettaen, että molemmat ovat käytössä. Vaikka ne ovatkin tämän arkkitehtuurin erillisiä osia nykyään, olemme nähneet varhaisia ​​merkkejä trendistä, jossa tietokannat sisältävät työnkulkuominaisuuksia ja työnkulut alkavat ottaa käyttöön kestävää tallennustilaa. Tämä ominaisuuksien yhdistäminen osoittaa, että rajat näiden kahden lähestymistavan välillä hämärtyvät ja muuttuvat vähemmän erottuviksi nykyaikaisissa arkkitehtuureissa. 

Työnkulkukeskeisiä lähestymistapoja yksityiskohtaisesti 

Työnkulku on yksinkertaisesti koodilohkoja, jotka suoritetaan tapahtumien tai ajastimien perusteella, jotka kehittävät sovelluksen tilakonetta. Transaktiotyönkulku varmistaa koodin suorittamisen vahvoilla takuilla, mikä estää osittaiset tai tahattomat tilat sovelluksessa. Kehittäjät kirjoittavat logiikan, ja työnkulkumoottori käsittelee tapahtumat, mutaatiot ja idempotenssit. Eri työnkulkumoottorit tekevät erilaisia ​​kompromisseja sen suhteen, kuinka suuri osa tapahtuman tiedoista paljastaa kehittäjille. 

Esimerkkinä alla on visuaalinen esitys Orkesissa (Conductor) käynnissä olevasta uloskirjautumistyönkulusta: 

On kaksi karkeaa lähestymistapaa jolla työnkulkumoottorit saavat pidon. Yhdessä (tyypillisesti Temporal.io) kehittäjät kirjoittavat koodia käyttämällä tavallisia taustaohjelmointikieliä (esim. Go tai Java) ja järjestelmä varmistaa, että koodi suoritetaan loppuun, jopa epäonnistumisen aikana. Tässä mallissa ohjelmakutsupino säilyy, vaikka koodi odottaa estokutsun valmistumista (esim. luku tai kirjoitus). Tätä varten kielen ajonaikaa muutetaan estämään osittaisen koodin suorittaminen virheiden aikana. Tämän lähestymistavan kääntöpuolena on, että kehittäjät voivat kirjoittaa tutuilla kielillä ja tehdä virheenkorjauksen helposti ylläpidetyn puhelupinon avulla. Näemme tämän lähestymistavan suosituimpana taustatiimien keskuudessa, jotka käsittelevät suuria, kehittyneitä sovelluksia. 

Haittapuolena on, että se vaatii usein paljon integrointityötä ja käärekoodia paljastaakseen hyödyllisiä ja turvallisia käyttöliittymiä sovelluskehittäjille. Toinen haittapuoli on, että se luottaa mukautettuun suorituskerrokseen paljaan kielen sijaan, ja on reunatapauksia, joissa suoritus eroaa äidinkielen ajonajasta. Joten vaikka kehittäjät voivat käyttää tuntemiaan kieliä, heidän on silti ymmärrettävä, miten taustalla oleva järjestelmä toimii.  

Toinen lähestymistapa, joka on suositumpi sovelluskehittäjien keskuudessa (erityisesti Typescript/Javascript), on työnkulkumoottorin toimii asynkronisten toimintojen järjestäjänä (esim. Ingest, Defer ja Trigger). Tässä mallissa kolmannen osapuolen tapahtumat tai toiminnot ohjataan työnkulkukoneeseen, joka sitten lähettää sovellusohjelmoijien rekisteröimän logiikan, jonka on palautettava hallinta, kun ilmenee tarve estää toinen asynkroninen toiminto. Hyvä puoli on, että tämä on paljon kevyempi tapa integroida ohjelmaan. Se myös pakottaa koodiin tarpeeksi rakennetta, jotta sen parissa työskentelevä tiimi ymmärtää sen helpommin. Tätä lähestymistapaa voi kuitenkin olla vaikeampi korjata ilman työkalutukea, joten virheenkorjaus on yleensä alustakohtaista.

Työnkulkumoottorit ovat erityisen tehokkaita, koska ne mahdollistavat asteittaisen käyttöönoton olemassa olevissa sovelluksissa. Niitä voidaan soveltaa osittaisesti tiettyihin työnkulkuihin mahdollisimman vähän. Työnkulkumoottoreiden kaksi suurinta puutetta johtuvat kuitenkin siitä, että ne eivät ulotu tietokantaan. Tämän seurauksena sovelluksen tilasta ja liiketoimintatiedoista ei ole yhtä, kysyttävää totuuden lähdettä. Myös tapahtumasemantiikka eroaa yleensä tietokannan semantiikasta, mikä edellyttää sovelluskehittäjien käsittelevän reunaehtoja. 

Vaikka se ei ole nykyään normi, haluamme havainnollistaa käsitteellisiä arkkitehtuureja siitä, kuinka työnkulkuja voidaan monissa tapauksissa käyttää pysyvinä tietovarastoina:

Tietokantakeskeisiä lähestymistapoja yksityiskohtaisesti 

Tietokantakeskeiset lähestymistavat alkavat tietokannasta, mutta laajentavat sitä tukemaan mielivaltaisen koodin suorittamista mahdollistaakseen työnkulkuja tiedonhallinnan ohella. He tekevät tämän antamalla ohjelmoijille hallinnan, jotta he voivat tehdä täsmällisiä päätöksiä tavallisten koodilohkojen mutaatioista, transaktioista ja idempotenssista - lähinnä paljastamalla OLTP-semantiikan suoraan. Ohjelmoija on vastuussa liiketoimintalogiikan ja liiketoimintatietojen pitämisestä erillään sovelluksen tilasta. 

Itse asiassa puhdas tietokantanäkymä on, että sovelluksen tila voidaan aina johtaa yritystiedoista. Tämä tehdään yleensä tallentamalla sovelluksen tila joukkona tapahtumia, jotka muokkaavat yritystietoja tietokantaan. On helpointa ajatella tätä tietokannana, joka voi suorittaa koodilohkoja samoin vahvoilla takuilla kuin yllä kuvatut työnkulkujärjestelmät. 

Sisäisesti kutsumme tätä Application Logic Transaktional Platform (ALTP) lähestymistapaa, koska viime kädessä se laajentaa OLTP-tapahtumat sovellukseen. Mutta ALTP:lle on ominaista se, että uusille sovelluksille se voi täysin välttää sovellusten kehittäjien tarpeen hallita suoraan taustainfrastruktuuria.  

ALTP-objektiivista yleisimmin käytetty lähestymistapa alkoi Firebasesta, joka tarjoaa mm täyden palvelun "taustakokemus", mukaan lukien todennus, tietovarasto, tietokannat ja paljon muuta. Firebase ja uudemmat tulokkaat, kuten Supabase, ovat edelleen erittäin suosittuja ympäristöprojekteja. Ja vaikka niillä on taipumus pysyä uskollisina OLTP-juurilleen – eivätkä siten tue mielivaltaisen koodin suorittamista transaktioiden taustatoiminnoille – Supabase on jo alkanut lisätä tukea työnkulkuille.

Kuitenkin, seuraavan sukupolven ALTP-tarjonta kuten Convex sallii mielivaltaisen koodin suorittamisen tapahtumana tietokannan rinnalla. Nämä tarjoukset mahdollistavat täysin transaktioyhteensopivan koodin kirjoittamisen normaalilla kielellä (esim. Javascript/Typescript), jossa yksi koodilohko voi lukea, kirjoittaa ja muuntaa tietoja – sekä sovelluksen tila- että liiketoimintatietoja. Tietyssä mielessä se antaa kehittäjille yhden kysyttävän totuuden lähteen ja tarjoaa työnkulun primitiivisiä, kuten tilauksia. 

ALTP ratkaisee ongelmat, joita työnkulkumoottoreilla on irrotettu tietokannasta, mutta sen seurauksena käyttäjien on turvattava tietokantatarjontaansa tavallisen OLTP:n sijaan saadakseen hyödyt. Seurauksena on, että tiimit ottavat ensisijaisesti käyttöön ALTP:n uusille sovelluksille sen sijaan, että ne integroivat sen olemassa oleviin monimutkaisiin taustajärjestelmiin.

Yllä oleva kaavio on yhdistelmä monista operaattoreista, joiden kanssa puhuimme. Jotkut käyttävät vain työnkulkumoottoria. Jotkut käyttävät vain tietokantakeskeistä lähestymistapaa. Mutta monet käyttävät molempia - varsinkin kun he ovat vasta alkamassa ottaa työnkulkuja käyttöön. Työnkulkumoottoreiden käyttäjät ovat nykyään yleensä taustatiimejä, jotka käsittelevät suuria ja monimutkaisia ​​sovelluksia, vaikka olemme nähneet myös monien täyden pinon tiimien ottavan niitä käyttöön. Palveluna toimivat taustaratkaisut ovat yleensä sovelluskehittäjäystävällisempiä ja niitä käytetään yleisemmin, kun sovellus ohjaa teknologian valintaa. 

Lähentyminen

On käymässä selväksi, että työnkulkukeskeiset lähestymistavat ja tietokantakeskeiset lähestymistavat ovat törmäyskurssilla. Ensisijainen syy tähän on, että vaikka sovelluksen tila ja tietokannan tila ovat loogisesti erillisiä, ne ovat riippuvaisia ​​toisistaan, ja järjestelmä, joka ei kata molempia, on monimutkainen korjata ja korjata.  

Esimerkkinä voidaan harkita työnkulkukonetta, jota käytetään käyttäjän kassaprosessin tilakoneen seuraamiseen, ja tämä käyttäjä lisää tuotetta ostoskoriin. Tyypillisesti työnkulkumoottorit varmistavat, että koodivaihe suoritetaan myös vian sattuessa. Saattaa kuitenkin olla tapauksia, joissa moottorin on suoritettava tietty vaihe uudelleen vian aikana, koska ei ole täysin varmaa, onko vaihe suoritettu kokonaan. Jos tähän vaiheeseen kuuluu yritystietojen kirjoittaminen perinteiseen tietokantaan (tässä tapauksessa ostoskorissa olevaan tuotteeseen) eikä tietokanta ole tietoinen kaksoiskappaleesta, se päätyy kaksoismerkintään. 

On kaksi tapaa käsitellä tätä. Yksi tapa on työntää ongelma sovelluksen kehittäjälle, joka käyttää työnkulkujärjestelmän tarjoamaa noncea varmistaakseen, että vain yksi kohde on kirjoitettu. Mutta tämä edellyttää, että kehittäjä ymmärtää idempotenssin, joka on tunnetusti hankalaa saada oikeaan, ja tämä poistaa suuren osan työnkulkujärjestelmän taikuudesta. Toinen tapa on sitoa työnkulkumoottori tietokantaan, joka on tietoinen työnkulun tapahtumasemantiikasta. Tämä ei ole vielä aivan tapahtunut, mutta ei ole vaikea uskoa, että se tapahtuu. 

Toisaalta tietokantakeskeiset lähestymistavat ymmärtävät, että yleinen työnkulku on todella hyödyllinen sovellusten kehittäjille. Ja niin alamme nähdä tietokannat (kuten Convex) - jotka tukevat perinteisiä tietokantatoimintoja, kuten kyselyjä, mutaatioita, indeksejä jne. - toteuttavat toimintoja, kuten ajoitusta ja tilauksia. Niiden avulla niitä voidaan käyttää työnkulkumoottoreina. Toisin sanoen ne mahdollistavat mielivaltaisten koodilohkojen suorittamisen vahvoilla takuilla. 

Kuten Ian Livingstone (joka antoi palautetta tästä kappaleesta) sanoi, "Se on klassinen "Tuotko sovelluslogiikan tietokantaan vai tietokannan sovelluslogiikkaan?" pelata uudelleen… tällä kertaa johtui monoliitin rikkomisesta." Koska tämä kaksijakoisuus on ollut vuosikymmeniä, on selvää, että molemmat mallit säilyvät lyhyellä aikavälillä. On paljon vähemmän selvää, että se pysyy samana pitkällä aikavälillä. 

Erityinen kiitos Charly Polylle (Defer), Dan Farrellylle (Inngest), David Khourshidille (Stately), Ian Livingstonelle (Cape Security), Enes Akarille (Upstash), James Cowlingille (kupera), Jamie Turnerille (kupera), Paul Copplestonelle (Supabase) ), Sam Lambert (PlanetScale), Tony Holdstock-Brown (Inngest), Matt Aitken (Trigger) tämän viestin tarkistamisesta ja palautteen antamisesta. Lisäksi kiitos Benjamin Hindmanille (Reboot), Fredrik Björkille (Grafbase), Glauber Costalle (Chiselstrike), Guillaume Sallesille (Liveblocks), Maxim Fateeville (Temporal), Steven Fabrelle (Liveblocks) ja Viren Baraiyalle (Orkes) auttamisesta. tutkimus.

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• Platoblockchain. Web3 Metaverse Intelligence. Tietoa laajennettu. Pääsy tästä.
• Tulevaisuuden lyöminen Adryenn Ashley. Pääsy tästä.
• Lähde: https://a16z.com/2023/04/14/the-modern-transactional-stack/