Jarný webový klient vs. RestTemplate
Práve som oznámil nové Naučte sa jar kurz zameraný na základy jari 5 a Spring Boot 2:
>> SKONTROLUJTE KURZ1. Úvod
V tomto výučbe budeme porovnávať dve implementácie webového klienta Spring - RestTemplate a nová reaktívna alternatíva jari 5 Webový klient.
2. Blokovanie vs. Neblokujúci klient
Vo webových aplikáciách je bežnou požiadavkou uskutočňovať hovory HTTP do iných služieb. Preto potrebujeme nástroj webového klienta.
2.1. RestTemplate Blokovanie klienta
Jar už dlho ponúka RestTemplate ako abstrakcia webového klienta. Pod kapotou, RestTemplate používa API Java Servlet, ktoré je založené na modeli thread-per-request.
To znamená, že vlákno bude blokované, kým webový klient nedostane odpoveď. Problém s blokovacím kódom je spôsobený tým, že každé vlákno spotrebováva určité množstvo pamäte a cyklov CPU.
Uvažujme o tom, že budeme mať veľa prichádzajúcich požiadaviek, ktoré čakajú na nejakú pomalú službu potrebnú na dosiahnutie výsledku.
Požiadavky čakajúce na výsledky sa skôr alebo neskôr nahromadia. Aplikácia následne vytvorí veľa vlákien, ktoré vyčerpajú fond vlákien alebo zaberú všetku dostupnú pamäť. Môžeme tiež zaznamenať zníženie výkonu z dôvodu častého prepínania kontextu (vlákna) procesora.
2.2. Webový klient Neblokujúci klient
Na druhej strane, Webový klient používa asynchrónne, neblokujúce riešenie poskytované rámcom Spring Reactive.
Zatiaľ čo RestTemplate používa vlákno volajúceho pre každú udalosť (volanie HTTP), Webový klient vytvorí pre každú udalosť niečo ako „úlohu“. V zákulisí bude reaktívny rámec radiť tieto „úlohy“ do frontu a vykonávať ich, až keď bude k dispozícii príslušná odpoveď.
Reaktívny rámec využíva architektúru riadenú udalosťami. Poskytuje prostriedky na zostavenie asynchrónnej logiky prostredníctvom rozhrania Reactive Streams API. Výsledkom je, že reaktívny prístup dokáže spracovať viac logiky pri použití menšieho počtu vlákien a systémových prostriedkov v porovnaní s metódou synchronného / blokovania.
Webový klient je súčasťou jarnej knižnice WebFlux. Preto môžeme navyše napísať kód klienta pomocou funkčného a plynulého API s reaktívnymi typmi (Mono a Flux) ako deklaratívne zloženie.
3. Porovnávací príklad
Na demonštráciu rozdielov medzi týmito dvoma prístupmi by sme museli spustiť testy výkonnosti s mnohými súbežnými požiadavkami klientov. Po určitom počte paralelných požiadaviek klientov by sme u blokovacej metódy videli výrazné zníženie výkonu.
Na druhej strane by reaktívna / neblokujúca metóda mala poskytovať neustále výkony bez ohľadu na počet požiadaviek.
Na účely tohto článku poďme implementovať dva koncové body REST, jeden pomocou RestTemplate a druhý pomocou Webový klient. Ich úlohou je zavolať ďalšiu pomalú webovú službu REST, ktorá vráti zoznam tweetov.
Na začiatok budeme potrebovať závislosť štartéra Spring Boot WebFlux:
org.springframework.boot spring-boot-starter-webflux Ďalej je tu náš koncový bod REST pre pomalú službu:
@GetMapping ("/ slow-service-tweets") private List getAllTweets () {Thread.sleep (2000L); // oneskorenie návratu Arrays.asList (nový Tweet ("pravidlá RestTemplate", "@ user1"), nový Tweet ("WebClient je lepší", "@ user2"), nový Tweet ("OK, obe sú užitočné", "@ user1 ")); }3.1. Použitím RestTemplate zavolať pomalú službu
Poďme teraz implementovať ďalší koncový bod REST, ktorý bude volať našu pomalú službu cez webového klienta.
Najskôr použijeme RestTemplate:
@GetMapping ("/ tweets-blocking") public List getTweetsBlocking () {log.info ("Starting BLOCKING Controller!"); final String uri = getSlowServiceUri (); RestTemplate restTemplate = nový RestTemplate (); ResponseEntity response = restTemplate.exchange (uri, HttpMethod.GET, null, new ParameterizedTypeReference() {}); Výsledok zoznamu = response.getBody (); result.forEach (tweet -> log.info (tweet.toString ())); log.info ("Ukončujem blokovanie radiča!"); návratový výsledok; }
Keď hovoríme tento koncový bod, kvôli synchrónnej povahe RestTemplate, kód zablokuje čakanie na odpoveď z našej pomalej služby. Iba po prijatí odpovede sa vykoná zvyšok kódu v tejto metóde. V denníkoch uvidíme:
Spúšťa sa blokovanie radiča! Tweet (text = pravidlá RestTemplate, [chránené e-mailom]) Tweet (text = Webový klient je lepší, [chránený e-mailom]) Tweet (text = OK, obe sú užitočné, [chránené e-mailom]).3.2. Použitím Webový klient zavolať pomalú službu
Po druhé, použijeme Webový klient zavolať na pomalú službu:
@GetMapping (value = "/ tweets-non-blocking", produce = MediaType.TEXT_EVENT_STREAM_VALUE) public Flux getTweetsNonBlocking () {log.info ("Spúšťam NEBLOKOVACÍ radič!"); Flux tweetFlux = WebClient.create () .get () .uri (getSlowServiceUri ()) .retrieve () .bodyToFlux (Tweet.class); tweetFlux.subscribe (tweet -> log.info (tweet.toString ())); log.info ("Ukončuje sa NEBLOKOVACÍ radič!"); spať tweetFlux; }V tomto prípade, Webový klient vracia a Flux vydavateľ a vykonávanie metódy sa dokončí. Keď bude výsledok k dispozícii, vydavateľ začne vydávať tweety svojim predplatiteľom. Upozorňujeme, že to volá klient (v tomto prípade webový prehliadač) / tweety-neblokujúce koncový bod bude tiež prihlásený na odber Flux objekt.
Pozrime sa teraz na protokol:
Spúšťa sa neblokujúci radič! Ukončuje sa neblokujúci ovládač! Tweet (text = pravidlá RestTemplate, [chránené e-mailom]) Tweet (text = Webový klient je lepší, [chránený e-mailom]) Tweet (text = OK, obe sú užitočné, [chránené e-mailom])Upozorňujeme, že táto metóda koncového bodu bola dokončená pred prijatím odpovede.
4. Záver
V tomto článku sme na jar preskúmali dva rôzne spôsoby použitia webových klientov.
RestTemplate používa API Java Servlet, a je preto synchrónne a blokujúce. Naopak, Webový klient je asynchrónny a nebude blokovať vykonávajúce vlákno počas čakania na návrat odpovede. Iba v prípade, že je odpoveď pripravená, sa oznámenie vydá.
RestTemplate sa bude stále používať. V niektorých prípadoch neblokujúci prístup využíva oveľa menej systémových prostriedkov v porovnaní s blokujúcim. Preto v týchto prípadoch Webový klient je výhodnejšia voľba.
Všetky úryvky kódu uvedené v článku nájdete na GitHub.
REST spodok
