Der har været en masse brummer om reaktive systemer de sidste par år. Sammen med brummen kommer samlingen af relevante søgeordssalater som reaktive strømme, reaktive udvidelser, reaktiv programmering, funktionel reaktiv programmering osv. Hvis du har været i teknologiindustrien længe nok, har du set de cykliske op- og nedture i buzzwords. og akronymer fra tid til anden. Så er alt det der endnu en snart sprængt hype?
Jeg har hørt softwareingeniører afvise reaktive systemer som intet andet end et alias for asynkrone begivenhedsbaserede systemer, ligesom den måde, hvorpå nogle afviser mikrotjenester som SOA (serviceorienteret arkitektur) mindre ESB (enterprise-servicebus). Mens teknologiske buzzwords med genopfundet betydning ofte dukker op, ser jeg nok karakteristiske træk i reaktive systemer til at tro, at navnet ikke blot er et andet alias.
Hvad er reaktive systemer?
Det reaktive manifest beskriver de væsentlige egenskaber ved de reaktive systemer: lydhør, elastisk, elastisk og budskabsstyret. Det giver et billede på højt niveau og lyder lidt generisk. Især lydhørhed, modstandsdygtighed, elasticitet beskrevet i manifestet er næsten standardkrav til mange virkelige applikationer i disse dage.
Måske er "meddelelsesstyret" kravet, der virkelig adskiller reaktive systemer fra andre. Under emhætten er et reaktivt system afhængigt af interaktioner via asynkron meddelelsesoverføring, der etablerer grænser mellem individuelle komponenter. En sådan interaktionsmodel hjælper med at bane vejen mod løs kobling både tidsmæssigt og placeringsmæssigt for henholdsvis samtidighed og distribuerbarhed. Derudover tillader det, at systemet integreres med en ikke-blokerende mekanisme til at regulere datastrømme (mere om dette nedenfor).
Reaktive strømme
Ved opbygning af reaktive systemer synes der at være en fremtrædende tilgang, hvor databehandlingsoperationer, når det er relevant, formuleres som kompositionsstrømme. Det er ikke en del af kravene i Reactive Manifesto, men det kan være den iboende meddelelsesdrevne interaktionsmodel i reaktive systemer, der naturligt favoriserer en sådan strømcentreret modelleringsmetode.
Tilsyneladende opstået som et separat initiativ, kan reaktive strømme ses som en bestemt type reaktive systemer, der centrerer omkring strømbehandling, der udtrykker kompositionsstrømme som instruerede grafer.
Rygpres
En af de ikke-blokerende reguleringsmekanismer, der er nævnt tidligere, er modtryk. Det kan være den mest efterspurgte funktionalitet til systemer, der implementerer reaktive strømme. Det er en asynkron feedbackmekanisme, der fungerer i modsat retning af strømmen mod opstrøms komponenter til belastningsregulering.
Med det indbyggede modtryk, der regulerer strømmen på en ikke-blokerende måde, er systemet i stand til at fungere med relativt mere jævn hukommelsesudnyttelse. En sådan funktionalitet eliminerer potentielt ødelæggende stackoverløbsproblemer (f.eks. Forårsaget af en langsom datasink), som typisk skal imødegås ved hjælp af specialbygget databuffermekanisme i hele strømmen.
Hvad med reaktiv programmering?
Som et programmeringsparadigme til opbygning af reaktive systemer understreger reaktiv programmering at formulere asynkron programmeringslogik som datastrømme og automatisk udbredelse af ændringer i værdier af korrelerede variabler i systemet. De sprog, der anvendes til et sådant programmeringsparadigme, ville give passende komponerbare funktioner til at fungere på de formulerede strømme.
Ved design favoriserer reaktiv programmering den funktionelle programmeringsstil, der udtrykker og løser beregningsproblemer ved hjælp af komponerbare funktioner. Ikke desto mindre foregår eksistensen af udtrykket funktionel reaktiv programmering denne reaktive "bevægelse" med mere end et årti. FRP har et meget andet fokus og centrerer sig om at bruge funktioner til at udtrykke adfærd over kontinuerlig tid med en simpel denotationssemantik. Alligevel betragtes det nu ofte som reaktiv programmering med en eksplicit vægt i funktionel programmering.
Hvis en illustration med kode fungerer bedre, anbefaler jeg at læse Andre Staltz's tutorial-indlæg, der gennemgår essensen af reaktiv programmering i JavaScript ved hjælp af RxJS.
ReactiveX
ReactiveX, alias Reactive Extensions, er et API-bibliotek, der muliggør brug af kompositionsoperationer til at håndtere strømme af asynkrone begivenheder. Udvidelse fra observatørmønsteret udgør observerbare og observatører (som abonnerer på de observerbare) nøgleingredienserne i biblioteket med et sæt komponerbare operatorer til filtrering, transformation, sammenlægning osv. RxJS og RxJava er to af de mest populære implementeringer af ReactiveX i henholdsvis JavaScript og Java.
Akka skuespillere
Akka er et skuespillerbaseret bibliotek målrettet til opbygning af skalerbare samtidige og distribuerede applikationer på JVM (Java Virtual Machine). Kernen er beregningsprimitiver kaldet aktører, der opretholder tilstand og adfærd, og kommunikerer indbyrdes via asynkron meddelelsesoverførsel.
Skrevet i Scala er Akka-skuespillere af natur lette og løst koblede. Dette kombineret med Akkas robuste routing-, sharding- og pub-sub-funktioner til skalerbare distribuerede systemer som IoT gør dem til en god platform til opbygning af reaktive systemer.
Akka strømmer
En frontløber (og et stiftende medlem) af det reaktive streams-initiativ er Akka Streams. Det er bygget oven på Akka-skuespillere og giver et omfattende sæt API'er til opbygning af streamtopologier og behandling af streams på en meget kompositionsmæssig måde. Et nylig blogindlæg af mine centre omkring Akka-vandløb, og hvordan det kan bruges til at udføre nogle grundlæggende tekstminedrift.
Tilsyneladende har Akka streams som et reaktivt initiativ stræbt i disse dage. Akka-Streams-baserede drivere som Reactive Rabbit og ReactiveMongo for RabbitMQ og MongoDB er begyndt at få noget fart i teknologiindustrien. Derudover er Akka HTTP, som er den næste generation af Spray REST / HTTP-værktøjssættet, også bygget til at blive stream-aktiveret med Akka-streams som den underliggende motor.
Alle streams orienteret - på en eller anden måde
Med det stadigt voksende momentum i vedtagelsen af det reaktive systeminitiativ har det tilsyneladende overgået scenen for at være en simpel hype. Det er også åbenbart mere end et genopfundet buzzword af asynkrone begivenhedsbaserede systemer. Fra et teknisk fortjenesteperspektiv ser jeg ingen grund til, at det ikke bliver mere fremtrædende. Ikke desto mindre er selv open source-teknologiinitiativer som kommercielle produkter - god timing kan hurtigt tiltrække opmærksomhed i den indledende fase, og passende markedsføring kan hjælpe med at få løbende momentum, der er nødvendige for at popularisere til den bredere brugerbase.
Timingmæssig, funktionel programmering har været stigende, så jeg vil sige, at det er god timing, da programmeringsstilen er positivt omfavnet i opbygningen af reaktive systemer. Med hensyn til markedsføring tror jeg, at en mere intuitiv og åbenbarende navngivning af initiativet ville sælge bedre til teknologiindustrien. Man kunne næppe forstå noget meningsfuldt, når man for første gang hørte udtrykket "reaktive systemer". Selvom udtrykket "reaktivt" vedrører et eller andet aspekt af den omfavnede forandringsudbredelse i sådanne systemer, springer det ikke ud til publikum som en signaturkarakteristik.
Med reaktive systemer, reaktive streams og reaktiv programmering, der overvejende er orienteret omkring streams, tror jeg, at udtrykket "stream" er et mere åbenlyst nøgleord end "reaktivt." Ved at handle generelt med enkelhed og intuition ville jeg kombinere reaktive systemer og reaktive streams som et enkelt initiativ og erstatte "reaktiv" med noget, der centrerer omkring "stream".
