streamalism.org

Most jelentettem be az újat Tanulj tavaszt tanfolyam, amelynek középpontjában az 5. tavasz és a tavaszi bakancs 2 alapjai állnak:

1. Bemutatkozás

Ebben az oktatóanyagban összehasonlítani fogjuk a Spring két webes kliens megvalósítását - RestTemplate és az új 5. tavasz reaktív alternatívája Web Ügyfél.

2. Blokkoló és nem blokkoló kliens

A webalkalmazásokban általános követelmény, hogy HTTP-hívásokat indítsanak más szolgáltatásokkal. Ezért szükségünk van egy webes kliens eszközre.

2.1. RestTemplate Blokkoló kliens

A Tavasz hosszú ideje kínál RestTemplate mint webes kliens absztrakció. A motorháztető alatt, RestTemplate a Java Servlet API-t használja, amely a kérésenként szálon alapuló modellen alapul.

Ez azt jelenti, hogy a szál addig blokkol, amíg a webes ügyfél meg nem kapja a választ. A blokkoló kóddal kapcsolatos probléma abból adódik, hogy minden szál bizonyos mennyiségű memóriát és CPU-ciklust fogyaszt.

Vegyük fontolóra sok beérkező kérés beérkezését, amelyek az eredmény előállításához szükséges lassú szolgáltatásra várnak.

Előbb vagy utóbb az eredményekre váró kérelmek felhalmozódnak. Következésképpen az alkalmazás sok szálat hoz létre, amelyek kimerítik a szálkészletet, vagy elfoglalják az összes rendelkezésre álló memóriát. A teljesítmény romlását tapasztalhatjuk a CPU gyakori (szál) váltása miatt is.

2.2. Web Ügyfél Nem blokkoló kliens

A másik oldalon, Web Ügyfél aszinkron, nem blokkoló megoldást használ, amelyet a Spring Reactive keretrendszer biztosít.

Míg RestTemplate a hívó szálat használja minden eseményhez (HTTP hívás), Web Ügyfél valami hasonló feladatot hoz létre minden eseményhez. A színfalak mögött a Reactive keretrendszer sorba állítja ezeket a „feladatokat”, és csak akkor hajtja végre őket, ha a megfelelő válasz rendelkezésre áll.

A reaktív keretrendszer eseményvezérelt architektúrát használ. Ez biztosítja az aszinkron logika összeállításának módját a Reactive Streams API-n keresztül. Ennek eredményeként a reaktív megközelítés több logikát képes feldolgozni, miközben kevesebb szálat és rendszererőforrást használ, összehasonlítva a szinkron / blokkoló módszerrel.

Web Ügyfél a Spring WebFlux könyvtár része. Ebből kifolyólag, emellett kliens kódot is írhatunk egy funkcionális, folyékony, reaktív típusú (Monó és Fényáram) mint deklaratív összetétel.

3. Összehasonlító példa

E két megközelítés közötti különbségek bemutatásához teljesítményteszteket kell lefuttatnunk, sok egyidejű ügyfélkéréssel. Jelentős teljesítményromlást tapasztalhatunk a blokkolási módszerrel bizonyos számú párhuzamos ügyfélkérés után.

A másik oldalon a reaktív / nem blokkoló módszernek állandó teljesítményt kell nyújtania, függetlenül a kérések számától.

E cikk alkalmazásában: valósítsunk meg két REST végpontot, egyet használva RestTemplate a másik pedig Web Ügyfél. Feladatuk egy másik lassú REST webszolgáltatás felhívása, amely visszaadja a tweetek listáját.

Először szükségünk lesz a Spring Boot WebFlux indítófüggőségre:

 org.springframework.boot spring-boot-starter-webflux 

Továbbá, itt van a lassú szolgáltatást nyújtó REST végpontunk:

@GetMapping ("/ slow-service-tweets") privát lista getAllTweets () {Thread.sleep (2000L); // delay return Arrays.asList (új Tweet ("RestTemplate szabályok", "@ user1"), új Tweet ("a WebClient jobb", "@ user2"), új Tweet ("OK, mindkettő hasznos", "@ felhasználó1 ")); }

3.1. Használata RestTemplate hogy hívjon lassú szolgáltatást

Vezessünk be egy másik REST végpontot, amely a webes kliensen keresztül hívja lassú szolgáltatásunkat.

Először is használni fogjuk RestTemplate:

@GetMapping ("/ tweets-blocking") public list getTweetsBlocking () {log.info ("A blokkoló vezérlő indítása!"); végső karakterlánc uri = getSlowServiceUri (); RestTemplate restTemplate = új RestTemplate (); ResponseEntity response = restTemplate.exchange (uri, HttpMethod.GET, null, új ParameterizedTypeReference() {}); Lista eredménye = response.getBody (); result.forEach (tweet -> log.info (tweet.toString ())); log.info ("Kilépés a blokkoló vezérlőből!"); visszatérési eredmény; }

Amikor ezt a végpontot hívjuk, a szinkron jellege miatt RestTemplate, a kód blokkolja a lassú szolgáltatásunk válaszának megvárását. Csak akkor, amikor a válasz megérkezett, a metódus többi része végrehajtásra kerül. A naplókban látni fogjuk:

A vezérlő blokkolásának elindítása! Tweet (szöveg = RestTemplate szabályok, [e-mail védett]) Tweet (szöveg = jobb a Webkliens, [e-mail védett]) Tweet (text = OK, mindkettő hasznos, [e-mail védett]) Kilépés a BLOCKING Controllerből!

3.2. Használata Web Ügyfél hogy hívjon lassú szolgáltatást

Másodszor, használjuk Web Ügyfél hívja a lassú szolgáltatást:

@GetMapping (value = "/ tweet-non-blocking", = MediaType.TEXT_EVENT_STREAM_VALUE) public Flux getTweetsNonBlocking () {log.info ("NON-BLOCKING Controller indítása!"); Flux tweetFlux = WebClient.create () .get () .uri (getSlowServiceUri ()) .retrieve () .bodyToFlux (Tweet.class); tweetFlux.subscribe (tweet -> log.info (tweet.toString ())); log.info ("Kilépés a nem blokkoló vezérlőből!"); return tweetFlux; }

Ebben az esetben, Web Ügyfél visszatér a Fényáram kiadó és a metódus végrehajtása befejeződik. Amint az eredmény elérhető, a kiadó tweeteket küld az előfizetőinek. Ne feledje, hogy egy ügyfél (ebben az esetben egy webböngésző) hívja ezt / tweetek-nem blokkoló végpont is feliratkozik a visszaküldöttre Fényáram tárgy.

Ezúttal figyeljük meg a naplót:

A nem blokkoló vezérlő elindítása! Kilépés a nem blokkoló vezérlőből! Tweet (szöveg = RestTemplate szabályok, [e-mail védett]) Tweet (szöveg = jobb a WebClient, [e-mail védett])

Vegye figyelembe, hogy ez a végpont-módszer a válasz fogadása előtt fejeződött be.

4. Következtetés

Ebben a cikkben két különböző módszert tártunk fel a webes ügyfelek tavasszal történő használatára.

RestTemplate Java Servlet API-t használ, ezért szinkron és blokkoló. Ezzel ellentétben Web Ügyfél aszinkron, és nem fogja blokkolni a végrehajtó szálat, amíg a válasz visszatérésére vár. Csak akkor készül el az értesítés, ha a válasz készen áll.

RestTemplate továbbra is használni fogják. Bizonyos esetekben a nem blokkoló megközelítés sokkal kevesebb rendszererőforrást használ fel, mint a blokkoló. Ezért ezekben az esetekben Web Ügyfél előnyösebb választás.

A cikkben említett összes kódrészlet megtalálható a GitHubon.

Most jelentettem be az újat Tanulj tavaszt tanfolyam, amelynek középpontjában az 5. tavasz és a tavaszi bakancs 2 alapjai állnak: