🥇Kuidas Quarkus ühendab imperatiivse ja reaktiivse programmeerimise

Sel aastal plaanime konteineriteemasid tõsiselt arendada, Pilv-native Java и Kubernetes. Nende teemade loogiline jätk on juba lugu Quarkuse raamistikust kaalus Habré kohta. Tänane artikkel räägib vähem "subatomaarse ülikiire Java" disainist ja rohkem lubadusest, mille Quarkus Enterprise'ile annab.

Java ja JVM on endiselt ülipopulaarsed, kuid serverita tehnoloogiate ja pilvepõhiste mikroteenustega töötades kasutatakse Java ja teisi JVM-keeli üha vähem, kuna need võtavad liiga palju mäluruumi ja on liiga aeglased laadimiseks, muutes need sobib halvasti kasutamiseks lühiealiste mahutitega. Õnneks hakkab see olukord nüüd tänu Quarkusele muutuma.

Üliire subatomiline Java on jõudnud uuele tasemele!

42 väljalaset, 8 kuud kogukonnatööd ja 177 hämmastavat arendajat – selle kõige tulemuseks oli väljalase 2019. aasta novembris Kvarkus 1.0, väljalase, mis tähistab projekti arendamisel olulist verstaposti ja pakub palju lahedaid funktsioone ja võimalusi (nende kohta saate rohkem lugeda teadaanne).

Täna näitame teile, kuidas Quarkus ühendab kohustuslikud ja reaktiivsed programmeerimismudelid üheks reaktiivseks tuumaks. Alustame lühikese ajalooga ja seejärel räägime üksikasjalikult, mis on Quarkuse reaktiivne tuumdualism ja kuidas Java- Arendajad saavad neid eeliseid ära kasutada.

Mikroteenused, sündmustest juhitud arhitektuurid и serverita-funktsioonid – kõik see, nagu öeldakse, on tänapäeval tõusuteel. Viimasel ajal on pilvekesksete arhitektuuride loomine muutunud palju lihtsamaks ja ligipääsetavamaks, kuid probleemid püsivad – eriti Java arendajate jaoks. Näiteks serverita funktsioonide ja mikroteenuste puhul on hädasti vaja vähendada käivitusaega, vähendada mälukulu ning muuta nende arendamine siiski mugavamaks ja nauditavamaks. Java on viimastel aastatel teinud mitmeid täiustusi, näiteks parandanud konteinerite ergonoomilist funktsionaalsust ja nii edasi. Java konteineris korralikult tööle panemine on aga endiselt keeruline. Seega alustame Javale omase keerukuse vaatlemisega, mis on konteinerile orienteeritud Java-rakenduste arendamisel eriti terav.

Kõigepealt vaatame ajalugu.

Vood ja konteinerid

Alates versioonist 8u131 hakkas Java ergonoomika funktsionaalsuse täiustamise tõttu enam-vähem konteinereid toetama. Eelkõige teab JVM nüüd, kui paljudel protsessorituumadel see töötab, ja saab vastavalt konfigureerida lõimekogumeid – tavaliselt hargneda/liituda. See on muidugi suurepärane, aga oletame, et meil on traditsiooniline veebirakendus, mis kasutab HTTP servlette ja töötab Tomcatis, Jettys jne. Selle tulemusena annab see rakendus igale päringule eraldi lõime ja lubab sellel lõime blokeerida, oodates I/O toiminguid, näiteks andmebaasi, failide või muude teenuste juurde pääsemisel. See tähendab, et sellise rakenduse suurus ei sõltu saadaolevate tuumade arvust, vaid samaaegsete päringute arvust. Lisaks tähendab see, et Kubernetese tuumade arvu kvoodid või piirangud pole siin eriti abiks ja asi lõppeb lõpuks tõrjumisega.

Mälu ammendumine

Niidid on mälu. Ja konteinerisisesed mälupiirangud pole mingil juhul imerohi. Lihtsalt alustage rakenduste ja lõimede arvu suurendamist ning varem või hiljem kogete lülitussageduse kriitilist tõusu ja selle tulemusena jõudluse halvenemist. Samuti, kui teie rakendus kasutab traditsioonilisi mikroteenuste raamistikke või loob ühenduse andmebaasiga või kasutab vahemällu või kasutab muul viisil mälu, vajate ilmselgelt tööriista, mis võimaldab teil vaadata JVM-i sisse ja näha, kuidas see mälu haldab ilma seda hävitamata. JVM ise (näiteks XX:+UseCGroupMemoryLimitForHeap). Ja kuigi alates Java 9-st on JVM õppinud c-gruppe aktsepteerima ja vastavalt kohanema, on mälu reserveerimine ja haldamine endiselt üsna keeruline küsimus.

Kvoodid ja piirangud

Java 11 tutvustas protsessori kvootide (nagu PreferContainerQuotaForCPUCount) tuge. Kubernetes pakub ka toetust limiitide ja kvootide jaoks. Jah, see kõik on loogiline, kuid kui rakendus ületab taas eraldatud kvoodi, jõuame jälle suuruseni – nagu traditsiooniliste Java-rakenduste puhul –, mis määratakse tuumade arvu järgi ja iga jaoks eraldi lõime eraldamisega. taotlust, siis on sellel kõigel vähe mõtet.
Lisaks ei lahene probleem iseenesest, kui kasutate kvoote ja piiranguid või Kubernetese aluseks oleva platvormi skaleerimisfunktsioone. Me lihtsalt kulutame rohkem ressursse algse probleemi lahendamisele või kulutame lõpuks üle. Ja kui see on suure koormusega süsteem avalikus avalikus pilves, kasutame peaaegu kindlasti rohkem ressursse, kui tegelikult vajame.

Ja mida selle kõigega peale hakata?

Lihtsamalt öeldes kasutage asünkroonseid ja mitteblokeerivaid I/O teeke ja raamistikke, nagu Netty, Vert.x või Akka. Reaktiivse iseloomu tõttu sobivad need palju paremini konteinerites töötamiseks. Tänu mitteblokeerivale I/O-le saab sama lõime töödelda mitut samaaegset päringut. Samal ajal kui üks päring ootab I/O tulemusi, vabastatakse selle lõime töötlemine ja selle võtab üle teine päring. Ja kui I/O tulemused lõpuks saabuvad, jätkub esimese päringu töötlemine. Päringute põimitud töötlemisega samas lõimes saate vähendada lõimede koguarvu ja vähendada päringute töötlemise ressursikulu.

Mitteblokeeriva I/O puhul muutub tuumade arv võtmeparameetriks, kuna see määrab paralleelselt teostatavate I/O lõimede arvu. Õige kasutamise korral võimaldab see tõhusalt jaotada koormust tuumade vahel ja toime tulla suurema töökoormusega väiksemate ressurssidega.

Kuidas, kas see on kõik?

Ei, seal on midagi muud. Reaktiivne programmeerimine aitab ressursse paremini kasutada, kuid sellel on ka oma hind. Eelkõige tuleb kood ümber kirjutada vastavalt mitteblokeerimise põhimõtetele ja vältida I/O lõimede blokeerimist. Ja see on täiesti erinev arendus- ja teostusmudel. Ja kuigi kasulikke raamatukogusid on siin palju, on see siiski harjumuspärase mõtteviisi radikaalne muutus.

Esiteks peate õppima, kuidas kirjutada asünkroonselt töötavat koodi. Kui hakkate kasutama mitteblokeerivat I/O-d, peate selgelt määrama, mis peaks juhtuma, kui päringule vastus saabub. Lihtsalt blokeerimine ja ootamine ei toimi enam. Selle asemel saate edastada tagasihelistusi, kasutada reaktiivset programmeerimist või jätkamist. Kuid see pole veel kõik: mitteblokeeriva I/O kasutamiseks on vaja nii mitteblokeerivaid servereid kui ka kliente, eelistatavalt kõikjal. HTTP puhul on kõik lihtne, kuid on ka andmebaase, failisüsteeme ja palju muud.

Ja kuigi täielik otsast lõpuni reaktiivsus maksimeerib tõhusust, võib sellist nihet praktikas olla raske mõista. Seetõttu muutub reaktiivse ja imperatiivse koodi kombineerimise võimalus eelduseks, et:

Kasutage tõhusalt ressursse tarkvarasüsteemi kõige koormatud piirkondades;
Kasutage ülejäänud osades lihtsamat stiilikoodi.

Tutvustame Quarkust

Tegelikult on see Quarkuse olemus – ühendada reaktiivsed ja kohustuslikud mudelid ühes käituskeskkonnas.

Quarkus põhineb Vert.x-l ja Nettyl, mille peal on arendaja abistamiseks rida reaktiivseid raamistikke ja laiendusi. Quarkus on mõeldud mitte ainult HTTP mikroteenuste, vaid ka sündmustepõhise arhitektuuri loomiseks. Tänu oma reaktiivsele olemusele töötab see väga tõhusalt sõnumsidesüsteemidega (Apache Kafka, AMQP jne).

Trikk seisneb selles, kuidas kasutada sama reaktiivset mootorit nii kohustusliku kui ka reaktiivse koodi jaoks.

Quarkus teeb seda suurepäraselt. Valik imperatiivse ja reaktiivse vahel on ilmne – kasutage mõlema jaoks reaktiivset tuuma. See aitab tegelikult kiiret, mitteblokeerivat koodi, mis käsitleb peaaegu kõike, mis läbib sündmusetsükli lõime ehk IO lõime. Kuid kui teil on klassikalised REST- või kliendipoolsed rakendused, on Quarkusel valmis programmeerimismudel. Näiteks HTTP tugi Quarkuses põhineb mitteblokeeriva ja reaktiivse mootori (Eclipse Vert.x ja Netty) kasutamisel. Kõik teie rakenduse poolt vastuvõetud HTTP-päringud juhitakse esmalt läbi sündmusetsükli (IO Thread) ja saadetakse seejärel päringuid haldavasse koodiossa. Olenevalt sihtkohast saab päringuhalduskoodi kutsuda eraldi lõime (nn töölõime, mida kasutatakse servletite ja Jax-RS-i puhul) või kasutada lähteteksti I/O lõime (reaktiivne marsruut).

Sõnumsidesüsteemi konnektorid kasutavad mitteblokeerivaid kliente, mis töötavad Vert.x mootori peal. Seetõttu saate tõhusalt saata, vastu võtta ja töödelda sõnumeid sõnumside vahevarasüsteemidest.

Site Quarkus.io Siin on mõned head õpetused, mis aitavad teil Quarkuse kasutamist alustada:

Oleme loonud ka veebipõhiseid praktilisi õpetusi, et õpetada teile reaktiivse programmeerimise erinevaid aspekte ainult brauseris, IDE pole vaja ega arvutit. Need õppetunnid leiate siin.

Kasulikud ressursid

4 põhjust Quarkuse proovimiseks
Quarkuse projekti veebisait – quarkus.io
Quarkuse projekt GitHubis – github.com/quarkusio/quarkus
Quarkuse projekt Twitter – twitter.com/QuarkusIO
Quarkuse projekti vestlus – quarkusio.zulipchat.com
Quarkuse projekti foorumid – groups.google.com/forum/#!forum/quarkus-dev

10 videotundi Quarkuse kohta teemaga tutvumiseks

Nagu kodulehel öeldakse Quarkus.io, Kvarkus - Kas Kubernetes- orienteeritud Java pinu, mis on kohandatud GraalVM-i ja OpenJDK HotSpoti jaoks ning mis on kokku pandud parimatest Java raamatukogudest ja standarditest.

Teema mõistmiseks oleme valinud 10 videoõpetust, mis hõlmavad Quarkuse erinevaid aspekte ja näiteid selle kasutamisest:

1. Quarkuse tutvustamine: Kubernetese järgmise põlvkonna Java raamistik

Thomas Qvarnstrom ja Jason Greene
Quarkuse projekti eesmärk on luua Java platvorm Kubernetese ja serverivabade keskkondade jaoks ning ühendada reaktiivsed ja imperatiivsed programmeerimismudelid üheks käituskeskkonnaks, et arendajad saaksid oma lähenemisviisi paindlikult varieerida, töötades laia valiku hajutatud rakendusarhitektuuridega. Uuri lähemalt allolevast sissejuhatavast loengust.

2. Kvarkus: ülikiire subatomaarne Java

Autor: Burr Sutter
See DevNation Live'i videoõpetus näitab, kuidas Quarkust kasutada ettevõtte Java-rakenduste, API-de, mikroteenuste ja serverivabade funktsioonide optimeerimiseks Kubernetes/OpenShift keskkonnas, muutes need palju väiksemaks, kiiremaks ja skaleeritavamaks.

3. Quarkus ja GraalVM: talveunerežiimi kiirendamine ülikiireks ja selle kahandamine subatomaarsete suurusteni

Autor: Sanne Grinovero
Esitlusest saate teada, kuidas Quarkus tekkis, kuidas see töötab ja kuidas see võimaldab teil luua keerukaid teeke, nagu näiteks Hibernate ORM, ühilduma GraalVM-i loomulike piltidega.

4. Õppige arendama serverita rakendusi

Autor: Martin Luther
Allolev video näitab, kuidas luua Quarkuse abil lihtne Java-rakendus ja juurutada see Knative'is serverita rakendusena.

5. Quarkus: nautige kodeerimist

Autor: Edson Yanaga
Videojuhend oma esimese Quarkuse projekti loomiseks, mis võimaldab teil mõista, miks Quarkus arendajate südameid võidab.

6. Java ja konteinerid – milline saab olema nende ühine tulevik

Postitas Mark Little
See esitlus tutvustab Java ajalugu ja selgitab, miks Quarkus on Java tulevik.

7. Kvarkus: ülikiire subatomaarne Java

Autor: Dimitris Andreadis
Ülevaade arendajate tunnustuse pälvinud Quarkuse eelistest: lihtsus, ülisuured kiirused, parimad raamatukogud ja standardid.

8. Kvarkud ja subatomaarsed raketisüsteemid

Autor: Clement Escoffier
Tänu GraalVM-iga integreerimisele pakub Quarkus ülikiire arenduskogemuse ja subatomaarse käituskeskkonna. Autor räägib Quarkuse reaktiivsest poolest ja sellest, kuidas seda kasutada reaktiivsete ja voogedastusrakenduste ehitamiseks.

9. Quarkus ja kiire rakenduste arendamine Eclipse MicroProfile'is

Autor: John Clingan
Kombineerides Eclipse MicroProfile'i ja Quarkuse, saavad arendajad luua täisfunktsionaalsusega konteineris MicroProfile'i rakendusi, mis käivituvad kümnete millisekunditega. Video kirjeldab üksikasjalikult, kuidas kodeerida konteineris MicroProfile'i rakendust Kubernetese platvormil juurutamiseks.

10. Java, "Turbo" versioon

Autor: Marcus Biel
Autor näitab, kuidas Quarkuse abil luua üliväikesi ülikiireid Java konteinereid, mis võimaldavad tõelisi läbimurdeid, eriti serverita keskkondades.

Allikas: www.habr.com