Pēdējo pāris gadu laikā par reaktīvajām sistēmām ir daudz dzirdēts. Līdztekus ieteikumiem nāk atbilstošu atslēgvārdu salātu kolekcija, piemēram, reaktīvās plūsmas, reaktīvie paplašinājumi, reaktīvā programmēšana, funkcionālā reaktīvā programmēšana utt. Ja pietiekami ilgi esat bijis tehnoloģiju industrijā, esat redzējis buzzwords cikliskus kāpumus un kritumus un laiku pa laikam saīsinājumus. Tātad, vai tas viss ir vēl viens drīz novecojošs uznāciens?
Esmu dzirdējis programmatūras inženierus, kuri noraida reaktīvās sistēmas kā neko citu kā aizstājēju asinhronām, uz notikumiem balstītām sistēmām, līdzīgi kā daži noraida mikropakalpojumus kā SOA (uz pakalpojumu orientēta arhitektūra), mazāk par ESB (uzņēmuma pakalpojumu kopne). Kaut arī bieži parādās tehnoloģiju jaunvārdi ar atkārtotu nozīmi, reaktīvajās sistēmās es redzu pietiekami daudz atšķirīgu pazīmju, lai domātu, ka nosaukums nav vienkārši cits aizstājvārds.
Kas ir reaktīvās sistēmas?
Reaktīvajā manifestā aprakstītas reaktīvo sistēmu būtiskās īpašības: reaģējošas, elastīgas, elastīgas un ar ziņām saistītas. Tas dod augsta līmeņa attēlu un izklausās mazliet vispārīgi. Jo īpaši manifestā aprakstītā atsaucība, izturība, elastība mūsdienās ir gandrīz standarta prasības daudzām reālās pasaules lietojumprogrammām.
Iespējams, prasība, kas balstīta uz ziņojumu, ir tāda, kas patiesi atšķir reaktīvās sistēmas no citām. Zem pārsega reaktīvā sistēma paļaujas uz mijiedarbību, izmantojot asinhronu ziņu nodošanu, kas nosaka robežas starp atsevišķiem komponentiem. Šāds mijiedarbības modelis palīdz bruģēt ceļu uz brīvu savienošanu gan laika, gan atrašanās vietas ziņā, lai panāktu atbilstību un izplatāmību. Turklāt tas ļauj sistēmai būt integrētai ar kādu nebloķējošu mehānismu, lai regulētu datu plūsmas (vairāk par to tālāk).
Reaktīvās plūsmas
Reaktīvo sistēmu izveidē, šķiet, ir ievērojama pieeja, kurā datu apstrādes darbības, kad vien iespējams, tiek formulētas kā kompozīcijas plūsmas plūsmas. Tā nav daļa no Reaktīvā manifesta prasībām, bet tas varētu būt reaktīvo sistēmu raksturīgais mijiedarbības modelis, kas dabiski atbalsta šādu plūsmas orientētu modelēšanas pieeju.
Acīmredzot reaktīvās plūsmas parādījās kā atsevišķa iniciatīva, tās var uzskatīt par īpašu reaktīvo sistēmu veidu, kas koncentrējas ap straumes apstrādi, kompozīcijas plūsmas izsakot kā virzītus grafikus.
Pretspiediens
Viens no iepriekš minētajiem nebloķējošajiem regulēšanas mehānismiem ir pretspiediens. Tā var būt vispieprasītākā funkcionalitāte sistēmām, kas ievieš reaktīvās plūsmas. Tas ir asinhronais atgriezeniskās saites mehānisms, kas darbojas straumes pretējā virzienā pret augšupējām sastāvdaļām slodzes regulēšanai.
Ar iebūvēto pretspiedienu, kas bloķē plūsmas plūsmas, sistēma spēj darboties ar salīdzinoši stabilāku atmiņas izmantošanu. Šāda funkcionalitāte novērš potenciāli postošas kaudzes pārpildes problēmas (piemēram, ko izraisa lēna datu iegrime), kuras parasti visā strāvas plūsmā būtu jācīnās ar pielāgotu datu buferēšanas mehānismu.
Kā ar reaktīvo programmēšanu?
Kā reaktīvo sistēmu veidošanas programmēšanas paradigma, reaktīvā programmēšana uzsver asinhronās programmēšanas loģikas formulēšanu kā datu plūsmas un korelēto mainīgo lielumu izmaiņu automātisku izplatīšanu sistēmā. Valodas, ko izmanto šādai programmēšanas paradigmai, nodrošinātu piemērotas saliekamās funkcijas, lai darbotos formulētajās straumēs.
Pēc konstrukcijas reaktīvā programmēšana atbalsta funkcionālo programmēšanas stilu, kas izsaka un atrisina skaitļošanas problēmas, izmantojot saliekamās funkcijas. Neskatoties uz to, termina funkcionālā reaktīvā programmēšana esamība ir bijusi pirms šīs reaktīvās "kustības" pirms vairāk nekā desmit gadiem. FRP ir ievērojami atšķirīgs fokuss, un tā koncentrējas uz funkciju izmantošanu, lai paustu uzvedību nepārtrauktā laikā ar vienkāršu denotācijas semantiku. Tomēr tagad to bieži uzskata par reaktīvu programmēšanu, nepārprotami uzsverot funkcionālo programmēšanu.
Ja ilustrācija ar kodu darbojas labāk, es iesaku izlasīt Andrē Stalca pamācību, kurā ir aprakstīta JavaScript reaktīvās programmēšanas būtība, izmantojot RxJS.
ReactiveX
ReactiveX, arī Reactive Extensions, ir API bibliotēka, kas ļauj izmantot kompozīcijas operācijas, lai apstrādātu asinhrono notikumu straumes. Pēc novērotāju modeļa novērojamie un novērotāji (kas ir novērojamo objektu abonenti) ir galvenās bibliotēkas sastāvdaļas ar filtrējamu, pārveidojamu, apkopojamu uc komponentu operatoru kopumu. RxJS un RxJava ir divas no populārākajām ReactiveX attiecīgi JavaScript un Java.
Akka aktieri
Akka ir uz aktieriem balstīta bibliotēka, kas paredzēta mērogojamu vienlaicīgu un izplatītu lietojumprogrammu veidošanai JVM (Java Virtual Machine). Tās pamatā ir skaitļošanas primitīvi, kurus sauc par dalībniekiem, kuri uztur stāvokli un uzvedību un sazinās savā starpā, izmantojot asinhronu ziņojumu nodošanu.
Scala rakstītie Akka aktieri pēc būtības ir viegli un brīvi savienoti. Tas kopā ar Akka spēcīgajām maršrutēšanas, sadalīšanas un krodziņa apakšfunkcijām mērogojamām izplatītām sistēmām, piemēram, IoT, padara tās par lielisku platformu reaktīvu sistēmu veidošanai.
Akka straumes
Reaktīvo plūsmu iniciatīvas līderis (un dibinātājs) ir Akka Streams. Tas ir veidots virs Akka dalībniekiem un nodrošina plašu API komplektu straumju topoloģiju veidošanai un straumju apstrādei ļoti kompozicionālā veidā. Nesenais raktuvju emuāra ziņojums koncentrējas ap Akka straumēm un to, kā to var izmantot, lai veiktu pamata teksta ieguvi.
Acīmredzot Akka straumes kā reaktīva iniciatīva šajās dienās tiecās. Akka-Streams bāzētie draiveri, piemēram, Reactive Rabbit un ReactiveMongo for RabbitMQ un MongoDB, tehnoloģiju nozarē ir sākuši gūt zināmu impulsu. Turklāt Akka HTTP, kas ir Spray REST / HTTP rīkkopas nākamā paaudze, ir veidota tā, lai to varētu iespējot ar Akka straumēm kā tās galveno dzinēju.
Visas plūsmas ir orientētas - kaut kādā veidā
Ar vienmērīgi pieaugošo reaktīvo sistēmu iniciatīvas pieņemšanas momentu tas acīmredzami ir pārspējis vienkārša satraukuma stadiju. Tas acīmredzami ir kas vairāk par asinhronu, uz notikumiem balstītu sistēmu atkārtotu izgudrojumu. No tehnisko nopelnu viedokļa es neredzu iemeslu, kāpēc tas nekļūs pamanāmāks. Neskatoties uz to, pat atvērtā koda tehnoloģiju iniciatīvas ir kā komerciāli produkti - labs laiks var ātri piesaistīt uzmanību sākotnējā posmā, un piemērots mārketings var palīdzēt iegūt nepārtrauktu impulsu, kas nepieciešams, lai popularizētos plašākā lietotāju lokā.
Laika ziņā funkcionāla programmēšana ir pieaugusi, tāpēc es teiktu, ka tas ir lieliski, jo reaktīvo sistēmu veidošanā labvēlīgi tiek izmantots programmēšanas stils. Kas attiecas uz mārketingu, es uzskatu, ka intuitīvāka un atklājāka iniciatīvas nosaukšana labāk pārdotu tehnoloģiju nozarei. Pirmo reizi dzirdot terminu "reaktīvās sistēmas", gandrīz neko nevarēja saprast. Neskatoties uz to, ka termins "reaktīvs" attiecas uz dažiem aspektiem, kas attiecas uz izmaiņu izplatīšanos šādās sistēmās, auditorijai tas neizlec kā paraksta raksturojums.
Tā kā reaktīvās sistēmas, reaktīvās plūsmas un reaktīvā programmēšana galvenokārt ir orientēta ap plūsmām, es domāju, ka termins "straume" ir vairāk atklāsmes atslēgvārds nekā "reaktīvs". Tirgot vispārīgumu ar vienkāršību un intuīciju, es apvienotu reaktīvās sistēmas un reaktīvās plūsmas kā vienu iniciatīvu un aizstātu "reaktīvo" ar kaut ko tādu, kas koncentrējas ap "straumi".
