Den moderne transaktionsstak

Transaktionelle databaser har længe været den mest kritiske komponent i applikationsdesign. Hvorfor? Fordi en stabil database generelt er det ultimative håndhævelsespunkt for korrekthed i en rodet, distribueret verden. Uden dem ville vi betale for meget og underprise. Vi ville miste ryttere, der forsøgte at komme hjem fra lufthavnen, og vi ville miste varer i vores indkøbskurve. Vores onlinekonti ville gå tabt, duplikeres eller ødelægges og blive ubrugelige. 

Faktisk har transaktionsdatabasen (generelt kaldet OLTP - en forkortelse for online transaktionsbehandling - database) været så central for applikationsudvikling, at den over tid forbrugte mere og mere applikationsfunktionalitet. Mikrotjenester og andre moderne applikationsarkitekturer introducerede imidlertid nye kompleksiteter i applikationsdesign: Udviklere havde brug for at administrere data på tværs af forskellige tjenester og sikre sammenhæng mellem dem, hvilket tvang dem til at bygge komplekse datasynkroniserings- og behandlingsmekanismer internt. 

Og så, som branche, oplever vi en stigende bevidsthed om, at transaktionsgarantier er nødvendige uden for den traditionelle model. Vi ser fremkomsten af ​​systemer, der udvider stærke transaktionsgarantier ud over databasen, ind i selve de distribuerede apps. 

Vi har fulgt disse løsninger i løbet af de sidste par år. Generelt stræber de efter at tillade transaktionsstyring af staten i en stor distribueret app, uden at skabe skaleringsudfordringer og samtidig give et moderne programmeringsmiljø. 

Vi finder disse løsninger groft opdelt i to kategorier. En kategori er workflow orkestrering. Dette garanterer dybest set, at en blok kode vil køre til færdiggørelse, selv i lyset af fejl. Så det kan bruges med det formål at styre en distribueret tilstandsmaskine deterministisk uden at blive forvirret. Den anden kategori er database + arbejdsgang, som udvider traditionelt OLTP-databasedesign, hvilket giver mulighed for udførelse af vilkårlig kode til samme formål. 

Dette er stadig et meget begyndende område, og der er en masse forvirring omkring nomenklatur, hvordan hvert værktøj bruges i praksis, og hvem der skal bruge dem. For at hjælpe med at få en bedre forståelse spurgte vi praktikere fra førende ingeniørorganisationer om deres transaktionsstabel, og hvordan de tænker på tre nøglekoncepter for transaktionsmæssige arbejdsbelastninger: applikationstilstand, forretningslogik og forretningsdata. 

Før vi undersøger disse nye stakke, er her dog en hurtig semi-teknisk digression for at hjælpe med at forstå, hvordan vi kom hertil.

Transaktioner, garantier og moderne apps 

Den meget grove version er denne: Der er et sæt opgaver - transaktioner - som du enten vil udføre alle eller ingen af. Alt derimellem (hvis det er delvist gjort) vil ende i en korrupt tilstand. Det er svært at garantere noget i et distribueret system, men databaser gør det godt med transaktioner. Derfor er den nemmeste måde at håndtere garantier i mange systemer på blot at lave de fleste ting transaktioner og lade databasen håndtere dem.

Moderne apps er store distribuerede systemer med masser af brugere, der gør mange ting. Så selv at holde app-tilstanden konsistent (som at spore, hvor forskellige brugere er i et check-out-flow) bliver til et distribueret transaktionsproblem. I traditionelle monolitiske arkitekturer var styring af transaktioner ved hjælp af SQL med en OLTP-database noget effektiv. Men i den nye, komplekse verden af ​​mikrotjenester, der interagerer gennem API'er på højere niveau (f.eks. REST eller gRPC), er transaktionsbehov blevet fordelt i naturen. 

Mange virksomheder, der går på rejsen til mikrotjenester, har dog ikke gjort meget for at udvide stærke transaktionsgarantier ud over databasen. Og det er det i praksis næsten altid OKAY. Men efterhånden som applikationer skaleres, vokser uoverensstemmelser i data, og det samme gør den resulterende bugginess og uafstemte fejl i forretningsdata. Hvilket selvfølgelig kan være enormt problematisk. Dette tvinger applikationsudviklere til at håndtere en lang række af fejlscenarier og konfliktløsningsstrategier og til at sikre statens konsistens ved at komme med deres egne strategier gennem forskellige arkitektoniske mønstre.

Definitioner Forretningsdata ("data") refererer til de forretningskritiske data, der traditionelt er lagret i en OLTP-database for persistens og behandling (f.eks. brugerprofiloplysninger såsom navn, adresse, kreditvurdering osv.). Ansøgningstilstand henviser til systemets aktuelle tilstand; applikationstilstanden bestemmes af en værdi, der er lagret i et datalagringssystem, og hvilket trin programmets udførelse er på i en finite state-maskine (f.eks. tilstanden af ​​en ordre, såsom "ordre modtaget", "beholdning kontrolleret", "kredit kontrolleret ," "afsendt", "returneret"). Forretningslogik refererer til den del af programmet, der beskæftiger sig med, hvordan applikationen faktisk fungerer, eller hvad den gør, i stedet for udførelsesdetaljer (f.eks. "Hvis bruger_indkomst > $100K & kreditscore >650 ⇒ boliglån_godkendt = SAND").

Med henblik på denne diskussion er det vigtigt at skelne mellem applikationstilstand og forretningsdata. For eksempel at vide, at en kunde har indtastet sit kreditkort, men ikke har tjekket ud, er ansøgningstilstand. Dataene for kreditkortet og varerne i ansøgningsvognen er forretningsdata. 

I et typisk flow kommer en anmodning fra front-end, godkendes og bliver derefter rutet via en API-gateway eller GraphQL til det relevante slutpunkt. 

Det enkelte API-slutpunkt skal nu orkestrere titusinder eller hundredvis af mikrotjenester for at levere forretningstransaktionen til slutkunden. Det er her, udviklere typisk samler alt i forretningslogik-blobs og bruger derefter en kombination af køer, caches og håndkodede genforsøgsmekanismer til at få dataene til databasen - forhåbentlig begået som en fuld transaktion.

I takt med at applikationens skala øges, øges kompleksiteten af ​​håndtering af køer og caches også, samt antallet af skarpe kanter i afstemningslogikken, når der opstår problemer. 

Stigningen af ​​workflow-centrerede og database-centrerede transaktionsstabler

OK, så transaktioner er vigtige. LAMP på en database var ikke tilstrækkelig til skalering. Og en kæmpe hårbold af køer og genforsøgslogik er for skrøbelig. For at håndtere dette har vi i løbet af de sidste par år set fremkomsten af ​​nye løsninger, der bringer fornuft tilbage til transaktionslogik. De kan groft kategoriseres som enten workflow-centrerede tilgange eller database-centrerede tilgange.

Til dato arbejder workflow-motorer primært på applikationstilstand frem for forretningsdata og kræver ofte en vis kompleksitet, når de integreres med traditionelle databaser. Databasecentrerede tilgange tilføjer applikationslogik ved siden af ​​forretningsdata, men har endnu ikke den samme sofistikerede kodeudførelse som workflow-motorer. 

Diagrammet nedenfor giver en grov skitse af, hvordan workflow- og/eller databasecentrerede tilgange bruges i en Javascript/Typescript-applikation, forudsat at begge er i brug. Selvom de er særskilte dele af denne arkitektur i dag, har vi set tidlige tegn på en tendens, hvor databaser inkorporerer workflow-funktioner, og workflows begynder at indføre holdbar lagring. Denne sammensmeltning af kapaciteter indikerer, at linjerne mellem de to tilgange udviskes og bliver mindre tydelige i moderne arkitekturer. 

Workflow-centrerede tilgange i detaljer 

En arbejdsgang er simpelthen kodeblokke, der udføres baseret på hændelser eller timere, der udvikler applikationstilstandsmaskinen. Transaktionel arbejdsgang sikrer kodeeksekvering med stærke garantier, hvilket forhindrer delvise eller utilsigtede tilstande i applikationen. Udviklere skriver logikken, og workflow-motoren håndterer transaktioner, mutationer og idempotens. Forskellige workflow-motorer foretager forskellige afvejninger i forhold til, hvor meget af transaktionsdetaljerne, der eksponeres for udviklerne. 

Som et eksempel er nedenfor en visuel repræsentation af et check-out workflow, der kører på Orkes (Conductor): 

Der er to barske tilgange hvorved workflow-motorer får trækkraft. I et (typisk af Temporal.io) skriver udviklere kode ved hjælp af standard back-end programmeringssprog (f.eks. Go eller Java) og systemet vil sikre, at koden kører til fuldførelse, selv under en fiasko. I denne model bibeholdes program-opkaldsstakken, selvom koden venter på, at et blokeringsopkald afsluttes (f.eks. læse eller skrive). For at gøre dette ændres sprogkørselstiden for at forhindre delvis kodeudførelse under fejl. Fordelen ved denne tilgang er, at udviklere kan skrive på velkendte sprog og let fejlfinde med en vedligeholdt opkaldsstack. Vi ser denne tilgang mest populær hos back-end-teams, der beskæftiger sig med store, sofistikerede apps. 

Ulempen er, at det ofte kræver en del integrationsarbejde og indpakningskode at afsløre nyttige og sikre grænseflader for applikationsudviklere. En anden ulempe er, at den er afhængig af et brugerdefineret eksekveringslag i stedet for det blotte sprog, og der er edge-tilfælde, hvor udførelsen vil adskille sig fra modersmålets runtime. Så selvom udviklere kan bruge sprog, de er fortrolige med, skal de stadig forstå, hvordan det underliggende system fungerer.  

Den anden tilgang, som er mere populær blandt applikationsudviklere (især Typescript/Javascript) er, at workflow-motoren skal tjene som orkestrator af asynkrone funktioner (f.eks. Inngest, Defer og Trigger). I denne model dirigeres tredjepartsbegivenheder eller -funktioner til workflow-motoren, som derefter sender logik registreret af applikationsprogrammørerne, som skal give kontrollen tilbage, når behovet for at blokere på en anden asynkronfunktion opstår. Fordelen er, at dette er en langt mere let metode til at integrere i et program. Det tvinger også tilstrækkelig struktur på koden til, at teamet, der arbejder på den, lettere kan forstå det. Denne tilgang kan dog være sværere at fejlfinde uden værktøjsunderstøttelse, så fejlretning har en tendens til at være platformsspecifik.

Workflow-motorer er særligt kraftfulde, fordi de giver mulighed for gradvis overtagelse af eksisterende apps. De kan anvendes på stykvis basis til visse arbejdsgange med minimalt fodaftryk. Når det er sagt, stammer de to største mangler ved workflow-motorer fra det faktum, at de ikke strækker sig ind i databasen. Som et resultat er der ikke en enkelt, forespørgelig kilde til sandhed på tværs af applikationstilstand og forretningsdata. Desuden er den transaktionelle semantik generelt forskellig fra databasesemantikken, hvilket kræver, at applikationsudviklere håndterer kantforhold. 

Selvom det ikke er normen i dag, ønsker vi at illustrere de konceptuelle arkitekturer for, hvordan arbejdsgange i mange tilfælde kan bruges som vedvarende datalagre:

Databasecentrerede tilgange i detaljer 

Databasecentrerede tilgange starter med en database, men udvider den til at understøtte vilkårlig kodekørsel for at tillade arbejdsgange sammen med datastyring. De gør dette ved at give kontrol til programmørerne, så de kan træffe eksplicitte beslutninger om mutationer, transaktioner og idempotens for almindelige kodeblokke - hovedsageligt ved at eksponere OLTP-semantik direkte. Programmøren er ansvarlig for at holde forretningslogik og forretningsdata adskilt fra applikationstilstand. 

Faktisk er den rene databasevisning, at applikationstilstand altid kan udledes af forretningsdata. Dette gøres normalt ved at gemme applikationstilstand som et sæt transaktioner, der ændrer forretningsdata i databasen. Det er nemmest at tænke på dette som en database, der kan eksekvere kodeblokke med samme stærke garantier som workflow-systemerne beskrevet ovenfor. 

Internt kalder vi dette for Application Logic Transactional Platform (ALTP) tilgang, fordi den i sidste ende udvider OLTP-transaktioner ind i applikationen. Men det, der virkelig kendetegner ALTP, er, at det for greenfield-apps helt kan undgå behovet for app-udviklere til direkte at administrere back-end-infrastruktur.  

Fra ALTP-objektivet startede den mest brugte tilgang med Firebase, som tilbyder en fuld service "backend-oplevelse," herunder godkendelse, datalager, databaser og mere. Firebase og nyere deltagere, som Supabase, er fortsat meget populære platforme for greenfield-projekter. Og selvom de har en tendens til at forblive tro mod deres OLTP-rødder – og derfor ikke understøtter vilkårlig kodeudførelse for transaktionelle back-end-funktioner – er Supabase allerede begyndt at tilføje understøttelse af arbejdsgange.

Imidlertid næste generation af ALTP-tilbud ligesom Convex tillader eksekvering af vilkårlig kode som en transaktion ved siden af ​​databasen. Disse tilbud gør det muligt at skrive fuldstændig transaktionskompatibel kode på et normalt sprog (f.eks. Javascript/Typescript), hvor en enkelt kodeblok kan læse, skrive og mutere data - både applikationstilstand og forretningsdata. På en måde giver det udviklere en enkelt kilde til sandhed, der kan forespørges på, og giver primitiver i arbejdsgangene som abonnementer. 

ALTP løser det problem, workflow-motorer har ved at blive afkoblet fra databasen, men som et resultat kræver det, at brugerne stoler på deres databasetilbud frem for en standard OLTP for at få fordelene. Som et resultat ser vi primært, at teams anvender ALTP til greenfield-apps i stedet for at integrere det i eksisterende, komplekse backends.

Diagrammet ovenfor er en blanding af de mange operatører, vi har talt med. Nogle vil bare bruge en workflow-motor. Nogle vil blot bruge en database-centreret tilgang. Men mange vil bruge begge dele - især når de lige er begyndt at indføre arbejdsgange. Brugere af workflow-motorer i dag har en tendens til at være back-end-teams, der beskæftiger sig med store, komplekse applikationer, selvom vi også har set mange full-stack-teams tage dem i brug. Back-end-as-a-service-løsninger har en tendens til at være mere applikationsudviklervenlige og er mere almindelige, når appen driver teknologivalg. 

Konvergensen

Det er ved at blive klart, at workflow-centrerede tilgange og database-centrerede tilgange er på kollisionskurs. Den primære årsag til dette er, at selvom applikationstilstand og databasetilstand er logisk adskilte, er de afhængige af hinanden, og et system, der ikke dækker begge dele, er komplekst at rette op på og at fejlsøge.  

Som et eksempel kan du overveje en workflow-motor, der bruges til at spore tilstandsmaskinen for en brugers betalingsproces, og denne bruger tilføjer en vare til en indkøbskurv. Typisk sikrer workflow-motorer, at et kodetrin kører, selv i tilfælde af en fejl. Der kan dog være tilfælde, hvor motoren skal køre et givet trin igen under en fejl, fordi den ikke er helt sikker på, om trinnet blev fuldført. Hvis dette trin involverer at skrive forretningsdata til en traditionel database (i dette tilfælde varen i indkøbskurven), og databasen ikke er opmærksom på gentagelsesforsøget, ender det med en dubletpost. 

Der er to måder at håndtere dette på. En måde er at skubbe problemet til applikationsudvikleren, som vil bruge en nonce fra workflowsystemet for at sikre, at der kun skrives ét element. Men det forudsætter, at udvikleren forstår idempotens, hvilket er notorisk vanskeligt at få rigtigt, og dette undgår meget af magien ved at have et workflow-system. Den anden måde er at binde workflow-motoren til en database, der er opmærksom på workflow-transaktionssemantikken. Det er ikke helt sket endnu, men det er ikke svært at tro, det vil ske. 

På den anden side indser databasecentrerede tilgange, at generel arbejdsgang er virkelig nyttig for applikationsudviklere. Og så er vi begyndt at se databaser (som Convex) – som understøtter traditionelle databasefunktioner som forespørgsler, mutationer, indekser osv. – implementere funktionalitet som planlægning og abonnementer. Disse giver dem mulighed for at blive brugt som workflow-motorer. Det vil sige, at de tillader udførelse af vilkårlige kodeblokke med stærke garantier. 

Som Ian Livingstone (som gav feedback på dette stykke) udtrykte det, "Det er den klassiske 'Bringer du applikationslogikken til databasen, eller databasen til applikationslogikken?' spiller ud igen … denne gang forårsaget af at bryde monolitten op.” Efter at have haft den dikotomi i årtier, er det klart, at begge modeller vil bestå på kort sigt. Det er langt mindre klart, at det vil forblive tilfældet i det lange løb. 

Særlig tak til Charly Poly (Defer), Dan Farrelly (Inngest), David Khourshid (Stately), Ian Livingstone (Cape Security), Enes Akar (Upstash), James Cowling (Convex), Jamie Turner (Convex), Paul Copplestone (Supabase) ), Sam Lambert (PlanetScale), Tony Holdstock-Brown (Inngest), Matt Aitken (Trigger) for at have gennemgået dette indlæg og givet feedback. Derudover tak til Benjamin Hindman (Reboot), Fredrik Björk (Grafbase), Glauber Costa (Chiselstrike), Guillaume Salles (Liveblocks), Maxim Fateev (Temporal), Steven Fabre (Liveblocks) og Viren Baraiya (Orkes) for at hjælpe os med forskningen.

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang her.
• Udmøntning af fremtiden med Adryenn Ashley. Adgang her.
• Kilde: https://a16z.com/2023/04/14/the-modern-transactional-stack/