{"id":74795,"date":"2020-03-20T20:42:21","date_gmt":"2020-03-20T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie"},"modified":"2020-03-20T20:42:21","modified_gmt":"2020-03-20T17:42:21","slug":"kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","title":{"rendered":"Si Quarkus bashkon programimin imperativ dhe reaktiv","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

K\u00ebt\u00eb vit ne planifikojm\u00eb t\u00eb zhvillojm\u00eb seriozisht temat e kontejnerave, Java Cloud-Native<\/a><\/noindex> dhe Kubernetes<\/a><\/noindex>. Nj\u00eb vazhdim i natyrsh\u00ebm i k\u00ebtyre temave do t\u00eb jet\u00eb diskutimi mbi framework-un Quarkus, tashm\u00eb i shqyrtuar<\/a><\/noindex> n\u00eb Habr. Artikulli i sot\u00ebm i kushtohet jo aq shum\u00eb struktur\u00ebs s\u00eb \"Java-s super-shpejt subatomike\", sa m\u00eb shum\u00eb mund\u00ebsive q\u00eb Quarkus sjell n\u00eb Enterprise.<\/p>\n

\"Si
\n
\nJava dhe JVM vazhdojn\u00eb t\u00eb jen\u00eb jasht\u00ebzakonisht t\u00eb njohura, por kur punoni me teknologjit\u00eb pa server dhe mikroshtyllat e orientuara nga reja, Java dhe gjuh\u00eb t\u00eb tjera p\u00ebr JVM p\u00ebrdoren gjithnj\u00eb e m\u00eb pak, pasi se mbajn\u00eb shum\u00eb hap\u00ebsir\u00eb n\u00eb memorje dhe ngadal\u00eb ngarkohen, duke e b\u00ebr\u00eb t\u00eb pap\u00ebrshtatshme p\u00ebr t'u p\u00ebrdorur me kontejner\u00eb me jet\u00eb t\u00eb shkurt\u00ebr. Fatmir\u00ebsisht, tani kjo situat\u00eb po fillon t\u00eb ndryshoj\u00eb fal\u00eb Quarkus.
\n<\/a><\/noindex><\/p>\n

Java super-shpejt subatomike ka arritur nj\u00eb nivel t\u00eb ri!<\/h3>\n

\n42 l\u00ebshime, 8 muaj pun\u00eb nga komuniteti dhe 177 zhvillues t\u00eb mahnitsh\u00ebm \u2013 si rezultat i gjith\u00eb k\u00ebsaj ishte publikimi n\u00eb n\u00ebntor 2019 Quarkus 1.0<\/a><\/noindex>, nj\u00eb l\u00ebshim q\u00eb simbolizon nj\u00eb ndales\u00eb t\u00eb r\u00ebnd\u00ebsishme n\u00eb zhvillimin e projektit dhe ofron nj\u00eb s\u00ebr\u00eb funksionesh dhe mund\u00ebsish t\u00eb mrekullueshme (m\u00eb shum\u00eb rreth tyre mund t\u00eb lexoni n\u00eb njoftime<\/a><\/noindex>).<\/p>\n

Sot do t\u00eb flasim p\u00ebr m\u00ebnyr\u00ebn se si Quarkus bashkon modelet e programimit imperativ dhe reaktiv mbi nj\u00eb b\u00ebrtham\u00eb reaktive t\u00eb vetme. Do t\u00eb fillojm\u00eb me nj\u00eb p\u00ebrmbledhje t\u00eb shkurt\u00ebr t\u00eb historis\u00eb dhe m\u00eb pas do t\u00eb shqyrtojm\u00eb detajet mbi dualizmin e b\u00ebrtham\u00ebs reaktive t\u00eb Quarkus dhe se si Java<\/a><\/noindex>-zhvilluesit mund t\u00eb shfryt\u00ebzojn\u00eb k\u00ebto avantazhe.<\/p>\n

Mikrosherbimet<\/a><\/noindex>, arkitektur\u00eb e menaxhuar nga ngjarjet<\/a><\/noindex> dhe serverless<\/a><\/noindex>-funksionet \u2013 tudo kjo sot, ashtu si\u00e7 quhet, \u00ebsht\u00eb n\u00eb rritje. Koh\u00ebt e fundit, krijimi i arkitekturave n\u00eb cloud \u00ebsht\u00eb b\u00ebr\u00eb shum\u00eb m\u00eb i leht\u00eb dhe m\u00eb i aksesuesh\u00ebm, megjithat\u00eb problemet mbeten \u2013 ve\u00e7an\u00ebrisht p\u00ebr zhvilluesit e Java. P\u00ebr shembull, n\u00eb rastin e funksioneve serverless dhe mikrosherbimeve, ekziston nj\u00eb nevoj\u00eb urgjente p\u00ebr t\u00eb reduktuar koh\u00ebn e ngarkes\u00ebs, ulur p\u00ebrdorimin e memories dhe ta b\u00ebjm\u00eb zhvillimin e tyre nj\u00eb proces m\u00eb t\u00eb leht\u00eb dhe m\u00eb t\u00eb k\u00ebndsh\u00ebm. Java n\u00eb vitet e fundit ka b\u00ebr\u00eb disa p\u00ebrmir\u00ebsime, si p\u00ebr shembull funksionaliteti ergonomics i p\u00ebrmir\u00ebsuar p\u00ebr kontejner\u00ebt, etj. Megjithat\u00eb, arrijta e nj\u00eb funksionimi normal t\u00eb Java n\u00eb nj\u00eb kontenier vazhdon t\u00eb jet\u00eb nj\u00eb sfid\u00eb. Prandaj, do t\u00eb fillojm\u00eb duke shqyrtuar disa nga kompleksitetet e brendshme t\u00eb Java, t\u00eb cilat shfaqen ve\u00e7an\u00ebrisht acaruese gjat\u00eb zhvillimit t\u00eb aplikacioneve Java t\u00eb orientuara nga kontenier\u00ebt.<\/p>\n

S\u00eb pari, le t\u00eb kthehemi n\u00eb histori.<\/p>\n

\"Si<\/p>\n

T\u00eb drejtat dhe kontejner\u00ebt<\/h3>\n

\nMe nisjen nga versioni 8u131, Java filloi t\u00eb mb\u00ebshtes\u00eb m\u00eb mir\u00eb kontejner\u00ebt me p\u00ebrmir\u00ebsime n\u00eb funksionalitetin ergonomik. N\u00eb ve\u00e7anti, tani JVM e di se n\u00eb sa b\u00ebrthama procesori po ekzekutohet dhe mund t\u00eb konfiguroj\u00eb p\u00ebrkat\u00ebsisht grupet e fijeve \u2014 zakonisht grupet fork\/join. Pa dyshim, kjo \u00ebsht\u00eb e shk\u00eblqyer, por le t\u00eb themi se kemi nj\u00eb aplikacion tradicional n\u00eb web q\u00eb p\u00ebrdor servletet HTTP dhe ekzekutohet n\u00eb Tomcat, Jetty e t\u00eb tjera. Si rezultat, ky aplikacion do t\u00eb jap\u00eb nj\u00eb fije t\u00eb ve\u00e7ant\u00eb p\u00ebr \u00e7do k\u00ebrkes\u00eb dhe do ta lejoj\u00eb at\u00eb t\u00eb bllokoj\u00eb k\u00ebt\u00eb fije gjat\u00eb pritjes p\u00ebr operacione hyr\u00ebse-dal\u00ebse, p\u00ebr shembull, gjat\u00eb aksesimit t\u00eb pajisjeve, skedar\u00ebve ose sh\u00ebrbimeve t\u00eb tjera. Kjo do t\u00eb thot\u00eb se p\u00ebrmasat e nj\u00eb aplikacioni t\u00eb till\u00eb varen jo nga numri i b\u00ebrthamave t\u00eb disponueshme, por nga numri i k\u00ebrkesave paralelisht. P\u00ebr m\u00eb tep\u00ebr, kjo n\u00ebnkupton se kuotat ose kufijt\u00eb n\u00eb Kubernetes p\u00ebr numrin e b\u00ebrthamave k\u00ebtu nuk do t\u00eb ndihmojn\u00eb shum\u00eb, dhe n\u00eb fund ver\u00ebn do p\u00ebrfundoj\u00eb me trojt\u00ebllim.<\/p>\n

Shterimi i memories<\/h3>\n

\nFlukset jan\u00eb kujtes\u00eb. Dhe kufizimet brenda konteiner\u00ebve p\u00ebr kujtes\u00ebn nuk jan\u00eb nj\u00eb zgjidhje e plot\u00eb. Thjesht filloni t\u00eb rritni numrin e aplikacioneve dhe rrjedhave, dhe s\u00eb shpejti do t\u00eb p\u00ebrballeni me nj\u00eb rritje kritike t\u00eb frekuenc\u00ebs s\u00ebnd\u00ebrrimit dhe, si pasoj\u00eb, me degradimin e performanc\u00ebs. P\u00ebr m\u00eb tep\u00ebr, n\u00ebse aplikacioni p\u00ebrdor framework-e tradicionale microservices ose lidhet me BD, ose angazhon caching, ose ndonj\u00eb m\u00ebnyr\u00eb tjet\u00ebr konsumon kujtes\u00eb, ju n\u00eb m\u00ebnyr\u00eb t\u00eb qart\u00eb keni nevoj\u00eb p\u00ebr nj\u00eb mjet q\u00eb lejon t\u00eb shikoni brenda JVM dhe t\u00eb shihni se si menaxhon kujtes\u00ebn, dhe n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb nuk e vrisni vet\u00eb JVM (p.sh., XX:+UseCGroupMemoryLimitForHeap). Edhe pse q\u00eb nga Java 9, JVM ka m\u00ebsuar t\u00eb perceptoj\u00eb cgroups dhe t\u00eb adaptohet p\u00ebrkat\u00ebsisht, ruajtja dhe menaxhimi i kujtes\u00ebs mbetet nj\u00eb detyr\u00eb e komplikuar.<\/p>\n

Kuotat dhe limitet<\/h3>\n

\nN\u00eb Java 11 \u00ebsht\u00eb shtuar mb\u00ebshtetje p\u00ebr CPU quotas (si PreferContainerQuotaForCPUCount). Kubernetes gjithashtu ofron mb\u00ebshtetje p\u00ebr kufizime dhe kuota. Po, gjith\u00e7ka ka kuptim, por n\u00ebse aplikacioni p\u00ebrs\u00ebri kalon kufirin e caktuar, ne p\u00ebrs\u00ebri kthehemi te ajo se sa i madh \u00ebsht\u00eb, si\u00e7 ndodh me aplikacionet tradicionale Java, q\u00eb p\u00ebrcaktohet nga numri i b\u00ebrthamave dhe me alokimin e nj\u00eb threads individual p\u00ebr \u00e7do k\u00ebrkes\u00eb, dometh\u00ebn\u00eb fitimi \u00ebsht\u00eb i vog\u00ebl nga e gjith\u00eb kjo.
\nP\u00ebr m\u00eb tep\u00ebr, n\u00ebse p\u00ebrdoren kuota dhe kufizime ose funksione horizontale (scale-out) t\u00eb platform\u00ebs q\u00eb q\u00ebndron pas Kubernetes, problemi nuk zgjidhet vetiu. Ne thjesht shpenzojm\u00eb m\u00eb shum\u00eb burime p\u00ebr zgjidhjen e problemit fillestar ose p\u00ebrfundojm\u00eb me teprica burimesh. Dhe n\u00ebse \u00ebsht\u00eb nj\u00eb sistem me ngarkes\u00eb t\u00eb lart\u00eb n\u00eb nj\u00eb cloud publik, pothuajse me siguri fillojm\u00eb t\u00eb shpenzojm\u00eb m\u00eb shum\u00eb burime se sa \u00ebsht\u00eb v\u00ebrtet e nevojshme.<\/p>\n

\u00c7far\u00eb mund t\u00eb b\u00ebjm\u00eb me gjith\u00eb k\u00ebt\u00eb?<\/h3>\n

\nN\u00ebse ta themi thjesht, p\u00ebrdorni biblioteka dhe framework-e asinkrone dhe jo-bllokuese si Netty, Vert.x<\/a><\/noindex> ose Akka. Ato jan\u00eb shum\u00eb m\u00eb t\u00eb p\u00ebrshtatshme p\u00ebr pun\u00eb n\u00eb kontejner\u00eb p\u00ebr shkak t\u00eb natyr\u00ebs s\u00eb tyre reaktive. Fal\u00eb input-e\/output-it jo-bllokues, e nj\u00ebjta prurje mund t\u00eb trajtoj\u00eb disa k\u00ebrkesa t\u00eb pap\u00ebrkohshme. Nd\u00ebrsa nj\u00eb k\u00ebrkes\u00eb pret rezultatet e input-e\/output-it, prurja q\u00eb e trajton lirohet dhe merr p\u00ebrsip\u00ebr nj\u00eb k\u00ebrkes\u00eb tjet\u00ebr. Kur rezultatet e input-e\/output-it p\u00ebrfundojn\u00eb, vazhdohet trajtimi i k\u00ebrkes\u00ebs s\u00eb par\u00eb. Duke alternuar trajtimin e k\u00ebrkesave brenda t\u00eb nj\u00ebjtit prurje, mund t\u00eb reduktojm\u00eb numrin e p\u00ebrgjithsh\u00ebm t\u00eb prurjeve dhe t\u00eb ulim konsumin e burimeve p\u00ebr trajtimin e k\u00ebrkesave.<\/p>\n

Me input-e\/output-in jo-bllokues, numri i b\u00ebrthamave b\u00ebhet nj\u00eb paramet\u00ebr ky\u00e7, pasi ai p\u00ebrcakton numrin e prurjeve t\u00eb input-e\/output-it q\u00eb mund t\u00eb ekzekutohen paralelisht. Kur p\u00ebrdoret si\u00e7 duhet, kjo lejon shp\u00ebrndarjen efikase t\u00eb ngarkes\u00ebs midis b\u00ebrthamave dhe trajtimin e ngarkesave m\u00eb t\u00eb larta me m\u00eb pak burime.<\/p>\n

Si, dhe kjo \u00ebsht\u00eb gjith\u00e7ka?<\/h3>\n

\nJo, ka di\u00e7ka tjet\u00ebr. Programimi reaktiv ndihmon n\u00eb shfryt\u00ebzimin m\u00eb t\u00eb mir\u00eb t\u00eb burimeve, por gjithashtu ka nj\u00eb \u00e7mim. Sidomos, kodi do t\u00eb duhet t\u00eb ridizajnohet sipas parimeve t\u00eb pa-bllokueshm\u00ebris\u00eb dhe t\u00eb shmanget bllokimi i rrjedhave t\u00eb input-output. Dhe kjo \u00ebsht\u00eb nj\u00eb model t\u00ebr\u00ebsisht tjet\u00ebr zhvillimi dhe ekzekutimi. Edhe pse ka shum\u00eb biblioteka t\u00eb dobishme k\u00ebtu, prap\u00ebseprap\u00eb, kjo \u00ebsht\u00eb nj\u00eb ndryshim i thell\u00eb n\u00eb m\u00ebnyr\u00ebn e zakonshme t\u00eb t\u00eb menduarit.<\/p>\n

S\u00eb pari, duhet t\u00eb m\u00ebsoni t\u00eb shkruani kod q\u00eb ekzekutohet asinkronisht. Sa her\u00eb q\u00eb filloni t\u00eb p\u00ebrdorni input-output pa bllokim, ju nevojitet t\u00eb sh\u00ebnoni qart\u00eb se \u00e7far\u00eb duhet t\u00eb ndodh\u00eb kur merrni nj\u00eb p\u00ebrgjigje p\u00ebr k\u00ebrkes\u00ebn. Thjesht t\u00eb bllokoni dhe t\u00eb prisni m\u00eb nuk funksionon. N\u00eb vend t\u00eb k\u00ebsaj, mund t\u00eb p\u00ebrdorni thirrje t\u00eb prapa, programim reaktiv ose vazhdim\u00ebsi. Por kjo nuk \u00ebsht\u00eb e gjitha: p\u00ebr t\u00eb p\u00ebrdorur input-output pa bllokim, ju nevojiten gjithashtu server\u00eb dhe klient\u00eb pa bllokim, dhe preferohet t\u00eb jen\u00eb n\u00eb \u00e7do vend. N\u00eb rastin e HTTP-s\u00eb, gjith\u00e7ka \u00ebsht\u00eb e thjesht\u00eb, por ka gjithashtu edhe bazat e t\u00eb dh\u00ebnave, sistemet e skedar\u00ebve dhe shum\u00eb t\u00eb tjera.<\/p>\n

Megjith\u00ebse reaktiviteti total i plot\u00eb jep maksimal efikasitet, nj\u00eb ndryshim i till\u00eb mund t\u00eb jet\u00eb i v\u00ebshtir\u00eb p\u00ebr t'u p\u00ebrpunuar n\u00eb praktik\u00eb. Prandaj, mund\u00ebsia p\u00ebr t\u00eb kombinua kodin reaktiv dhe imperativ b\u00ebhet nj\u00eb kusht i nevojsh\u00ebm p\u00ebr t\u00eb:<\/p>\n

    \n
  1. P\u00ebrdorur efektivisht burimet n\u00eb drejtimet m\u00eb t\u00eb ngarkuara t\u00eb sistemit software;<\/li>\n
  2. P\u00ebrdorur kod m\u00eb t\u00eb thjesht\u00eb n\u00eb stil n\u00eb pjes\u00ebt e tjera t\u00eb tij.<\/li>\n<\/ol>\n

    <\/p>\n

    Prezantojm\u00eb Quarkus<\/h3>\n

    \nN\u00eb thelb, kjo \u00ebsht\u00eb esenca e Quarkus \u2013 t\u00eb bashkoj\u00eb modelet reaktive dhe imperativ n\u00eb nj\u00eb mjedis ekzekutimi.<\/p>\n

    Thelbi i Quarkus \u00ebsht\u00eb Vert.x dhe Netty, mbi t\u00eb cilat p\u00ebrdoret nj\u00eb num\u00ebr i madh skenar\u00ebsh dhe zgjerimesh reaktive p\u00ebr t\u00eb ndihmuar zhvilluesin. Quarkus \u00ebsht\u00eb e destinuar p\u00ebr nd\u00ebrtimin jo vet\u00ebm t\u00eb mikrosh\u00ebrbimeve HTTP, por edhe t\u00eb arkitekturave t\u00eb menaxhuara nga ngjarjet. Fal\u00eb natyr\u00ebs s\u00eb saj reaktive, ajo punon shum\u00eb efektivisht me sistemet e shk\u00ebmbimit t\u00eb mesazheve (Apache Kafka, AMQP, etj).<\/p>\n

    I gjith\u00eb triksht\u00eb \u00ebsht\u00eb se si t\u00eb p\u00ebrdorni t\u00eb nj\u00ebjtin motor reaktiv p\u00ebr kodin imperativ dhe at\u00eb reaktiv.<\/p>\n

    \"Si<\/p>\n

    Quarkus e menaxhon mrekullisht k\u00ebt\u00eb. Zgjedhja midis nj\u00eb modeli imperativ dhe nj\u00eb reaktiv \u00ebsht\u00eb e qart\u00eb \u2013 p\u00ebrdorni t\u00eb dyja me nj\u00eb b\u00ebrtham\u00eb reaktive. Ajo q\u00eb ndihmon shum\u00eb \u00ebsht\u00eb kodimi i shpejt\u00eb dhe jo-bllokues, i cili trajton pothuajse gjith\u00e7ka q\u00eb kalon p\u00ebrmes ciklit t\u00eb ngjarjeve (event-loop thread, i njohur gjithashtu si \u2013 IO thread). Por n\u00ebse keni aplikacione klasike REST ose aplikacione n\u00eb an\u00ebn e klientit, Quarkus ka nj\u00eb model programimi imperativ n\u00eb gatishm\u00ebri. P\u00ebr shembull, mb\u00ebshtetje p\u00ebr HTTP n\u00eb Quarkus nd\u00ebrtimi p\u00ebrfshin p\u00ebrdorimin e nj\u00eb motori jo-bllokues dhe reaktiv (Eclipse Vert.x dhe Netty). T\u00eb gjitha k\u00ebrkesat HTTP q\u00eb merr aplikacioni juaj kalojn\u00eb fillimisht p\u00ebrmes ciklit t\u00eb ngjarjeve (IO Thread), dhe m\u00eb pas d\u00ebrgohen n\u00eb pjes\u00ebn e kodit q\u00eb menaxhon k\u00ebrkesat. N\u00eb p\u00ebrputhje me destinacionin, kodi i menaxhimit t\u00eb k\u00ebrkesave mund t\u00eb thirret brenda nj\u00eb treti t\u00eb ve\u00e7ant\u00eb (i ashtuquajturi worker thread, e p\u00ebrdorur n\u00eb rastet e servleteve dhe Jax-RS) ose t\u00eb p\u00ebrdor\u00eb rrjedh\u00ebn origjinale t\u00eb input-output (riakttiv ruta reactive route).<\/p>\n

    \"Si<\/p>\n

    P\u00ebr lidh\u00ebsit e sistemeve t\u00eb transferimit t\u00eb mesazheve p\u00ebrdoren klient\u00eb jo-bllokues, t\u00eb cil\u00ebt funksionojn\u00eb mbi motorin Vert.x. K\u00ebshtu, ju mund t\u00eb d\u00ebrgoni, merrni dhe procesoni mesazhe nga sisteme t\u00eb klas\u00ebs messaging middleware n\u00eb m\u00ebnyr\u00eb efikase.<\/p>\n

    N\u00eb faqen Quarkus.io<\/a><\/noindex> jan\u00eb mbledhur disa udh\u00ebzime t\u00eb mira p\u00ebr t'ju ndihmuar t\u00eb filloni me Quarkus:<\/p>\n