Per pastaruosius porą metų apie reaktyviąsias sistemas buvo daug šurmulio. Kartu su „buzz“ pateikiama atitinkamų raktinių žodžių salotų, tokių kaip reaktyvūs srautai, reaktyvūs plėtiniai, reaktyvus programavimas, funkcinis reaktyvus programavimas ir kt., Rinkinys. Jei pakankamai ilgai dirbate technologijų pramonėje, matėte cikliškus madingų žodžių pakilimus ir nuosmukius ir laikas nuo laiko trumpiniai. Taigi, ar visa tai yra dar vienas greitai pasibaigiantis ažiotažas?
Girdėjau, kaip programinės įrangos inžinieriai atmeta reaktyvias sistemas kaip tik asinchroninių įvykiais pagrįstų sistemų slapyvardį, panašiai kaip tai, kaip kai kurie atmeta mikropaslaugas, nes SOA (į paslaugas orientuota architektūra) mažiau ESB (įmonės paslaugų magistralė). Nors dažnai atsiranda naujų žodžių su išradusia prasme technologija, reaktyviose sistemose matau pakankamai skiriamųjų bruožų, kad manau, jog šis vardas nėra tik dar vienas slapyvardis.
Kas yra reaktyviosios sistemos?
Reaktyviame manifeste aprašomos esminės reaktyviųjų sistemų charakteristikos: reaguojančios, elastingos, elastingos ir valdomos pranešimais. Tai suteikia aukšto lygio vaizdą ir skamba šiek tiek bendrai. Visų pirma, jautrumas, atsparumas, elastingumas, aprašyti manifeste, yra beveik standartiniai šių dienų daugelio realių programų reikalavimai.
Galbūt „pranešimas grindžiamas“ yra reikalavimas, kuris reaktyvias sistemas skiria nuo kitų. Po gaubtu reaktyvi sistema remiasi sąveika per asinchroninį pranešimų perdavimą, nustatantį ribas tarp atskirų komponentų. Toks sąveikos modelis padeda nutiesti kelią laisvai susieti tiek laiko, tiek vietos požiūriu, kad būtų galima lygiagrečiai ir paskirstomai. Be to, tai leidžia sistemoje būti integruota su kai kuriais neužblokavimo mechanizmais, reguliuojančiais duomenų srautus (apie tai plačiau).
Reaktyvūs srautai
Kuriant reaktyviąsias sistemas, atrodo, yra aiškus požiūris, kai duomenų apdorojimo operacijos, kai tinkama, formuluojamos kaip sudėtiniai srautai. Tai nėra reaktyvaus manifesto reikalavimų dalis, tačiau tai gali būti reaktyviųjų sistemų prigimtinis pranešimas, pagrįstas tokiu srautu orientuotu modeliavimo metodu.
Akivaizdu, kad reaktyvieji srautai atsirado kaip atskira iniciatyva, todėl juos galima vertinti kaip specifinį reaktyviųjų sistemų tipą, kuris sutelktas ties srauto apdorojimu, išreiškiant kompozicinius srautus kaip nukreiptus grafikus.
Nugaros spaudimas
Vienas iš anksčiau paminėtų neblokuojančių reguliavimo mechanizmų yra priešslėgis. Tai gali būti labiausiai ieškoma funkcinė sistema, įgyvendinanti reaktyvius srautus. Tai asinchroninis grįžtamojo ryšio mechanizmas, veikiantis priešinga srauto kryptimi link komponentų prieš srovę, kad būtų galima reguliuoti apkrovą.
Kai įmontuotas priešpriešinis slėgis reguliuoja srauto srautus neužblokuodamas, sistema gali veikti gana stabiliai naudodama atmintį. Toks funkcionalumas pašalina potencialiai niokojančias kamino perpildymo problemas (pvz., Sukeltas lėto duomenų nusileidimo), kurias paprastai teks įveikti pritaikant duomenų buferio mechanizmą visame srauto sraute.
O reaktyvus programavimas?
Kaip reaktyvių sistemų kūrimo programavimo paradigma, reaktyvusis programavimas pabrėžia asinchroninės programavimo logikos formulavimą kaip duomenų srautus ir automatinį koreliacinių kintamųjų reikšmių pokyčių skleidimą sistemoje. Kalbos, naudojamos tokiai programavimo paradigmai, suteiktų tinkamas komponavimo funkcijas, kad veiktų suformuluotuose srautuose.
Pagal konstrukciją reaktyvusis programavimas palaiko funkcinį programavimo stilių, kuris išreiškia ir išsprendžia skaičiavimo problemas naudodamas komponuojamas funkcijas. Nepaisant to, terminas „funkcinis reaktyvus programavimas“ egzistuoja anksčiau nei prieš dešimtmetį. FRP skiria labai skirtingą dėmesį ir sutelkia dėmesį į funkcijų naudojimą, kad elgesys būtų išreikštas nepertraukiamu laiku, naudojant paprastą denotacijos semantiką. Tačiau dabar tai dažnai vertinama kaip reaktyvus programavimas, aiškiai pabrėžiant funkcinį programavimą.
Jei iliustracija su kodu veikia geriau, rekomenduoju perskaityti Andre Staltzo mokomąjį įrašą, kuriame aprašoma „JavaScript“ reaktyvaus programavimo esmė naudojant „RxJS“.
ReaktyvusX
„ReactiveX“, dar žinomi kaip „Reactive Extensions“, yra API biblioteka, leidžianti naudoti kompozicines operacijas asinchroninių įvykių srautams tvarkyti. Remiantis stebėtojų modeliu, stebimieji elementai ir stebėtojai (kurie yra stebimųjų prenumeratoriai) yra pagrindiniai bibliotekos ingredientai, sudarantys sudedamųjų operatorių rinkinį filtravimui, transformavimui, kaupimui ir kt. RxJS ir RxJava yra du populiariausi „ReactiveX“ atitinkamai „JavaScript“ ir „Java“.
Akkos aktoriai
„Akka“ yra aktorių biblioteka, skirta kurti keičiamas vienu metu ir platinamas programas JVM („Java Virtual Machine“). Jos esmė yra skaičiavimo primityviai, vadinami veikėjais, kurie palaiko būseną ir elgesį ir bendrauja tarpusavyje per asinchroninį pranešimų perdavimą.
Parašyti „Scaloje“, „Akka“ aktoriai iš prigimties yra lengvi ir laisvai susieti. Tai kartu su tvirtais „Akka“ keičiamo paskirstymo sistemų, tokių kaip IoT, maršrutizavimo, dalijimo ir „pub-sub“ funkcijomis daro juos puikia platforma kuriant reaktyvias sistemas.
Akkos upeliai
Pirmoji reaktyviųjų srautų iniciatyvos dalyvė (ir steigėja) yra „Akka Streams“. Jis pastatytas ant „Akka“ aktorių ir suteikia platų API rinkinį srautų topologijoms kurti ir srautams apdoroti labai kompoziciškai. Neseniai parašytas tinklaraščio įrašas yra apie „Akka“ srautus ir apie tai, kaip jį galima naudoti norint atlikti kai kuriuos pagrindinius teksto kasimus.
Matyt, „Akka“ srautai, kaip reaktyvi iniciatyva, šiomis dienomis siekė. Tokios „Akka-Streams“ tvarkyklės, kaip „Reactive Rabbit“ ir „ReactiveMongo for RabbitMQ“ bei „MongoDB“, pradėjo įgauti tam tikrą pagreitį technologijų pramonėje. Be to, „Akka HTTP“, kuris yra naujos kartos „Spray REST“ / HTTP įrankių rinkinys, taip pat sukurtas taip, kad jį būtų galima įjungti naudojant „Akka“ srautus kaip pagrindinį variklį.
Visi srautai orientuoti - tam tikru būdu
Nuolat augant reaktyviųjų sistemų iniciatyvai, matyt, ji peržengė paprasčiausio ažiotažo stadiją. Tai taip pat akivaizdžiai daugiau nei iš naujo sugalvotas asinchroninių įvykiais pagrįstų sistemų žodis. Žiūrint iš techninių nuopelnų, nematau priežasties, kodėl ji netaps ryškesnė. Nepaisant to, net atviro kodo technologijų iniciatyvos yra tarsi komerciniai produktai - tinkamas laikas gali greitai pritraukti dėmesį pradiniame etape, o tinkama rinkodara gali padėti įgyti nuolatinį impulsą, reikalingą populiarėjant platesnei vartotojų bazei.
Laiko požiūriu funkcionalus programavimas auga, todėl sakyčiau, kad tai puikus laikas, nes kuriant reaktyvias sistemas programavimo stilius yra palankiai pritaikytas. Kalbant apie rinkodarą, manau, kad intuityvesnis ir apreiškesnis iniciatyvos įvardijimas būtų geriau parduodamas technologijų pramonei. Pirmą kartą išgirdus terminą „reaktyviosios sistemos“, vargu ar būtų galima suvokti ką nors prasmingo. Nors terminas „reaktyvus“ susijęs su kai kuriais perimamų pokyčių tokiose sistemose aspektais, jis neiššoka iš auditorijos kaip parašo charakteristikos.
Kai reaktyvios sistemos, reaktyvūs srautai ir reaktyvus programavimas vyrauja daugiausia aplink srautus, manau, kad terminas „srautas“ yra labiau apreiškiamasis raktinis žodis nei „reaktyvus“. Prekiaudamas bendrumu su paprastumu ir intuicija, aš sujungčiau reaktyvias sistemas ir reaktyvius srautus kaip vieną iniciatyvą, o „reaktyvų“ pakeisčiau tuo, kas sutelktas aplink „srautą“.
