Det har vært mye sus om reaktive systemer de siste par årene. Sammen med buzz kommer samlingen av relevante søkeordsalater som reaktive strømmer, reaktive utvidelser, reaktiv programmering, funksjonell reaktiv programmering, etc. Hvis du har vært i teknologibransjen lenge nok, har du sett de konjunktur- og nedturene med moteord. og akronymer fra tid til annen. Så, er alt dette en annen snart sprøytenarkoman?
Jeg har hørt programvareingeniører avfeie reaktive systemer som intet annet enn et alias for asynkrone hendelsesbaserte systemer, omtrent som måten noen avviser mikrotjenester på som SOA (serviceorientert arkitektur) mindre ESB (enterprise service bus). Mens teknologiske motord med gjenoppfunnet betydning ofte dukker opp, ser jeg nok karakteristiske trekk i reaktive systemer til å tro at navnet ikke bare er et annet alias.
Hva er reaktive systemer?
Reactive Manifest beskriver de essensielle egenskapene til de reaktive systemene: responsiv, elastisk, elastisk og meldingsdrevet. Det gir et bilde på høyt nivå og høres litt generisk ut. Spesielt respons, motstandsdyktighet, elastisitet beskrevet i manifestet er nesten standardkrav for mange virkelige applikasjoner i disse dager.
Kanskje "meldingsdrevet" er kravet som virkelig skiller reaktive systemer fra andre. Under panseret er et reaktivt system avhengig av interaksjoner via asynkron meldingsoverføring som etablerer grenser mellom individuelle komponenter. En slik interaksjonsmodell hjelper til med å bane veien mot løs kobling både tidsmessig og lokaliseringsmessig for henholdsvis samtidighet og distribuerbarhet. I tillegg tillater det at systemet kan integreres med en ikke-blokkerende mekanisme for å regulere datastrømmer (mer om dette nedenfor).
Reaktive strømmer
Ved å bygge reaktive systemer ser det ut til å være en fremtredende tilnærming der databehandlingsoperasjoner, når det er aktuelt, formuleres når komposisjonsstrømmer strømmer. Det er ikke en del av kravene i Reactive Manifesto, men det kan være den iboende meldingsdrevne interaksjonsmodellen i reaktive systemer som naturlig favoriserer en slik strøm-sentrisk modelleringstilnærming.
Tilsynelatende dukket opp som et eget initiativ, reaktive strømmer kan sees på som en bestemt type reaktive systemer som sentrerer rundt strømbehandling, og uttrykker komposisjonsstrømmer som rettet graf.
Mottrykk
En av de ikke-blokkerende reguleringsmekanismene som er nevnt tidligere er mottrykk. Det kan være den mest etterspurte funksjonaliteten for systemer som implementerer reaktive strømmer. Det er en asynkron tilbakemeldingsmekanisme som fungerer i motsatt retning av strømmen mot oppstrøms komponenter for lastregulering.
Med det innebygde mottrykket som regulerer strømmen på en ikke-blokkerende måte, er systemet i stand til å operere med relativt mer jevn minneutnyttelse. Slike funksjonaliteter eliminerer potensielt ødeleggende problemer med stack-overflow (f.eks. Forårsaket av en langsom datasink) som vanligvis må motvirkes av spesialbaserte databuffermekanismer gjennom strømmen.
Hva med reaktiv programmering?
Som et programmeringsparadigme for å bygge reaktive systemer, legger reaktiv programmering vekt på å formulere asynkron programmeringslogikk som datastrømmer, og automatisk forplantning av endringer i verdier av korrelerte variabler i systemet. Språkene som brukes til et slikt programmeringsparadigme vil gi passende komponerbare funksjoner for å operere på de formulerte strømmer.
Ved design favoriserer reaktiv programmering den funksjonelle programmeringsstilen som uttrykker og løser beregningsproblemer ved hjelp av komponerbare funksjoner. Likevel foregår eksistensen av begrepet funksjonell reaktiv programmering denne reaktive "bevegelsen" med mer enn et tiår. FRP har et veldig annet fokus og fokuserer på å bruke funksjoner for å uttrykke atferd over kontinuerlig tid med en enkel betegnelsessemantikk. Likevel blir det ofte ofte sett på som reaktiv programmering med en eksplisitt vekt på funksjonell programmering.
Hvis en illustrasjon med kode fungerer bedre, anbefaler jeg å lese Andre Staltzs opplæringsinnlegg som går gjennom essensen av reaktiv programmering i JavaScript ved bruk av RxJS.
ReactiveX
ReactiveX, aka Reactive Extensions, er et API-bibliotek som gjør det mulig å bruke komposisjonsoperasjoner for å håndtere strømmer av asynkrone hendelser. Utvides fra observatørmønsteret, observerbare observatører og observatører (som abonnerer på observerbare) utgjør nøkkelingrediensene i biblioteket med et sett med komposerbare operatorer for filtrering, transformasjon, aggregering osv. RxJS og RxJava er to av de mest populære implementeringene av ReactiveX i henholdsvis JavaScript og Java.
Akka skuespillere
Akka er et aktørbasert bibliotek målrettet for å bygge skalerbare samtidige og distribuerte applikasjoner på JVM (Java Virtual Machine). Kjernen er beregningsprimitiver som kalles aktører som opprettholder tilstand og atferd, og kommuniserer seg imellom via asynkron overføring av meldinger.
Skrevet i Scala, er Akka-skuespillere av natur lette og løstkoblede. Det, kombinert med Akkas robuste ruting-, sharding- og pub-sub-funksjoner for skalerbare distribuerte systemer som IoT, gjør dem til en flott plattform for å bygge reaktive systemer.
Akka strømmer
En frontløper (og et grunnlegger) av reaktive strømmer-initiativet er Akka Streams. Den er bygget på toppen av Akka-skuespillere og gir et omfattende sett med APIer for å bygge strømtopologier og behandle strømmer på en svært komposisjonell måte. Et nylig blogginnlegg av mine sentre rundt Akka-bekker og hvordan det kan brukes til å utføre noen grunnleggende tekstutvinning.
Tilsynelatende har Akka streams som et reaktivt initiativ strevet i disse dager. Akka-Streams-baserte drivere som Reactive Rabbit og ReactiveMongo for RabbitMQ og MongoDB har begynt å få fart i teknologibransjen. I tillegg er Akka HTTP, som er neste generasjon av Spray REST / HTTP-verktøysettet, også bygget for å være strømaktivert med Akka-strømmer som den underliggende motoren.
Alle strømmer orientert - på en eller annen måte
Med det stadig økende momentumet i å ta i bruk det reaktive systeminitiativet, har det tilsynelatende overgått fasen av å være en ren hype. Det er tydeligvis mer enn et gjenoppfunnet moteord av asynkrone hendelsesbaserte systemer. Fra et teknisk fortjenesteperspektiv ser jeg ingen grunn til at det ikke blir mer fremtredende. Likevel er selv open source-teknologiinitiativer som kommersielle produkter - god timing kan raskt tiltrekke seg oppmerksomhet i den innledende fasen, og passende markedsføring kan bidra til å få et løpende momentum som er nødvendig for å popularisere til den bredere brukerbasen.
Timing-messig, funksjonell programmering har økt, så jeg vil si at det er flott timing, ettersom programmeringsstilen er gunstig omfavnet i å bygge reaktive systemer. Når det gjelder markedsføring, tror jeg at mer intuitiv og åpenbarende navngivning av initiativet vil selge bedre til teknologiindustrien. Man kunne knapt forstå noe meningsfylt når man for første gang hørte begrepet "reaktive systemer". Selv om begrepet "reaktivt" adresserer noen aspekter av den omfavnede forandringsforplantningen i slike systemer, hopper det ikke ut mot publikum som en signaturegenskap.
Med reaktive systemer, reaktive strømmer og reaktiv programmering som hovedsakelig er orientert rundt strømmer, tror jeg begrepet "strøm" er et mer avslørende søkeord enn "reaktivt." Ved å handle generelt med enkelhet og intuisjon, ville jeg kombinere reaktive systemer og reaktive strømmer som et enkelt initiativ, og erstatte "reaktiv" med noe som sentrerer rundt "strøm".
