Ove godine planiramo ozbiljno razvijati teme kontejnera, i . Logično nastavak ovih tema bit će razgovor o frameworku Quarkus, već na Habré. Današnja prilog posvećen je ne toliko uređaju "subatomske super brze Java", koliko perspektivama koje Quarkus donosi u Enterprise.
Java i JVM su i dalje izuzetno popularni, ali prilikom rada s serverless tehnologijama i oblačno orijentiranim mikroslužbama, Java i drugi jezici za JVM se sve ređe koriste, jer zauzimaju previše memorije i sporo se učitavaju, zbog čega slabo odgovaraju za korištenje s kratkotrajim kontejnerima. Na sreću, ova situacija se trenutno počinje mijenjati zahvaljujući Quarkus.
Super brza subatomska Java je dostigla novu razinu!
42 izdanja, 8 mjeseci rada zajednice i 177 nevjerojatnih developera – rezultat svega ovoga bio je izlazak u novembru 2019. godine , izdanja koje označava važnu prekretnicu u razvoju projekta i nudi brojne sjajne funkcije i mogućnosti (više o njima možete pročitati u ).
Danas ćemo pričati kako Quarkus spaja modele imperativnog i reaktivnog programiranja na osnovi jedinstvenog reaktivnog jezgra. Počet ćemo s kratkim uvodom u povijest, a zatim ćemo detaljno razraditi u čemu se sastoji dualnost reaktivnog jezgra Quarkus i kako -programeri mogu iskoristiti ove prednosti.
, i -funkcije – sve to danas, što se može reći, na vrhuncu je. U posljednje vrijeme kreiranje oblačno orijentiranih arhitektura postalo je mnogo jednostavnije i pristupačnije, međutim problemi su ostali – posebno za Java developere. Na primjer, u slučaju serverless funkcija i mikroslužbi postoji hitna potreba za smanjenjem vremena pokretanja, smanjenjem potrošnje memorije i učiniti njihov razvoj ugodnijim i jednostavnijim. Java je u posljednjih nekoliko godina unijela nekoliko poboljšanja, poput doradnog funkcionalnog ergonomske podrške za kontejnere i slično. Međutim, postizanje normalnog rada Java u kontejneru još uvijek je izazovno. Stoga ćemo početi razmatrati neke od unutarnjih složenosti Jave, koje se posebno ističu prilikom razvoja kontejnerski orijentiranih Java aplikacija.
Za početak, obratimo se povijesti.
Tokovi i kontejneri
Počevši od verzije 8u131, Java je postala prilično podržavati kontejnere zahvaljujući poboljšanjima u funkcionalnosti ergonomije. Naime, sada JVM zna na koliko se procesorskih jezgri pokreće i može odgovarajuće prilagoditi bazene tokova – obično fork/join bazene. Naravno, to je odlično, ali recimo da imamo tradicionalnu web aplikaciju koja koristi HTTP servlete i pokreće se u Tomcat, Jetty i sličnim okruženjima. Kao rezultat toga, ova aplikacija će svakoj zahtjevini dodijeliti zasebni tok i omogućiti mu da blokira taj tok dok čeka ulazno-izlazne operacije, primjerice, prilikom pristupa bazi podataka, datotekama ili ostalim servisima. Drugim riječima, veličina takve aplikacije ne ovisi o broju dostupnih jezgri, već o broju istodobnih zahtjeva. Osim toga, to znači da kvote ili ograničenja u Kubernetesu po broju jezgri ovdje nisu od velike pomoći, i na kraju će se sve svesti na throttling.
Iscrpljivanje memorije
Tokovi su memorija. I unutarkontejnerska ograničenja memorije nisu lijek za sve. Jednostavno počnite povećavati broj aplikacija i tokova, i prije ili kasnije suočit ćete se s kritičnim rastom učestalosti promjena i, kao posljedica, s degradacijom performansi. Nadalje, ako aplikacija koristi tradicionalne mikroservisne okvire ili se povezuje s bazom podataka, ili koristi keširanje, ili na neki način dodatno troši memoriju, očito vam je potreban alat koji omogućuje da zavirite unutar JVM-a i vidite kako upravlja memorijom, a da pritom ne ubijete samu JVM (npr. XX:+UseCGroupMemoryLimitForHeap). I čak iako je, počevši s Javom 9, JVM naučila prepoznavati cgroups i odgovarajuće se prilagođavati, rezervacija i upravljanje memorijom ostaje prilično složen zadatak.
Kvote i ograničenja
U Javi 11 uvedena je podrška za CPU kvote (poput PreferContainerQuotaForCPUCount). Kubernetes također nudi podršku za ograničenja i kvote. Da, sve to ima smisla, ali ako aplikacija opet premaši dodijeljenu kvotu, ponovno dolazimo do toga da veličinu – kao u slučaju tradicionalnih Java aplikacija – određuje broj jezgri uz dodjeljivanje zasebnog toka za svaki zahtjev, dakle, koristi od svega toga su ograničene.
Osim toga, korištenje kvota i limita ili funkcija horizontalnog (scale-out) skaliranja platforme koja temelji Kubernetes ne rješava problem samo od sebe. Tako samo trošimo više resursa na rješavanje osnovnog problema ili na kraju završavamo s prekomjernom potrošnjom resursa. A ako je to visoko opterećen sustav u javnom oblaku, gotovo sigurno počinjemo trošiti više resursa nego što je stvarno potrebno.
Što učiniti sa svime tim?
Ako kažemo jednostavno, treba koristiti asinkrone i neblokirajuće biblioteke ulaza/izlaza i okvire poput Netyja, ili Akka. Oni su mnogo bolje prilagođeni radu u kontejnerima zbog svoje reaktivne prirode. Zahvaljujući neblokirajućem ulazu/izlazu, ista nit može obrađivati više istovremenih zahtjeva. Dok jedan zahtjev čeka rezultate ulaza/izlaza, nit koja ga obrađuje se oslobađa i preuzima drugi zahtjev. A kada rezultati ulaza/izlaza napokon stignu, obrada prvog zahtjeva se nastavlja. Naizmjeničnim obrađivanjem zahtjeva unutar iste niti, moguće je smanjiti ukupni broj niti i smanjiti potrošnju resursa na obradi zahtjeva.
Kod neblokirajućeg ulaza/izlaza, broj jezgra postaje ključni parametar, jer on određuje broj niti ulaza/izlaza koje mogu raditi paralelno. Ako se pravilno koriste, omogućava učinkovito raspoređivanje opterećenja između jezgri i upravljanje većim opterećenjima s manjim resursima.
Kako, i to je sve?
Ne, ima još nečega. Reaktivno programiranje pomaže bolje koristiti resurse, ali također ima svoju cijenu. Naime, kod će se morati prepisivati prema načelima neblokirajućeg ulaza/izlaza i izbjegavati blokiranje ulaznih/izlaznih niti. A to je potpuno drugačiji model razvoja i izvršavanja. I iako postoji mnoštvo korisnih biblioteka, to je i dalje radikalna promjena u uobičajenom načinu razmišljanja.
Prvo, trebate naučiti pisati kod koji se izvršava asinkrono. Kada počnete koristiti neblokirajući ulaz-izlaz, morate izričito navesti što se treba dogoditi nakon što dobijete odgovor na zahtjev. Više ne možete jednostavno blokirati i čekati. Umjesto toga, možete proslijediti povratne pozive, koristiti reaktivno programiranje ili nastavak. No, to nije sve: da biste koristili neblokirajući ulaz-izlaz, trebate i neblokirajuće poslužitelje i klijente, i poželjno je da budu svugdje. U slučaju HTTP-a sve je jednostavno, ali tu su i baze podataka, datotečni sustavi i još mnogo toga.
I iako potpuna proaktivna reaktivnost donosi maksimalnu efikasnost, takva promjena može biti teška za probaviti u praksi. Stoga mogućnost kombiniranja reaktivnog i imperativnog koda postaje nužna za:
- Efikasno korištenje resursa na najopterećenijim dijelovima softverskog sustava;
- Korištenje jednostavnijeg koda u njegovim ostalim dijelovima.
Predstavljamo Quarkus
U biti, o tome se radi kod Quarkusa – spojiti reaktivne i imperativne modele unutar jednog okruženja izvršavanja.
Osnova Quarkusa su Vert.x i Netty, iznad kojih se koristi niz reaktivnih okvira i proširenja koja pomažu programerima. Quarkus je namijenjen izgradnji ne samo HTTP mikroservisa, već i arhitektura vođenih događajima. Zbog svoje reaktivne prirode, izuzetno je učinkovit u radu sa sustavima za razmjenu poruka (Apache Kafka, AMQP i sl.).
Caka je u tome kako koristiti isti reaktivni motor i za imperativni i za reaktivni kod.
Quarkus to izvrsno rješava. Odabir između imperativnog i reaktivnog programiranja je jasan – koristiti reaktivno jezgro za oboje. Ono što posebno pomaže je brzi, neblokirajući kod koji obrađuje gotovo sve što prolazi kroz petlju događaja (event-loop thread, također poznat kao IO thread). No, ako imate klasične REST aplikacije ili klijentske aplikacije, Quarkus nudi imperativni model programiranja. Na primjer, podrška za HTTP u Quarkusu temelji se na korištenju neblokirajućeg i reaktivnog motora (Eclipse Vert.x i Netty). Svi HTTP zahtjevi koje vaša aplikacija prima prvo prolaze kroz petlju događaja (IO Thread), a zatim se prosljeđuju onom dijelu koda koji upravlja zahtjevima. Ovisno o odredištu, kod za upravljanje zahtjevima može se pozivati u okviru zasebnog tijeka (tzv. worker thread, primjenjuje se u slučaju servlet-a i Jax-RS) ili koristiti izvorni IO stream (reaktivna ruta).
Za konektore sustava za prijenos poruka koriste se neblokirajući klijenti koji rade na motoru Vert.x. Zato možete učinkovito slati, primati i obrađivati poruke iz sustava klasifikacije messaging middleware.
Na web stranici pripremljeno je nekoliko dobrih vodiča koji će vam pomoći da započnete rad s Quarkus-om:
Osim toga, pripremili smo online praktične tečajeve za upoznavanje s različitim aspektima reaktivnog programiranja; za njihovo praćenje dovoljan je samo preglednik, nije potrebna nikakva IDE, niti je računar obavezan. Ove tečajeve možete pronaći .
Koristan resurs
- Web stranica projekta Quarkus –
- Projekt Quarkus na GitHub-u –
- Twitter projekt Quarkus –
- Chat projekta Quarkus –
- Forumi projekta Quarkus – !forum/quarkus-dev
10 video lekcija o Quarkus-u za početak
Kako navode na web stranici , – to je -orijentirani Java-tehnološki skup, prilagođen GraalVM-u i OpenJDK HotSpot-u, sastavljen od najboljih Java biblioteka i standarda.
Kako bismo vam pomogli da se bolje upoznate s temom, odabrali smo 10 video lekcija koje pokrivaju različite aspekte Quarkus-a i primjere njegove upotrebe:
1. Predstavljamo Quarkus: Java okvir nove generacije za Kubernetes
Autori: Thomas Qvarnstrom i Jason Greene
Cilj projekta Quarkus je izgraditi Java platformu za Kubernetes i serverless okruženja, a također kombinirati reaktivne i imperativne modele programiranja unutar jedne izvršne sredine kako bi programeri mogli fleksibilno mijenjati pristup dok rade s širokim spektrom distribuiranih arhitektura aplikacija. Saznajte više iz uvodne lekcije u nastavku.
2. Quarkus: superbrza subatomska Java
Autor: Burr Sutter
Video lekcija iz internetskog lektora DevNation Live pokazuje kako koristiti Quarkus za optimizaciju poslovnih Java aplikacija, API-ja, mikrousluga i serverless funkcija u Kubernetes/OpenShift okruženju, čineći ih znatno manjima, bržima i skalabilnijima.
3. Quarkus i GraalVM: ubrzavamo Hibernate do superbrzih brzina i smanjujemo ga do subatomskih dimenzija
Autor: Sanne Grinovero
Iz prezentacije ćete saznati kako je Quarkus nastao, kako funkcionira i kako omogućava da složene biblioteke, poput Hibernate ORM, budu kompatibilne s native slikama GraalVM.
4. Učimo razvijati serverless aplikacije
Autor: Marthen Luther
U videu ispod prikazano je kako stvoriti jednostavnu Java aplikaciju koristeći Quarkus i implementirati je kao serverless aplikaciju na Knative.
5. Quarkus: kodirajte s užitkom
Autor: Edson Yanaga
Vodič video o stvaranju vašeg prvog Quarkus projekta, koji objašnjava zašto Quarkus osvaja srca programera.
6. Java i kontejneri – kakva će biti njihova zajednička budućnost
Autor: Mark Little
Ova prezentacija upoznaje s poviješću Jave i objašnjava zašto je Quarkus budućnost Jave.
7. Quarkus: superbrza subatomska Java
Autor: Dimitris Andreadis
Pregled prednosti Quarkusa, koje su programeri prepoznali: jednostavnost, ultra visoke brzine, najbolje biblioteke i standardi.
8. Quarkus i subatomski reaktivni sustavi
Autor: Clement Escoffier
Zahvaljujući integraciji s GraalVM, Quarkus osigurava superbrzu razvojnu iskustvo i subatomsku sredinu izvršavanja. Autor govori o reaktivnoj strani Quarkusa i o tome kako je koristiti pri stvaranju reaktivnih aplikacija i aplikacija s prijenosom podataka.
9. Quarkus i brza izrada aplikacija u Eclipse MicroProfile
Autor: John Clingan
Kombinacijom Eclipse MicroProfile i Quarkusa, programeri mogu razvijati potpuno funkcionalne kontejnerske aplikacije MicroProfile koje se pokreću za samo nekoliko desetaka milisekundi. U videu se detaljno objašnjava kako kodirati kontejnersku aplikaciju MicroProfile za implementaciju na Kubernetes platformi.
10. Java, verzija „Turbo“
Autor: Markus Biel
Autor pokazuje kako koristiti Quarkus za kreiranje super malih i super brzih Java kontejnera, omogućavajući stvaranje pravih proboja, posebno u serverless okruženjima.
Izvor: habr.com
