Këtë vit ne planifikojmë të zhvillojmë seriozisht temat e kontejnerave, dhe . Një vazhdim i natyrshëm i këtyre temave do të jetë diskutimi mbi framework-un Quarkus, tashmë në Habr. Artikulli i sotëm i kushtohet jo aq shumë strukturës së "Java-s super-shpejt subatomike", sa më shumë mundësive që Quarkus sjell në Enterprise.
Java dhe JVM vazhdojnë të jenë jashtëzakonisht të njohura, por kur punoni me teknologjitë pa server dhe mikroshtyllat e orientuara nga reja, Java dhe gjuhë të tjera për JVM përdoren gjithnjë e më pak, pasi se mbajnë shumë hapësirë në memorje dhe ngadalë ngarkohen, duke e bërë të papërshtatshme për t'u përdorur me kontejnerë me jetë të shkurtër. Fatmirësisht, tani kjo situatë po fillon të ndryshojë falë Quarkus.
Java super-shpejt subatomike ka arritur një nivel të ri!
42 lëshime, 8 muaj punë nga komuniteti dhe 177 zhvillues të mahnitshëm – si rezultat i gjithë kësaj ishte publikimi në nëntor 2019 , një lëshim që simbolizon një ndalesë të rëndësishme në zhvillimin e projektit dhe ofron një sërë funksionesh dhe mundësish të mrekullueshme (më shumë rreth tyre mund të lexoni në ).
Sot do të flasim për mënyrën se si Quarkus bashkon modelet e programimit imperativ dhe reaktiv mbi një bërthamë reaktive të vetme. Do të fillojmë me një përmbledhje të shkurtër të historisë dhe më pas do të shqyrtojmë detajet mbi dualizmin e bërthamës reaktive të Quarkus dhe se si -zhvilluesit mund të shfrytëzojnë këto avantazhe.
, dhe -funksionet – tudo kjo sot, ashtu siç quhet, është në rritje. Kohët e fundit, krijimi i arkitekturave në cloud është bërë shumë më i lehtë dhe më i aksesueshëm, megjithatë problemet mbeten – veçanërisht për zhvilluesit e Java. Për shembull, në rastin e funksioneve serverless dhe mikrosherbimeve, ekziston një nevojë urgjente për të reduktuar kohën e ngarkesës, ulur përdorimin e memories dhe ta bëjmë zhvillimin e tyre një proces më të lehtë dhe më të këndshëm. Java në vitet e fundit ka bërë disa përmirësime, si për shembull funksionaliteti ergonomics i përmirësuar për kontejnerët, etj. Megjithatë, arrijta e një funksionimi normal të Java në një kontenier vazhdon të jetë një sfidë. Prandaj, do të fillojmë duke shqyrtuar disa nga kompleksitetet e brendshme të Java, të cilat shfaqen veçanërisht acaruese gjatë zhvillimit të aplikacioneve Java të orientuara nga kontenierët.
Së pari, le të kthehemi në histori.
Të drejtat dhe kontejnerët
Me nisjen nga versioni 8u131, Java filloi të mbështesë më mirë kontejnerët me përmirësime në funksionalitetin ergonomik. Në veçanti, tani JVM e di se në sa bërthama procesori po ekzekutohet dhe mund të konfigurojë përkatësisht grupet e fijeve — zakonisht grupet fork/join. Pa dyshim, kjo është e shkëlqyer, por le të themi se kemi një aplikacion tradicional në web që përdor servletet HTTP dhe ekzekutohet në Tomcat, Jetty e të tjera. Si rezultat, ky aplikacion do të japë një fije të veçantë për çdo kërkesë dhe do ta lejojë atë të bllokojë këtë fije gjatë pritjes për operacione hyrëse-dalëse, për shembull, gjatë aksesimit të pajisjeve, skedarëve ose shërbimeve të tjera. Kjo do të thotë se përmasat e një aplikacioni të tillë varen jo nga numri i bërthamave të disponueshme, por nga numri i kërkesave paralelisht. Për më tepër, kjo nënkupton se kuotat ose kufijtë në Kubernetes për numrin e bërthamave këtu nuk do të ndihmojnë shumë, dhe në fund verën do përfundojë me trojtëllim.
Shterimi i memories
Flukset janë kujtesë. Dhe kufizimet brenda konteinerëve për kujtesën nuk janë një zgjidhje e plotë. Thjesht filloni të rritni numrin e aplikacioneve dhe rrjedhave, dhe së shpejti do të përballeni me një rritje kritike të frekuencës sëndërrimit dhe, si pasojë, me degradimin e performancës. Për më tepër, nëse aplikacioni përdor framework-e tradicionale microservices ose lidhet me BD, ose angazhon caching, ose ndonjë mënyrë tjetër konsumon kujtesë, ju në mënyrë të qartë keni nevojë për një mjet që lejon të shikoni brenda JVM dhe të shihni se si menaxhon kujtesën, dhe në të njëjtën kohë nuk e vrisni vetë JVM (p.sh., XX:+UseCGroupMemoryLimitForHeap). Edhe pse që nga Java 9, JVM ka mësuar të perceptojë cgroups dhe të adaptohet përkatësisht, ruajtja dhe menaxhimi i kujtesës mbetet një detyrë e komplikuar.
Kuotat dhe limitet
Në Java 11 është shtuar mbështetje për CPU quotas (si PreferContainerQuotaForCPUCount). Kubernetes gjithashtu ofron mbështetje për kufizime dhe kuota. Po, gjithçka ka kuptim, por nëse aplikacioni përsëri kalon kufirin e caktuar, ne përsëri kthehemi te ajo se sa i madh është, siç ndodh me aplikacionet tradicionale Java, që përcaktohet nga numri i bërthamave dhe me alokimin e një threads individual për çdo kërkesë, domethënë fitimi është i vogël nga e gjithë kjo.
Për më tepër, nëse përdoren kuota dhe kufizime ose funksione horizontale (scale-out) të platformës që qëndron pas Kubernetes, problemi nuk zgjidhet vetiu. Ne thjesht shpenzojmë më shumë burime për zgjidhjen e problemit fillestar ose përfundojmë me teprica burimesh. Dhe nëse është një sistem me ngarkesë të lartë në një cloud publik, pothuajse me siguri fillojmë të shpenzojmë më shumë burime se sa është vërtet e nevojshme.
Çfarë mund të bëjmë me gjithë këtë?
Nëse ta themi thjesht, përdorni biblioteka dhe framework-e asinkrone dhe jo-bllokuese si Netty, ose Akka. Ato janë shumë më të përshtatshme për punë në kontejnerë për shkak të natyrës së tyre reaktive. Falë input-e/output-it jo-bllokues, e njëjta prurje mund të trajtojë disa kërkesa të papërkohshme. Ndërsa një kërkesë pret rezultatet e input-e/output-it, prurja që e trajton lirohet dhe merr përsipër një kërkesë tjetër. Kur rezultatet e input-e/output-it përfundojnë, vazhdohet trajtimi i kërkesës së parë. Duke alternuar trajtimin e kërkesave brenda të njëjtit prurje, mund të reduktojmë numrin e përgjithshëm të prurjeve dhe të ulim konsumin e burimeve për trajtimin e kërkesave.
Me input-e/output-in jo-bllokues, numri i bërthamave bëhet një parametër kyç, pasi ai përcakton numrin e prurjeve të input-e/output-it që mund të ekzekutohen paralelisht. Kur përdoret siç duhet, kjo lejon shpërndarjen efikase të ngarkesës midis bërthamave dhe trajtimin e ngarkesave më të larta me më pak burime.
Si, dhe kjo është gjithçka?
Jo, ka diçka tjetër. Programimi reaktiv ndihmon në shfrytëzimin më të mirë të burimeve, por gjithashtu ka një çmim. Sidomos, kodi do të duhet të ridizajnohet sipas parimeve të pa-bllokueshmërisë dhe të shmanget bllokimi i rrjedhave të input-output. Dhe kjo është një model tërësisht tjetër zhvillimi dhe ekzekutimi. Edhe pse ka shumë biblioteka të dobishme këtu, prapëseprapë, kjo është një ndryshim i thellë në mënyrën e zakonshme të të menduarit.
Së pari, duhet të mësoni të shkruani kod që ekzekutohet asinkronisht. Sa herë që filloni të përdorni input-output pa bllokim, ju nevojitet të shënoni qartë se çfarë duhet të ndodhë kur merrni një përgjigje për kërkesën. Thjesht të bllokoni dhe të prisni më nuk funksionon. Në vend të kësaj, mund të përdorni thirrje të prapa, programim reaktiv ose vazhdimësi. Por kjo nuk është e gjitha: për të përdorur input-output pa bllokim, ju nevojiten gjithashtu serverë dhe klientë pa bllokim, dhe preferohet të jenë në çdo vend. Në rastin e HTTP-së, gjithçka është e thjeshtë, por ka gjithashtu edhe bazat e të dhënave, sistemet e skedarëve dhe shumë të tjera.
Megjithëse reaktiviteti total i plotë jep maksimal efikasitet, një ndryshim i tillë mund të jetë i vështirë për t'u përpunuar në praktikë. Prandaj, mundësia për të kombinua kodin reaktiv dhe imperativ bëhet një kusht i nevojshëm për të:
- Përdorur efektivisht burimet në drejtimet më të ngarkuara të sistemit software;
- Përdorur kod më të thjeshtë në stil në pjesët e tjera të tij.
Prezantojmë Quarkus
Në thelb, kjo është esenca e Quarkus – të bashkojë modelet reaktive dhe imperativ në një mjedis ekzekutimi.
Thelbi i Quarkus është Vert.x dhe Netty, mbi të cilat përdoret një numër i madh skenarësh dhe zgjerimesh reaktive për të ndihmuar zhvilluesin. Quarkus është e destinuar për ndërtimin jo vetëm të mikroshërbimeve HTTP, por edhe të arkitekturave të menaxhuara nga ngjarjet. Falë natyrës së saj reaktive, ajo punon shumë efektivisht me sistemet e shkëmbimit të mesazheve (Apache Kafka, AMQP, etj).
I gjithë trikshtë është se si të përdorni të njëjtin motor reaktiv për kodin imperativ dhe atë reaktiv.
Quarkus e menaxhon mrekullisht këtë. Zgjedhja midis një modeli imperativ dhe një reaktiv është e qartë – përdorni të dyja me një bërthamë reaktive. Ajo që ndihmon shumë është kodimi i shpejtë dhe jo-bllokues, i cili trajton pothuajse gjithçka që kalon përmes ciklit të ngjarjeve (event-loop thread, i njohur gjithashtu si – IO thread). Por nëse keni aplikacione klasike REST ose aplikacione në anën e klientit, Quarkus ka një model programimi imperativ në gatishmëri. Për shembull, mbështetje për HTTP në Quarkus ndërtimi përfshin përdorimin e një motori jo-bllokues dhe reaktiv (Eclipse Vert.x dhe Netty). Të gjitha kërkesat HTTP që merr aplikacioni juaj kalojnë fillimisht përmes ciklit të ngjarjeve (IO Thread), dhe më pas dërgohen në pjesën e kodit që menaxhon kërkesat. Në përputhje me destinacionin, kodi i menaxhimit të kërkesave mund të thirret brenda një treti të veçantë (i ashtuquajturi worker thread, e përdorur në rastet e servleteve dhe Jax-RS) ose të përdorë rrjedhën origjinale të input-output (riakttiv ruta reactive route).
Për lidhësit e sistemeve të transferimit të mesazheve përdoren klientë jo-bllokues, të cilët funksionojnë mbi motorin Vert.x. Kështu, ju mund të dërgoni, merrni dhe procesoni mesazhe nga sisteme të klasës messaging middleware në mënyrë efikase.
Në faqen janë mbledhur disa udhëzime të mira për t'ju ndihmuar të filloni me Quarkus:
Përveç kësaj, ne kemi përgatitur mësime praktike online për të njohur aspekte të ndryshme të programimit reaktiv, dhe për t'i kaluar ato mjafton vetëm një shfletues, nuk kërkohet asnjë IDE për këtë, dhe as një kompjuter nuk është domosdoshmëri. Mund t'i gjeni këto mësime .
Burime të dobishme
- Faqja e projektit Quarkus –
- Projekti Quarkus në GitHub –
- Twitteri i projektit Quarkus –
- Chat-i i projektit Quarkus –
- Forumet e projektit Quarkus – !forum/quarkus-dev
10 video-mësimesh për Quarkus, për t'u njohur me temën
Siç shkruhet në faqen e internetit , është -orientuar Java-stack, i optimizuar për GraalVM dhe OpenJDK HotSpot, dhe i ndërtuar nga bibliotekat dhe standardet më të mira të Java.
Për t'ju ndihmuar të kuptoni temën, ne kemi përzgjedhur 10 video leksione që trajtojnë aspekte të ndryshme të Quarkus dhe shembujt e përdorimit të tij:
1. Prezantimi i Quarkus: një kornizë Java e së ardhmes për Kubernetes
Autorët: Thomas Qvarnstrom dhe Jason Greene
Qëllimi i projektit Quarkus është të krijojë një platformë Java për Kubernetes dhe mjedise serverless, si dhe të kombinojë modelet reaktive dhe imperativ në një ambient të vetëm ekzekutimi, në mënyrë që zhvilluesit të kenë fleksibilitet për të ndryshuar qasjen në punën me një gamë të gjerë të arkitekturave të shpërndara të aplikacioneve. Mësoni më shumë nga ligjërata hyrëse më poshtë.
2. Quarkus: Java subatomike super të shpejtë
Autori: Burr Sutter
Video leksioni nga DevNation Live tregon se si të përdorni Quarkus për të optimizuar aplikacionet e korporatave Java, API-të, mikroshërbimet dhe funksionet serverless në mjedisin Kubernetes/OpenShift, duke i bërë ato shumë më të vogla, më të shpejta dhe më të shkallëzueshme.
3. Quarkus dhe GraalVM: Nxehim Hibernate në shpejtësi super dhe e tkurrim në përmasa subatomike
Autori: Sanne Grinovero
Nga prezantimi do të mësoni se si lindi Quarkus, si funksionon dhe si lejon krijimin e bibliotekave komplekse, si Hibernate ORM, që janë të pajtueshme me imazhet native të GraalVM.
4. Nësojmë të zhvillojmë aplikacione serverless
Autori: Marthën Luter (Marthen Luther)
Në videon më poshtë është treguar se si të krijoni një aplikacion të thjeshtë Java me ndihmën e Quarkus dhe ta shtroni atë si një aplikacion serverless në Knative.
5. Quarkus: kodoni me kënaqësi
Autori: Edson Janaga (Edson Yanaga)
Video udhëzues për krijimin e projektit tuaj të parë Quarkus, që lejon të kuptoni pse Quarkus po fiton zemrat e zhvilluesve.
6. Java dhe kontejnerët – si do të jetë e ardhmja e tyre së bashku
Autori: Mark Litet (Mark Little)
Ky prezantim njofton mbi historinë e Java dhe shpjegon pse Quarkus është e ardhmja e Java.
7. Quarkus: Java subatomike super e shpejtë
Autori: Dimitris Andreadis (Dimitris Andreadis)
Përmbledhja e përfitimeve të Quarkus, që janë pranuar nga zhvilluesit: thjeshtësia, shpejtësitë e larta dhe standardet më të mira.
8. Quarkus dhe sistemet reaktive subatomike
Autori: Klement Eskofier (Clement Escoffier)
Falë integrimit me GraalVM, Quarkus ofron një përvojë zhvillimi jashtëzakonisht të shpejtë dhe një ambient ekzekutiv subatomik. Autori diskuton anën reaktive të Quarkus dhe se si ta përdorim atë për krijimin e aplikacioneve reaktive dhe aplikacioneve me transmetim të të dhënave.
9. Quarkus dhe zhvillimi i shpejtë i aplikacioneve në Eclipse MicroProfile
Autori: John Clingan
Duke kombinuar Eclipse MicroProfile dhe Quarkus, zhvilluesit mund të krijojnë aplikacione të plota kontenjere MicroProfile që nisin brenda disa dhjetëra milisekondash. Videoja shqyrton në detaje se si të kodoni një aplikacion konteiner MicroProfile për shpërndarje në platformën Kubernetes.
10. Java, versioni 'Turbo'
Autori: Marcus Biel
Autori tregon se si të përdorim Quarkus për të krijuar kontejnerë Java super të vegjël dhe super të shpejtë, duke sjellë një vërtetë revolucion, veçanërisht në ambientet serverless.
Burimi: habr.com
