Këtë vit ne planifikojmë të zhvillojmë seriozisht temat e kontejnerëve, dhe . Një vazhdim logjik i këtyre temave do të jetë diskutimi mbi kornizën Quarkus, e cila është në Habra. Artikulli i sotëm i kushtohet më shumë perspektivave që Quarkus sjell në Enterprise sesa struktures së "Java-së subatomike super të shpejtë".
Java dhe JVM vazhdojnë të jenë jashtëzakonisht të njohura, por gjatë punës me teknologjitë pa server dhe mikroshërbimet e orientuara në re, Java dhe gjuhë të tjera për JVM përdoren gjithnjë e më pak, pasi ato zënë shumë hapësirë në memorje dhe ngarkohen shumë ngadalë, duke i bërë ato të papërshtatshme për përdorim me kontejnerë me jetë të shkurtër. Për fat të mirë, kjo situatë po fillon të ndryshojë falë Quarkus.
Java subatomike super e shpejtë ka arritur një nivel të ri!
42 lëshime, 8 muaj punë nga komuniteti dhe 177 zhvillues të mrekullueshëm – përfundimi i të gjitha këtyre ishte lëshimi në nëntor 2019 , një lëshim që shënon një pikë të rëndësishme në zhvillimin e projektit dhe ofron një gamë të madhe funksionesh dhe mundësish të mrekullueshme (më shumë rreth tyre mund të lexoni në ).
Sot ne do të flasim se si Quarkus bashkon modelet e programimit imperativ dhe reaktiv mbi një bërthamë reaktive të vetme. Do të fillojmë me një shikim të shkurtër në histori dhe pastaj do të shqyrtojmë në detaje se çfarë përbën dualizmi i bërthamës reaktive të Quarkus dhe se si - zhvilluesit mund të shfrytëzojnë këto përfitime.
, dhe -funksionet – të gjitha këto sot, që quhet, janë në rritje. Që nga kohët e fundit, krijimi i arkitekturave të orientuara nga reja është bërë shumë më i thjeshtë dhe i aksesueshëm, megjithatë problemet mbeten - veçanërisht për zhvilluesit e Java. Për shembull, në rastin e funksioneve serverless dhe mikroshërbimeve, ekziston një nevojë e madhe për të reduktuar kohën e nisjes, për të ulur përdorimin e memories dhe për ta bërë zhvillimin e tyre një proces më të rehatshëm dhe të këndshëm. Java, gjatë viteve të fundit, ka sjellë disa përmirësime, si funksionalitetin e përmirësuar për konteinerët dhe të tjerë. Megjithatë, arritja e një funksionimi normal të Java në një konteiner ende mbetet një sfidë. Prandaj, do të fillojmë me shqyrtimin e disa nga vështirësitë e brendshme të Java, të cilat janë veçanërisht të dukshme gjatë zhvillimit të aplikacioneve Java të orientuara nga konteinerët.
Le të flasim fillimisht për historinë.
Të dhënat dhe kontejnerët
Duke filluar nga versioni 8u131, Java ka filluar të mbështesë më shumë kontejnerët falë përmirësimeve në funksionalitetin ergonomik. Në veçanti, tani JVM e di se në sa bërthama procesorësh po ekzekutohet dhe mund të konfigurojë pools e thread-eve në përputhje. Natyrisht, kjo është fantastike, por le të themi se kemi një aplikacion tradicional web që përdor servleta HTTP dhe që ekzekutohet në Tomcat, Jetty etj. Si rezultat, ky aplikacion do t’i japë çdo kërkese një thread të veçantë dhe do ta lejojë atë të bllokojë këtë thread duke pritur operacione I/O, për shembull, gjatë qasjes në DB, skedarë ose shërbime të tjera. Pra, madhësia e një aplikacioni të tillë varet jo nga numri i bërthamave të disponueshme, por nga numri i kërkesave të njëkohshme. Për më tepër, kjo do të thotë se kuotat ose kufizimet në Kubernetes për numrin e bërthamave nuk do të ndihmojnë ndjeshëm, dhe çështja përfundon në ngadalësim.
Shpenzimi i memories
Thread-et janë memorie. Dhe kufizimet e brendshme të memories në konteinerë nuk janë një panacee. Filloni të rritni numrin e aplikacioneve dhe thread-eve, dhe një ditë ose tjetër do të përballeni me një rritje kritike të frekuencës së kalimeve dhe, si pasojë, me degradimin e performancës. Për më tepër, nëse aplikacioni përdor kuadrot tradicionale mikro-shërbimesh ose lidhet me DB, ose angazhon caching, ose ndonjë tjetër metodë që harxhon memory, ju nevojitet një mjet që ju lejon të shihni brenda JVM dhe të shihni se si menaxhon memoria, pa vrarë vetë JVM (p.sh., XX:+UseCGroupMemoryLimitForHeap). Dhe madje përkundër faktit se, duke filluar nga Java 9, JVM ka mësuar të perceptojë cgroups dhe të adoptojë sipas nevojës, rezervimi dhe menaxhimi i memories mbetet një punë mjaft komplekse.
Kuota dhe kufizime
Në Java 11 përfshihet mbështetje për kuotat CPU (si PreferContainerQuotaForCPUCount). Kubernetes gjithashtu ofron mbështetje për kufizimet dhe kuotat. Po, gjithçka ka kuptim, por, nëse aplikacioni përsëri kalon kufirin e ndarë, ne përsëri arrijmë në pikën ku madhësia – ashtu si në rastin e aplikacioneve tradicionale Java – përcaktohet nga numri i bërthamave dhe ndarja e një thread-i për çdo kërkesë, do të thotë se ka pak përfitim nga gjithçka kjo.
Për më tepër, nëse përdoren kuotat dhe kufizimet ose funksionet e shkallëzimit horizontale (scale-out) të platformës pas Kubernetes, problemi nuk zgjidhet automatikisht. Ne thjesht shpenzojmë më shumë burime për të zgjidhur problemin fillestar ose përfundojmë me një mbivendosje burimi. Dhe nëse kjo është një sistem me ngarkesë të lartë në një cloud publik të hapur, pothuajse me siguri fillojmë të përdorim më shumë burime se sa realisht janë të nevojshme.
Dhe çfarë duhet të bëjmë me gjithë këtë?
Nëse flasim thjesht, duhet të përdorim 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ë hyrjes-nxjerrjes jo-bllokuese, një rrjedhë e njëjtë mund të trajtojë disa kërkesa në të njëjtën kohë. Ndërsa një kërkesë pret rezultatet e hyrjes-nxjerrjes, rrjedha që e trajton atë lirohet dhe zajmilihet me një kërkesë tjetër. Kur rezultatet e hyrjes-nxjerrjes përfundojnë, përpunimi i kërkesës së parë vazhdon. Duke alternuar përpunimin e kërkesave brenda së njëjtës rrjedhë, mund të zvogëlojmë numrin e përgjithshëm të rrjedhave dhe të ulim shpenzimet e burimeve për përpunimin e kërkesave.
Me hyrjen-nxjerrjen jo-bllokuese, numri i bërthamave bëhet një parametër kyç, pasi ai përcakton numrin e rrjedhave të hyrjes-nxjerrjes që mund të ekzekutohen paralelisht. Me përdorimin e duhur, kjo lejon shpërndarjen efikase të ngarkesës midis bërthamave dhe përballimin e ngarkesave më të larta me burime më të vogla.
Si, është kjo e gjitha?
Jo, ka ende diçka tjetër. Programimi reaktiv ndihmon në përdorimin më të mirë të burimeve, por gjithashtu ka një çmim të tij. Në veçanti, kodi do të duhet të riprogramohet sipas parimeve të jo-bllokimit dhe të shmanget bllokimi i rrjedhave të hyrjes-nxjerrjes. Dhe kjo është një model krejtësisht tjetër zhvillimi dhe ekzekutimi. Edhe pse ka shumë biblioteka të dobishme këtu, kjo megjithatë është një ndryshim radikal në mënyrën e zakonshme të mendimit.
Së pari, duhet të mësoni të shkruani kod që ekzekutohet asinkronisht. Sapo të filloni të përdorni input-output të papenguar, do t'ju duhet të shkruani qartë se çfarë do të ndodhë kur të merrni një përgjigje për kërkesën tuaj. Thjesht të bllokoni dhe të prisni nuk do të funksionojë më. Në vend të kësaj, mund të kaloni në funksione kthimi, të përdorni programimin reaktiv ose vazhdim. Por kjo nuk është gjithçka: për të përdorur input-output të papenguar, ju nevojiten edhe serverë dhe klientë të papenguar, dhe sa më shumë që të mundeni. Në rastin e HTTP-së, gjithçka është e thjeshtë, por ka gjithashtu edhe DB dhe sisteme skedash, dhe shumë më tepër.
Dhe megjithëse reaktiviteti total ofron maksimumin e efikasitetit, kjo kalim mund të jetë e vështirë për t'u përthithur në praktikë. Prandaj, mundësia për të kombinuar 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 programor;
- Përdorur një kod më të thjeshtë në stil në pjesët e tjera të tij.
Prezantimi i Quarkus
Në thelb, kjo është ajo që përfaqëson Quarkus - të kombinojë modelet reaktive dhe imperative brenda një mjedisi ekzekutiv.
Në themel të Quarkus qëndrojnë Vert.x dhe Netty, mbi të cilat përdoren një sërë frameworkësh dhe zgjerimesh reaktive, të destinuara për të ndihmuar zhvilluesin. Quarkus është projektuar për të ndërtuar jo vetëm mikroshërbime HTTP, por edhe arkitektura të menaxhuara nga ngjarjet. Falë natyrës së tij reaktive, ai punon shumë efektivisht me sistemet e shkëmbimit të mesazheve (Apache Kafka, AMQP etj).
E gjithë hileja qëndron në mënyrën si të përdorni të njëjtin motor reaktiv si për kodin imperativ, ashtu edhe për atë reaktiv.
Quarkus e menaxhon me sukses. Zgjedhja midis programimit imperativ dhe reaktiv është e dukshme – përdorimi i themelit reaktiv për të dyja. Dhe ajo që ndihmon shumë është kodi i shpejtë jo-bllokues, i cili trajton pothuajse gjithçka që kalon përmes ciklit të ngjarjeve (event-loop thread, gjithashtu – IO thread). Por nëse keni aplikacione klasike REST ose aplikacione anësore të klientit, Quarkus ka në dispozicion një model imperativ programimi. Për shembull, mbështetje HTTP në Quarkus ndalon nga përdorimi i motorit të reaktiv dhe jo-bllokues (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ë atë pjesë të kodit që menaxhon kërkesat. Në varësi të destinacionit, kodi i menaxhimit të kërkesave mund të thirret brenda një thread të veçantë (i njohur si worker thread, i përdorur në rastet e servleteve dhe Jax-RS) ose të përdorë thread-in origjinal të hyrjes dhe daljes (rrugë reaktive reactive route).
Për konektorët e sistemeve të transferimit të mesazheve përdoren klientë jo-bllokues që punojnë mbi motorin Vert.x. Prandaj mund ta dërgoni, merrni dhe trajtoni mesazhe në mënyrë efikase nga sistemet e klasës messaging middleware.
Në faqen tonë janë mbledhur disa udhëzime të mira që do t'ju ndihmojnë të filloni punën me Quarkus:
Për më tepër, ne kemi përgatitur mësime praktike online për t'u njohur me aspekte të ndryshme të programimit reaktiv, dhe për t'i ndjekur mjafton vetëm një shfletues, aspak nuk kërkohet IDE, as kompiuter. Mund t'i gjeni këto mësime .
Burime të dobishme
- Faqja e projektit Quarkus është
- Projekti Quarkus në GitHub është
- Twitteri i projektit Quarkus është
- Chat-i i projektit Quarkus është
- Forumet e projektit Quarkus janë !forum/quarkus-dev
10 video-mësime për Quarkus, për tu njohur me temën
Siç shkruhet në faqen e internetit , kanal logjik -një stack Java i orientuar, i optimizuar për GraalVM dhe OpenJDK HotSpot, 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-mësime që trajtojnë aspekte të ndryshme të Quarkus dhe shembuj të përdorimit të tij:
1. Paraqitja e Quarkus: një cadër Java të brezit të ri 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, duke kombinuar modelet reaktive dhe imperative të programimit brenda një mjedisi përfundimtar, që zhvilluesit të kenë mundësi të ndryshojnë fleksibël qasjen duke punuar me një gamë të gjërë arkitekturash të shpërndara të aplikacioneve. Mësoni më shumë nga ligjërata hyrëse më poshtë.
2. Quarkus: Java subatome e super shpejtë
Autor: Burr Sutter
Një video mësimore nga internet-lectoria DevNation Live tregon se si të përdorni Quarkus për optimizimin e aplikacioneve Java, API-ve, mikrosherbimeve dhe funksioneve 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: Shtyjmë Hibernate deri në shpejtësi super dhe e ngjeshim deri në përmasa subatome
Autor: Sanne Grinovero
Nga prezantimi do të mësoni se si u shfaq Quarkus, si funksionon dhe si lejon që biblioteka komplekse, si Hibernate ORM, të jenë të pajtueshme me imazhet native të GraalVM.
4. Të mësojmë të zhvillojmë aplikacione serverless
Autor: Marthen Luther
Në videon më poshtë tregohet se si të krijoni një aplikacion të thjeshtë Java me ndihmën e Quarkus dhe ta çoni atë si një aplikacion serverless në Knative.
5. Quarkus: Kodoni me kënaqësi
Autor: Edson Yanaga
Një udhëzues video për krijimin e projektit tuaj të parë Quarkus, duke e bërë të kuptoni pse Quarkus po fiton zemrat e zhvilluesve.
6. Java dhe kontejnerët – çfarë do të jetë e ardhmja e tyre së bashku
Autor: Mark Little
Ky prezantim paraqet historinë e Java dhe shpjegon pse Quarkus është e ardhmja e Java.
7. Quarkus: Java subatome e super shpejtë
Autor: Dimitris Andreadis
Një përmbledhje e avantazheve të Quarkus që janë njohur nga zhvilluesit: thjeshtësia, shpejtësitë super të larta, bibliotekat më të mira dhe standardet.
8. Quarkus dhe sistemet reaktive subatome
Autor: Clement Escoffier
Me ndihmën e integrimit me GraalVM, Quarkus ofron një përvojë zhvillimi super të shpejtë dhe një mjedis ekzekutiv subatom. Autori flet për anën reaktive të Quarkus dhe se si ta përdorë atë për ndërtimin e aplikacioneve reaktive dhe aplikacioneve me transmetim të të dhënave.
9. Quarkus dhe zhvillimi i shpejtë i aplikacioneve në Eclipse MicroProfile
Autor: John Clingan
Duke bashkë Eclipse MicroProfile dhe Quarkus, zhvilluesit mund të krijojnë aplikacione komplekse të kontejnerizuar MicroProfile që ekzekutojnë brenda disa dhjetra milisekondash. Videon e mbulon në detaje se si të kodoni një aplikacion kontejner MicroProfile për deployment në platformën Kubernetes.
10. Java, versioni "Turbo"
Autori: Markus Biel
Autori tregon se si të përdorni Quarkus për të krijuar kontejnerë Java shumë të vegjël dhe shumë të shpejtë, duke mundësuar një avancim të vërtetë, sidomos në mjediset serverless.
Burimi: habr.com
