{"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\/hr\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","title":{"rendered":"Kako Quarkus spaja imperativno i reaktivno programiranje","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ove godine planiramo ozbiljno razvijati teme kontejnera, Cloud-Native Java<\/a><\/noindex> i Kubernetes<\/a><\/noindex>. Logi\u010dno nastavak ovih tema bit \u0107e razgovor o frameworku Quarkus, ve\u0107 razmatranom<\/a><\/noindex> na Habr\u00e9. Dana\u0161nja prilog posve\u0107en je ne toliko ure\u0111aju \"subatomske super brze Java\", koliko perspektivama koje Quarkus donosi u Enterprise.<\/p>\n

\"Kako
\n
\nJava i JVM su i dalje izuzetno popularni, ali prilikom rada s serverless tehnologijama i obla\u010dno orijentiranim mikroslu\u017ebama, Java i drugi jezici za JVM se sve re\u0111e koriste, jer zauzimaju previ\u0161e memorije i sporo se u\u010ditavaju, zbog \u010dega slabo odgovaraju za kori\u0161tenje s kratkotrajim kontejnerima. Na sre\u0107u, ova situacija se trenutno po\u010dinje mijenjati zahvaljuju\u0107i Quarkus.
\n<\/a><\/noindex><\/p>\n

Super brza subatomska Java je dostigla novu razinu!<\/h3>\n

\n42 izdanja, 8 mjeseci rada zajednice i 177 nevjerojatnih developera \u2013 rezultat svega ovoga bio je izlazak u novembru 2019. godine Quarkus 1.0<\/a><\/noindex>, izdanja koje ozna\u010dava va\u017enu prekretnicu u razvoju projekta i nudi brojne sjajne funkcije i mogu\u0107nosti (vi\u0161e o njima mo\u017eete pro\u010ditati u najavi<\/a><\/noindex>).<\/p>\n

Danas \u0107emo pri\u010dati kako Quarkus spaja modele imperativnog i reaktivnog programiranja na osnovi jedinstvenog reaktivnog jezgra. Po\u010det \u0107emo s kratkim uvodom u povijest, a zatim \u0107emo detaljno razraditi u \u010demu se sastoji dualnost reaktivnog jezgra Quarkus i kako Java<\/a><\/noindex>-programeri mogu iskoristiti ove prednosti.<\/p>\n

Mikroslu\u017ebe<\/a><\/noindex>, arhitekture vo\u0111ene doga\u0111ajima<\/a><\/noindex> i serverless<\/a><\/noindex>-funkcije \u2013 sve to danas, \u0161to se mo\u017ee re\u0107i, na vrhuncu je. U posljednje vrijeme kreiranje obla\u010dno orijentiranih arhitektura postalo je mnogo jednostavnije i pristupa\u010dnije, me\u0111utim problemi su ostali \u2013 posebno za Java developere. Na primjer, u slu\u010daju serverless funkcija i mikroslu\u017ebi postoji hitna potreba za smanjenjem vremena pokretanja, smanjenjem potro\u0161nje memorije i u\u010diniti njihov razvoj ugodnijim i jednostavnijim. Java je u posljednjih nekoliko godina unijela nekoliko pobolj\u0161anja, poput doradnog funkcionalnog ergonomske podr\u0161ke za kontejnere i sli\u010dno. Me\u0111utim, postizanje normalnog rada Java u kontejneru jo\u0161 uvijek je izazovno. Stoga \u0107emo po\u010deti razmatrati neke od unutarnjih slo\u017eenosti Jave, koje se posebno isti\u010du prilikom razvoja kontejnerski orijentiranih Java aplikacija.<\/p>\n

Za po\u010detak, obratimo se povijesti.<\/p>\n

\"Kako<\/p>\n

Tokovi i kontejneri<\/h3>\n

\nPo\u010dev\u0161i od verzije 8u131, Java je postala prili\u010dno podr\u017eavati kontejnere zahvaljuju\u0107i pobolj\u0161anjima u funkcionalnosti ergonomije. Naime, sada JVM zna na koliko se procesorskih jezgri pokre\u0107e i mo\u017ee odgovaraju\u0107e prilagoditi bazene tokova \u2013 obi\u010dno fork\/join bazene. Naravno, to je odli\u010dno, ali recimo da imamo tradicionalnu web aplikaciju koja koristi HTTP servlete i pokre\u0107e se u Tomcat, Jetty i sli\u010dnim okru\u017eenjima. Kao rezultat toga, ova aplikacija \u0107e svakoj zahtjevini dodijeliti zasebni tok i omogu\u0107iti mu da blokira taj tok dok \u010deka ulazno-izlazne operacije, primjerice, prilikom pristupa bazi podataka, datotekama ili ostalim servisima. Drugim rije\u010dima, veli\u010dina takve aplikacije ne ovisi o broju dostupnih jezgri, ve\u0107 o broju istodobnih zahtjeva. Osim toga, to zna\u010di da kvote ili ograni\u010denja u Kubernetesu po broju jezgri ovdje nisu od velike pomo\u0107i, i na kraju \u0107e se sve svesti na throttling.<\/p>\n

Iscrpljivanje memorije<\/h3>\n

\nTokovi su memorija. I unutarkontejnerska ograni\u010denja memorije nisu lijek za sve. Jednostavno po\u010dnite pove\u0107avati broj aplikacija i tokova, i prije ili kasnije suo\u010dit \u0107ete se s kriti\u010dnim rastom u\u010destalosti promjena i, kao posljedica, s degradacijom performansi. Nadalje, ako aplikacija koristi tradicionalne mikroservisne okvire ili se povezuje s bazom podataka, ili koristi ke\u0161iranje, ili na neki na\u010din dodatno tro\u0161i memoriju, o\u010dito vam je potreban alat koji omogu\u0107uje da zavirite unutar JVM-a i vidite kako upravlja memorijom, a da pritom ne ubijete samu JVM (npr. XX:+UseCGroupMemoryLimitForHeap). I \u010dak iako je, po\u010dev\u0161i s Javom 9, JVM nau\u010dila prepoznavati cgroups i odgovaraju\u0107e se prilago\u0111avati, rezervacija i upravljanje memorijom ostaje prili\u010dno slo\u017een zadatak.<\/p>\n

Kvote i ograni\u010denja<\/h3>\n

\nU Javi 11 uvedena je podr\u0161ka za CPU kvote (poput PreferContainerQuotaForCPUCount). Kubernetes tako\u0111er nudi podr\u0161ku za ograni\u010denja i kvote. Da, sve to ima smisla, ali ako aplikacija opet prema\u0161i dodijeljenu kvotu, ponovno dolazimo do toga da veli\u010dinu \u2013 kao u slu\u010daju tradicionalnih Java aplikacija \u2013 odre\u0111uje broj jezgri uz dodjeljivanje zasebnog toka za svaki zahtjev, dakle, koristi od svega toga su ograni\u010dene.
\nOsim toga, kori\u0161tenje kvota i limita ili funkcija horizontalnog (scale-out) skaliranja platforme koja temelji Kubernetes ne rje\u0161ava problem samo od sebe. Tako samo tro\u0161imo vi\u0161e resursa na rje\u0161avanje osnovnog problema ili na kraju zavr\u0161avamo s prekomjernom potro\u0161njom resursa. A ako je to visoko optere\u0107en sustav u javnom oblaku, gotovo sigurno po\u010dinjemo tro\u0161iti vi\u0161e resursa nego \u0161to je stvarno potrebno.<\/p>\n

\u0160to u\u010diniti sa svime tim?<\/h3>\n

\nAko ka\u017eemo jednostavno, treba koristiti asinkrone i neblokiraju\u0107e biblioteke ulaza\/izlaza i okvire poput Netyja, Vert.x<\/a><\/noindex> ili Akka. Oni su mnogo bolje prilago\u0111eni radu u kontejnerima zbog svoje reaktivne prirode. Zahvaljuju\u0107i neblokiraju\u0107em ulazu\/izlazu, ista nit mo\u017ee obra\u0111ivati vi\u0161e istovremenih zahtjeva. Dok jedan zahtjev \u010deka rezultate ulaza\/izlaza, nit koja ga obra\u0111uje se osloba\u0111a i preuzima drugi zahtjev. A kada rezultati ulaza\/izlaza napokon stignu, obrada prvog zahtjeva se nastavlja. Naizmjeni\u010dnim obra\u0111ivanjem zahtjeva unutar iste niti, mogu\u0107e je smanjiti ukupni broj niti i smanjiti potro\u0161nju resursa na obradi zahtjeva.<\/p>\n

Kod neblokiraju\u0107eg ulaza\/izlaza, broj jezgra postaje klju\u010dni parametar, jer on odre\u0111uje broj niti ulaza\/izlaza koje mogu raditi paralelno. Ako se pravilno koriste, omogu\u0107ava u\u010dinkovito raspore\u0111ivanje optere\u0107enja izme\u0111u jezgri i upravljanje ve\u0107im optere\u0107enjima s manjim resursima.<\/p>\n

Kako, i to je sve?<\/h3>\n

\nNe, ima jo\u0161 ne\u010dega. Reaktivno programiranje poma\u017ee bolje koristiti resurse, ali tako\u0111er ima svoju cijenu. Naime, kod \u0107e se morati prepisivati prema na\u010delima neblokiraju\u0107eg ulaza\/izlaza i izbjegavati blokiranje ulaznih\/izlaznih niti. A to je potpuno druga\u010diji model razvoja i izvr\u0161avanja. I iako postoji mno\u0161tvo korisnih biblioteka, to je i dalje radikalna promjena u uobi\u010dajenom na\u010dinu razmi\u0161ljanja.<\/p>\n

Prvo, trebate nau\u010diti pisati kod koji se izvr\u0161ava asinkrono. Kada po\u010dnete koristiti neblokiraju\u0107i ulaz-izlaz, morate izri\u010dito navesti \u0161to se treba dogoditi nakon \u0161to dobijete odgovor na zahtjev. Vi\u0161e ne mo\u017eete jednostavno blokirati i \u010dekati. Umjesto toga, mo\u017eete proslijediti povratne pozive, koristiti reaktivno programiranje ili nastavak. No, to nije sve: da biste koristili neblokiraju\u0107i ulaz-izlaz, trebate i neblokiraju\u0107e poslu\u017eitelje i klijente, i po\u017eeljno je da budu svugdje. U slu\u010daju HTTP-a sve je jednostavno, ali tu su i baze podataka, datote\u010dni sustavi i jo\u0161 mnogo toga.<\/p>\n

I iako potpuna proaktivna reaktivnost donosi maksimalnu efikasnost, takva promjena mo\u017ee biti te\u0161ka za probaviti u praksi. Stoga mogu\u0107nost kombiniranja reaktivnog i imperativnog koda postaje nu\u017ena za:<\/p>\n

    \n
  1. Efikasno kori\u0161tenje resursa na najoptere\u0107enijim dijelovima softverskog sustava;<\/li>\n
  2. Kori\u0161tenje jednostavnijeg koda u njegovim ostalim dijelovima.<\/li>\n<\/ol>\n

    <\/p>\n

    Predstavljamo Quarkus<\/h3>\n

    \nU biti, o tome se radi kod Quarkusa \u2013 spojiti reaktivne i imperativne modele unutar jednog okru\u017eenja izvr\u0161avanja.<\/p>\n

    Osnova Quarkusa su Vert.x i Netty, iznad kojih se koristi niz reaktivnih okvira i pro\u0161irenja koja poma\u017eu programerima. Quarkus je namijenjen izgradnji ne samo HTTP mikroservisa, ve\u0107 i arhitektura vo\u0111enih doga\u0111ajima. Zbog svoje reaktivne prirode, izuzetno je u\u010dinkovit u radu sa sustavima za razmjenu poruka (Apache Kafka, AMQP i sl.).<\/p>\n

    Caka je u tome kako koristiti isti reaktivni motor i za imperativni i za reaktivni kod.<\/p>\n

    \"Kako<\/p>\n

    Quarkus to izvrsno rje\u0161ava. Odabir izme\u0111u imperativnog i reaktivnog programiranja je jasan \u2013 koristiti reaktivno jezgro za oboje. Ono \u0161to posebno poma\u017ee je brzi, neblokiraju\u0107i kod koji obra\u0111uje gotovo sve \u0161to prolazi kroz petlju doga\u0111aja (event-loop thread, tako\u0111er poznat kao IO thread). No, ako imate klasi\u010dne REST aplikacije ili klijentske aplikacije, Quarkus nudi imperativni model programiranja. Na primjer, podr\u0161ka za HTTP u Quarkusu temelji se na kori\u0161tenju neblokiraju\u0107eg i reaktivnog motora (Eclipse Vert.x i Netty). Svi HTTP zahtjevi koje va\u0161a aplikacija prima prvo prolaze kroz petlju doga\u0111aja (IO Thread), a zatim se proslje\u0111uju onom dijelu koda koji upravlja zahtjevima. Ovisno o odredi\u0161tu, kod za upravljanje zahtjevima mo\u017ee se pozivati u okviru zasebnog tijeka (tzv. worker thread, primjenjuje se u slu\u010daju servlet-a i Jax-RS) ili koristiti izvorni IO stream (reaktivna ruta).<\/p>\n

    \"Kako<\/p>\n

    Za konektore sustava za prijenos poruka koriste se neblokiraju\u0107i klijenti koji rade na motoru Vert.x. Zato mo\u017eete u\u010dinkovito slati, primati i obra\u0111ivati poruke iz sustava klasifikacije messaging middleware.<\/p>\n

    Na web stranici Quarkus.io<\/a><\/noindex> pripremljeno je nekoliko dobrih vodi\u010da koji \u0107e vam pomo\u0107i da zapo\u010dnete rad s Quarkus-om:<\/p>\n