Mastering Spring framework 5, 2. daļa: Spring WebFlux

Spring WebFlux iepazīstina ar pavasara ekosistēmu reaktīvu tīmekļa izstrādi. Šis raksts ļaus sākt darbu ar reaktīvajām sistēmām un reaktīvo programmēšanu ar Spring. Vispirms jūs uzzināsiet, kāpēc reaktīvās sistēmas ir svarīgas un kā tās tiek ieviestas Spring Framework 5, pēc tam saņemsiet praktisku ievadu reaktīvo pakalpojumu veidošanai, izmantojot Spring WebFlux. Mēs izveidosim savu pirmo reaktīvo lietojumprogrammu, izmantojot anotācijas. Es arī parādīšu, kā izveidot līdzīgu lietojumprogrammu, izmantojot Spring jaunākās funkcionālās funkcijas.

Pavasara apmācības vietnē JavaWorld

Ja esat jauns pavasara ietvars, iesaku sākt ar kādu no iepriekšējām šīs sērijas apmācībām:

• Kas ir pavasaris? Komponentu bāzes izstrāde Java
• 5. pavasara ietvara apgūšana: pavasara MVC

Reaktīvās sistēmas un pavasara WebFlux

Termiņš reaktīvs šobrīd ir populārs izstrādātāju un IT vadītāju vidū, taču esmu pamanījis zināmu neskaidrību par to, ko tas patiesībā nozīmē. Lai iegūtu skaidrāku informāciju par reaktīvajām sistēmām, ir noderīgi saprast pamatproblēmu, kuru risināšanai tās ir paredzētas. Šajā sadaļā mēs runāsim par reaktīvajām sistēmām kopumā, un es iepazīstināšu ar Reactive Streams API Java lietojumprogrammām.

Mērogojamība pavasara MVC

Pavasara MVC ir nopelnījis vietu starp galvenajām Java tīmekļa lietojumprogrammu un tīmekļa pakalpojumu veidošanas iespējām. Kā mēs atklājām Mastering Spring framework 5, 1. daļā, Spring MVC vienmērīgi integrē anotācijas pavasara lietojumprogrammas stabilajā arhitektūrā. Tas ļauj izstrādātājiem, kuri pārzina Spring, ātri izveidot apmierinošas, ļoti funkcionālas tīmekļa lietojumprogrammas. Mērogojamība tomēr ir izaicinājums pavasara MVC lietojumprogrammām. Tā ir problēma, kuru mēģina risināt pavasara WebFlux.

Bloķējošie vai nebloķējošie tīmekļa ietvari

Tradicionālajās tīmekļa lietojumprogrammās, kad tīmekļa serveris saņem pieprasījumu no klienta, tas pieņem šo pieprasījumu un ievieto to izpildes rindā. Pēc tam pavediens izpildes rindas pavedienu krājumā saņem pieprasījumu, nolasa tā ievades parametrus un ģenerē atbildi. Ja izpildes pavedienam ir jāizsauc bloķēšanas resurss, piemēram, datu bāze, failu sistēma vai cits tīmekļa pakalpojums, šis pavediens izpilda bloķēšanas pieprasījumu un gaida atbildi. Šajā paradigmā pavediens tiek efektīvi bloķēts, līdz ārējais resurss reaģē, kas izraisa veiktspējas problēmas un ierobežo mērogojamību. Lai apkarotu šīs problēmas, izstrādātāji izveido dāsna apjoma pavedienu kopas, lai, kamēr viens pavediens ir bloķēts, cits pavediens varētu turpināt apstrādāt pieprasījumus. 1. attēlā parādīta tradicionālās, bloķējošās tīmekļa lietojumprogrammas izpildes plūsma.

Stīvens Heinss

Nebloķējošie tīmekļa ietvari, piemēram, NodeJS un Play, izmanto citu pieeju. Tā vietā, lai izpildītu bloķēšanas pieprasījumu un gaidītu tā pabeigšanu, viņi izmanto nebloķējošu I / O. Šajā paradigmā lietojumprogramma izpilda pieprasījumu, nodrošina kodu, kas jāizpilda, kad atbilde tiek atgriezta, un pēc tam savu pavedienu atdod serverim. Kad ārējais resurss atgriež atbildi, sniegtais kods tiks izpildīts. Iekšēji nebloķējoši ietvari darbojas, izmantojot notikumu loku. Cilpā lietojumprogrammas kods vai nu nodrošina atzvanīšanu, vai nākotni, kas satur kodu, kas jāizpilda, kad asinhronā cilpa ir pabeigta.

Pēc būtības nav bloķējoši ietvari notikumu vadīts. Tam nepieciešama atšķirīga programmēšanas paradigma un jauna pieeja argumentācijai par to, kā jūsu kods tiks izpildīts. Kad esat to apvijis, reaktīvā programmēšana var novest pie ļoti mērogojamām lietojumprogrammām.

Atzvani, solījumi un nākotne

Pirmajās dienās JavaScript apstrādāja visas asinhronās funkcijas, izmantojot atzvanīšana. Šajā scenārijā, kad notiek notikums (piemēram, kad kļūst pieejama atbilde no pakalpojumu zvana), tiek veikta atzvanīšana. Kaut arī atzvanīšana joprojām ir izplatīta, JavaScript asinhronā funkcionalitāte ir nesen pārvietota uz solījumi. Ar solījumiem funkcijas izsaukums nekavējoties atgriežas, atgriežot solījumu sniegt rezultātus nākotnē. Tā vietā, lai solītu, Java īsteno līdzīgu paradigmu, izmantojot nākotnes līgumi. Šajā lietojumā metode atgriež nākotni, kurai būs kāda vērtība nākotnē.

Reaktīvā programmēšana

Iespējams, esat dzirdējis šo terminu reaktīvā programmēšana kas saistīti ar tīmekļa izstrādes ietvariem un rīkiem, bet ko tas patiesībā nozīmē? Termins, kā mēs to uzzinājām, radies no reaktīvā manifesta, kurā reaktīvās sistēmas definētas kā četras galvenās iezīmes:

1. Reaktīvās sistēmas ir atsaucīgs, kas nozīmē, ka viņi reaģē savlaicīgi, visos iespējamos apstākļos. Viņi koncentrējas uz ātru un konsekventu reakcijas laiku nodrošināšanu, uzticamu augšējo robežu noteikšanu, lai nodrošinātu vienmērīgu pakalpojumu kvalitāti.
2. Reaktīvās sistēmas ir izturīgs, kas nozīmē, ka viņi paliek atsaucīgi, ja rodas neveiksmes. Elastīgums tiek panākts, izmantojot replikācijas, ierobežošanas, izolēšanas un deleģēšanas paņēmienus. Izolējot lietojumprogrammas komponentus viens no otra, jūs varat ierobežot kļūmes un aizsargāt sistēmu kopumā.
3. Reaktīvās sistēmas ir elastīgs, kas nozīmē, ka viņi paliek atsaucīgi, ja mainās slodze. To panāk, elastīgi mērogojot lietojuma komponentus, lai apmierinātu pašreizējo pieprasījumu.
4. Reaktīvās sistēmas ir ar ziņu vadīts, kas nozīmē, ka viņi paļaujas uz asinhrono ziņojumu nodošanu starp komponentiem. Tas ļauj jums izveidot brīvu savienojumu, izolāciju un atrašanās vietas pārredzamību.

2. attēlā parādīts, kā šīs īpašības plūst kopā reaktīvā sistēmā.

Stīvens Heinss

Reaktīvās sistēmas raksturojums

Reaktīvās sistēmas tiek veidotas, izveidojot izolētus komponentus, kas savstarpēji sazinās asinhroni un var ātri mērogot, lai sasniegtu pašreizējo slodzi. Reaktīvās sistēmās komponenti joprojām neizdodas, taču šīs kļūmes rezultātā ir noteiktas darbības, kas visu sistēmu uztur funkcionālu un atsaucīgu.

The Reaktīvs manifests ir abstrakts, bet reaktīvo lietojumu parasti raksturo šādi komponenti vai paņēmieni:

• Datu straumes: A straume ir savlaicīgi sakārtotu notikumu secība, piemēram, lietotāju mijiedarbība, REST pakalpojuma izsaukumi, JMS ziņojumi un rezultāti no datu bāzes.
• Asinhrona: Datu straumes notikumi tiek tverti asinhroni, un jūsu kods nosaka, kā rīkoties, kad notikums tiek izstarots, kad rodas kļūda un kad notikumu straume ir pabeigta.
• Nebloķējošs: Apstrādājot notikumus, kodam nevajadzētu bloķēt un veikt sinhronus zvanus; tā vietā tai jāveic asinhroni zvani un jāatbild, kad šo zvanu rezultāti tiek atgriezti.
• Pretspiediens: Komponenti kontrolē notikumu skaitu un to izlaišanas biežumu. Reaktīvā izteiksmē jūsu komponents tiek saukts par abonents un notikumus izstaro a izdevējs. Tas ir svarīgi, jo abonents kontrolē, cik daudz datu viņš saņem, un tādējādi pats sevi nepārslogos.
• Neveiksmes ziņojumi: Tā vietā, lai komponenti izmestu izņēmumus, kļūdas tiek nosūtītas kā ziņojumi apstrādātāja funkcijai. Tā kā izņēmumu mešana pārtrauc plūsmu, definējot funkciju, lai apstrādātu kļūmes, kad tās notiek, tas nenotiek.

Reactive Streams API

Jauno Reactive Streams API ir izveidojuši inženieri no Netflix, Pivotal, Lightbend, RedHat, Twitter un Oracle. 2015. gadā publicētais Reactive Streams API tagad ir Java 9 sastāvdaļa. Tajā ir definētas četras saskarnes:

• Izdevējs: Izstaro abonentiem notikumu secību.
• Abonents: Saņem un apstrādā izdevēja izstarotos notikumus.
• Abonēšana: Nosaka savstarpēju attiecību starp izdevēju un abonentu.
• Procesors: Pārstāv apstrādes posmu, kurā ietilpst gan abonents, gan izdevējs, un ievēro abu līgumus.

3. attēlā parādīta saikne starp izdevēju, abonentu un abonementu.

Stīvens Heinss

Būtībā abonents izveido izdevēja abonementu un, kad izdevējam ir pieejami dati, tas nosūta abonentam notikumu ar elementu plūsmu. Ņemiet vērā, ka abonents pārvalda pretspiedienu Publisher abonementā.

Tagad, kad jūs zināt mazliet par reaktīvajām sistēmām un Reactive Streams API, pievērsīsim uzmanību rīkiem, kurus Spring izmanto reaktīvo sistēmu ieviešanai: Spring WebFlux un Reactor bibliotēku.

Projekta reaktors

Project Reactor ir trešās puses ietvars, kas balstīts uz Java Reactive Streams specifikāciju un ko izmanto, lai izveidotu nebloķējošas tīmekļa lietojumprogrammas. Project Reactor nodrošina divus izdevējus, kuri tiek intensīvi izmantoti Spring WebFlux:

• Mono: Atgriež 0 vai 1 elementu.
• Flux: Atgriež 0 vai vairāk elementus. Flux var būt bezgalīgs, tas nozīmē, ka tas var neatstāt izstaro elementus uz visiem laikiem, vai arī tas var atgriezt elementu secību un pēc tam nosūtīt pabeigšanas paziņojumu, kad tas ir atgriezis visus elementus.

Mono un plūsmas ir konceptuāli līdzīgas nākotnei, bet jaudīgākas. Izsaucot funkciju, kas atgriež mono vai plūsmu, tā nekavējoties atgriezīsies. Funkciju izsaukuma rezultāti jums tiks piegādāti, izmantojot mono vai plūsmu, kad tie būs pieejami.

Pavasara WebFlux laikā jūs izsauksit reaktīvās bibliotēkas, kas atgriež mono un plūsmas, un jūsu kontrolieri atgriezīs mono un plūsmas. Tā kā tie nekavējoties atgriežas, jūsu kontrolieri efektīvi atteiksies no saviem pavedieniem un ļaus Reactor apstrādāt atbildes asinhroni. Ir svarīgi atzīmēt, ka tikai izmantojot reaktīvas bibliotēkas, jūsu WebFlux pakalpojumi var palikt reaktīvi. Ja izmantojat neaktīvas bibliotēkas, piemēram, JDBC zvanus, pirms atgriešanās kods tiks bloķēts un gaidīs, kamēr šie zvani tiks pabeigti.

Reaktīvā programmēšana ar MongoDB

Pašlaik nav daudz reaktīvu datu bāzu bibliotēku, tāpēc jūs varētu domāt, vai ir praktiski rakstīt reaktīvos pakalpojumus. Labā ziņa ir tā, ka MongoDB ir reaktīvs atbalsts un MySQL un Postgres ir pāris trešo pušu reaktīvo datu bāzu draiveri. Visos pārējos lietošanas gadījumos WebFlux nodrošina mehānismu JDBC izsaukumu izpildei reaktīvā veidā, kaut arī izmantojot sekundāro pavedienu kopu, kas bloķē JDBC zvanus.

Sāciet darbu ar pavasara WebFlux

Pirmajam piemēram mēs izveidosim vienkāršu grāmatu pakalpojumu, kas turpina grāmatas uz MongoDB un no tās reaģēt.

Sāciet, dodoties uz pavasara Initializr mājas lapu, kur izvēlēsieties a Maven projekts ar Java un atlasiet jaunāko Spring Boot laidienu (2.0.3 šī rakstīšanas laikā). Piešķiriet savam projektam grupas nosaukumu, piemēram, “com.javaworld.webflux”, un artefakta nosaukumu, piemēram, “grāmatu serviss”. Izvērsiet Pārslēdzieties uz pilno versiju saite, lai parādītu pilnu atkarību sarakstu. Lietojumprogrammas paraugam atlasiet šādas atkarības:

• Tīmeklis -> Reaktīvais tīmeklis: Šī atkarība ietver pavasara WebFlux.
• NoSQL -> reaktīvs MongoDB: Šī atkarība ietver MongoDB reaktīvos draiverus.
• NoSQL -> iegultais MongoDB: Šī atkarība ļauj mums palaist iegulto MongoDB versiju, tāpēc nav nepieciešams instalēt atsevišķu instanci. Parasti to izmanto testēšanai, taču mēs to iekļausim izlaiduma kodā, lai izvairītos no MongoDB instalēšanas.
• Kodols -> Lomboka: Lombok izmantošana nav obligāta, jo tā nav nepieciešama, lai izveidotu Spring WebFlux lietojumprogrammu. Project Lombok izmantošanas priekšrocība ir tā, ka tas ļauj jums pievienot anotācijas klasēm, kas automātiski ģenerēs skaitītājus un iestatītājus, konstruktorus, hashCode (), vienāds (), un vēl.

Kad esat pabeidzis, jums vajadzētu redzēt kaut ko līdzīgu 4. attēlam.

Stīvens Heinss

Spiešana Ģenerēt projektu aktivizēs ZIP faila lejupielādi, kurā ir jūsu projekta avota kods. Atvienojiet lejupielādēto failu un atveriet to savā iecienītākajā IDE. Ja izmantojat IntelliJ, izvēlieties Fails un tad Atvērt, un dodieties uz direktoriju, kurā lejupielādētais zip fails ir atspiests.

Jūs atradīsit, ka Spring Initializr ir izveidojis divus svarīgus failus:

1. Maven pom.xml fails, kurā ir visas lietojumprogrammai nepieciešamās atkarības.
2. BookserviceApplication.java, kas ir programmas Spring Boot startera klase.

1. saraksts parāda ģenerētā faila pom.xml saturu.