{"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\/ro\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","title":{"rendered":"Cum Quarkus combin\u0103 programarea imperativ\u0103 \u0219i reactiv\u0103","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Anul acesta ne propunem s\u0103 dezvolt\u0103m serios temele containerelor, Java Cloud-Native<\/a><\/noindex> \u0219i Kubernetes<\/a><\/noindex>. O continuare logic\u0103 a acestor teme va fi discutarea framework-ului Quarkus, deja examinat<\/a><\/noindex> pe Habr. Articolul de ast\u0103zi nu este at\u00e2t despre cum func\u021bioneaz\u0103 \u00abJava subatomic\u0103 super rapid\u0103\u00bb, c\u00e2t despre perspectivele pe care Quarkus le aduce \u00een Enterprise.<\/p>\n

\"Cum
\n
\nJava \u0219i JVM sunt \u00eenc\u0103 extrem de populare, dar \u00een contextul tehnologiilor f\u0103r\u0103 server \u0219i al microserviciilor cloud-native, Java \u0219i alte limbaje pentru JVM sunt din ce \u00een ce mai rar utilizate, deoarece consum\u0103 prea mult\u0103 memorie \u0219i se \u00eencarc\u0103 prea lent, ceea ce le face inadecvate pentru utilizarea \u00een containere cu o via\u021b\u0103 scurt\u0103. Din fericire, aceast\u0103 situa\u021bie \u00eencepe s\u0103 se schimbe datorit\u0103 lui Quarkus.
\n<\/a><\/noindex><\/p>\n

Java subatomic\u0103 super rapid\u0103 a ajuns la un nou nivel!<\/h3>\n

\n42 de versiuni, 8 luni de munc\u0103 a comunit\u0103\u021bii \u0219i 177 de dezvoltatori uimitori - toate acestea au dus la lansarea \u00een noiembrie 2019 Quarkus 1.0<\/a><\/noindex>, o versiune care marcheaz\u0103 un punct de cotitur\u0103 important \u00een dezvoltarea acestui proiect \u0219i ofer\u0103 o mul\u021bime de caracteristici \u0219i func\u021bionalit\u0103\u021bi grozave (mai multe detalii pot fi citite \u00een anun\u021b<\/a><\/noindex>).<\/p>\n

Ast\u0103zi vom explica cum Quarkus combin\u0103 modelele de programare imperativ\u0103 \u0219i reactiv\u0103 bazate pe un nucleu reactiv unic. Vom \u00eencepe cu o scurt\u0103 excursie \u00een istorie \u0219i apoi vom analiza \u00een detaliu \u00een ce const\u0103 dualitatea nucleului reactiv al Quarkus \u0219i cum Java<\/a><\/noindex>-dezvoltatorii pot profita de aceste avantaje.<\/p>\n

Microservicii<\/a><\/noindex>, arhitecturi gestionate prin evenimente<\/a><\/noindex> \u0219i func\u021bii serverless \u2013 toate acestea sunt ast\u0103zi, ce se cheam\u0103, \u00een ascensiune. Recent, a devenit mult mai simplu \u0219i accesibil s\u0103 construie\u0219ti arhitecturi cloud-native, dar problemele persist\u0103 \u2013 \u00een special pentru dezvoltatorii Java. De exemplu, \u00een cazul func\u021biilor serverless \u0219i microserviciilor exist\u0103 o necesitate acut\u0103 de a reduce timpul de pornire, de a diminua consumul de memorie \u0219i de a face dezvoltarea lor o activitate mai comod\u0103 \u0219i pl\u0103cut\u0103. Java a adus c\u00e2teva \u00eembun\u0103t\u0103\u021biri \u00een ultimii ani, cum ar fi ergnomicile \u00eembun\u0103t\u0103\u021bite pentru containere \u0219i altele. Totu\u0219i, ob\u021binerea unei func\u021bion\u0103ri normale a Java \u00eentr-un container r\u0103m\u00e2ne complex\u0103. De aceea, vom \u00eencepe cu analiza unor dificult\u0103\u021bi interne ale Java, care se manifest\u0103 \u00een mod distinct \u00een dezvoltarea aplica\u021biilor Java orientate pe containere.<\/a><\/noindex>-Func\u021biile sunt, a\u0219adar, \u00een prezent, \u00een plin\u0103 expansiune. De ceva vreme, crearea arhitecturilor orientate pe cloud a devenit mult mai u\u0219oar\u0103 \u0219i accesibil\u0103, \u00eens\u0103 problemele persist\u0103 \u2013 \u00een special pentru dezvoltatorii Java. De exemplu, \u00een cazul func\u021biilor serverless \u0219i al microserviciilor, exist\u0103 o necesitate acut\u0103 de a reduce timpul de ini\u021biere, de a diminua consumul de memorie \u0219i, totodat\u0103, de a face dezvoltarea lor mai convenabil\u0103 \u0219i pl\u0103cut\u0103. Java a adus \u00een ultimii ani c\u00e2teva \u00eembun\u0103t\u0103\u021biri, cum ar fi func\u021bionalitatea ergonomics, adaptat\u0103 pentru containere, \u0219i altele. Cu toate acestea, realizarea unei func\u021bion\u0103ri optime a Java \u00eentr-un container este, \u00een continuare, dificil\u0103. Prin urmare, vom \u00eencepe prin a analiza unele dintre complexit\u0103\u021bile interne ale Java, care se manifest\u0103 \u00een mod special \u00een timpul dezvolt\u0103rii aplica\u021biilor Java orientate pe containere.<\/p>\n

Pentru \u00eenceput, haide\u021bi s\u0103 ne \u00eentoarcem la istorie.<\/p>\n

\"Cum<\/p>\n

Fluxuri \u0219i containere<\/h3>\n

\n\u00cencep\u00e2nd cu versiunea 8u131, Java a \u00eenceput s\u0103 sprijine mai bine containerele prin \u00eembun\u0103t\u0103\u021biri ale func\u021bionalit\u0103\u021bii ergonomice. \u00cen special, acum JVM \u0219tie pe c\u00e2te nuclee de procesor ruleaz\u0103 \u0219i poate s\u0103-\u0219i ajusteze \u00een mod corespunz\u0103tor grupurile de fire \u2013 de obicei, grupuri fork\/join. F\u0103r\u0103 \u00eendoial\u0103, acest lucru este minunat, dar s\u0103 presupunem c\u0103 avem o aplica\u021bie web tradi\u021bional\u0103 care folose\u0219te servlet-uri HTTP \u0219i este rulat\u0103 \u00een Tomcat, Jetty etc. Ca rezultat, aceast\u0103 aplica\u021bie va aloca un fir separatat fiec\u0103rui request \u0219i \u00eei va permite s\u0103 blocheze acest fir \u00een a\u0219teptarea opera\u021biunilor de intrare-ie\u0219ire, de exemplu, atunci c\u00e2nd se face apel la o baz\u0103 de date, fi\u0219iere sau alte servicii. Asta \u00eenseamn\u0103 c\u0103 dimensiunea unei astfel de aplica\u021bii depinde nu de num\u0103rul de nuclee disponibile, ci de num\u0103rul de cereri simultane. \u00cen plus, aceasta \u00eenseamn\u0103 c\u0103 cotele sau limitele \u00een Kubernetes privind num\u0103rul de nuclee nu vor ajuta prea mult, iar situa\u021bia se va finaliza cu throttling.<\/p>\n

Epuizarea memoriei<\/h3>\n

\nFirele sunt memorie. Iar restric\u021biile de memorie dintre containere nu sunt de niciun ajutor. Pur \u0219i simplu \u00eencepe\u021bi s\u0103 cre\u0219te\u021bi num\u0103rul de aplica\u021bii \u0219i fire, \u0219i mai devreme sau mai t\u00e2rziu ve\u021bi \u00eent\u00e2lni o cre\u0219tere critic\u0103 a frecven\u021bei comut\u0103rilor \u0219i, ca urmare, o degradare a performan\u021bei. \u00cen plus, dac\u0103 aplica\u021bia folose\u0219te framework-uri tradi\u021bionale de microservicii sau se conecteaz\u0103 la o baz\u0103 de date, sau utilizeaz\u0103 caching, sau \u00een orice alt mod consum\u0103 suplimentar memorie, este evident c\u0103 ave\u021bi nevoie de un instrument care s\u0103 v\u0103 permit\u0103 s\u0103 privi\u021bi \u00een interiorul JVM-ului \u0219i s\u0103 observa\u021bi cum gestioneaz\u0103 memoria, f\u0103r\u0103 a afecta \u00eens\u0103\u0219i JVM-ul (de exemplu, XX:+UseCGroupMemoryLimitForHeap). Chiar dac\u0103 \u00eencep\u00e2nd cu Java 9, JVM-ul a \u00eenv\u0103\u021bat s\u0103 recunoasc\u0103 cgroups \u0219i s\u0103 se adapteze \u00een mod corespunz\u0103tor, rezervarea \u0219i gestionarea memoriei r\u0103m\u00e2n ni\u0219te sarcini destul de complexe.<\/p>\n

Cote \u0219i limite<\/h3>\n

\n\u00cen Java 11 a ap\u0103rut suport pentru cotele CPU (de genul PreferContainerQuotaForCPUCount). Kubernetes ofer\u0103, de asemenea, suport pentru limite \u0219i cote. Da, toate acestea au sens, dar, dac\u0103 aplica\u021bia dep\u0103\u0219e\u0219te din nou cota alocat\u0103, revenim la situa\u021bia \u00een care dimensiunea \u2013 la fel ca \u00een cazul aplica\u021biilor tradi\u021bionale Java \u2013 este determinat\u0103 de num\u0103rul de nuclee \u0219i se aloc\u0103 un fir separat pentru fiecare cerere, ceea ce \u00eenseamn\u0103 c\u0103 toate acestea nu sunt de mare folos.
\n\u00cen plus, chiar dac\u0103 folosim cote \u0219i limite sau func\u021bii de scalare orizontal\u0103 (scale-out) ale platformei care st\u0103 la baza Kubernetes, problema nu se rezolv\u0103 de la sine. Pur \u0219i simplu cheltuim mai multe resurse pentru a rezolva problema ini\u021bial\u0103 sau, \u00een final, ajungem la un consum excesiv de resurse. Iar dac\u0103 este un sistem de \u00eenalt\u0103 \u00eenc\u0103rcare \u00eentr-un nor public, aproape cu siguran\u021b\u0103 \u00eencepem s\u0103 folosim mai multe resurse dec\u00e2t ar fi necesar.<\/p>\n

\u0218i ce s\u0103 facem cu toate acestea?<\/h3>\n

\nDac\u0103 vrem s\u0103 o spunem simplu, ar trebui s\u0103 folosim biblioteci \u0219i cadre de lucru asyncrone \u0219i non-blocante, precum Netty, Vert.x<\/a><\/noindex> sau Akka. Acestea sunt mult mai potrivite pentru utilizarea \u00een containere datorit\u0103 naturii lor reactive. Datorit\u0103 I\/O-ului non-blocant, aceea\u0219i fire de execu\u021bie poate gestiona mai multe cereri simultan. \u00cen timp ce o cerere a\u0219teapt\u0103 rezultatele I\/O-ului, firul care o proceseaz\u0103 este eliberat \u0219i preia o alt\u0103 cerere. Iar c\u00e2nd rezultatele I\/O-ului sosesc \u00een sf\u00e2r\u0219it, procesarea primei cereri continu\u0103. Altern\u00e2nd procesarea cererilor \u00een cadrul aceluia\u0219i fir, putem reduce num\u0103rul total de fire \u0219i s\u0103 sc\u0103dem consumul de resurse pentru procesarea cererilor.<\/p>\n

\u00cen cazul I\/O-ului non-blocant, num\u0103rul de nuclee devine un parametru cheie, deoarece acesta determin\u0103 num\u0103rul de fire de execu\u021bie I\/O care pot fi executate \u00een paralel. Folosit corect, acest lucru permite distribuirea eficient\u0103 a \u00eenc\u0103rc\u0103turii \u00eentre nuclee \u0219i gestionarea sarcinilor mai mari cu mai pu\u021bine resurse.<\/p>\n

Cum, at\u00e2t \u0219i asta?<\/h3>\n

\nNu, mai este ceva. Programarea reactiv\u0103 ajut\u0103 la utilizarea mai bun\u0103 a resurselor, dar are \u0219i un cost asociat. \u00cen special, codul va trebui rescris conform principiilor non-bloc\u0103rii \u0219i trebuie s\u0103 evit\u0103m blocarea firelor de execu\u021bie I\/O. Aceasta este o modelare complet diferit\u0103 de dezvoltare \u0219i execu\u021bie. \u0218i de\u0219i exist\u0103 o mul\u021bime de biblioteci utile, tot r\u0103m\u00e2ne o schimbare radical\u0103 \u00een modul de g\u00e2ndire obi\u0219nuit.<\/p>\n

\u00cen primul r\u00e2nd, trebuie s\u0103 \u00eenve\u021bi s\u0103 scrii cod care se execut\u0103 \u00een mod asincron. Odat\u0103 ce \u00eencepi s\u0103 folose\u0219ti intrarea-ie\u0219irea neblocat, trebuie s\u0103 specifici clar ce ar trebui s\u0103 se \u00eent\u00e2mple c\u00e2nd prime\u0219ti un r\u0103spuns la cerere. Pur \u0219i simplu s\u0103 blochezi \u0219i s\u0103 a\u0219tep\u021bi nu mai este o op\u021biune. \u00cen schimb, po\u021bi transmite apeluri inverse, folosi programarea reactiv\u0103 sau continuarea. Dar asta nu este tot: pentru a utiliza intrarea-ie\u0219irea neblocat, ai nevoie de servere \u0219i clien\u021bi nebloca\u021bi, ideal \u00een toate locurile. \u00cen cazul HTTP, totul este simplu, dar mai exist\u0103 \u0219i baze de date, sisteme de fi\u0219iere \u0219i multe altele.<\/p>\n

\u0218i de\u0219i reac\u021bia total\u0103 \u00een serie ofer\u0103 maxima eficien\u021b\u0103, o astfel de schimbare poate fi greu de digerat \u00een practic\u0103. Prin urmare, capacitatea de a combina codul reactiv \u0219i cel imperativ devine o condi\u021bie necesar\u0103 pentru a:<\/p>\n

    \n
  1. Utiliza eficient resursele \u00een cele mai aglomerate direc\u021bii ale sistemului software;<\/li>\n
  2. Folosi un cod mai simplu din punct de vedere stilistic \u00een celelalte p\u0103r\u021bi ale acestuia.<\/li>\n<\/ol>\n

    <\/p>\n

    \u00ce\u021bi prezent\u0103m Quarkus<\/h3>\n

    \nDe fapt, acesta este scopul lui Quarkus \u2013 de a combina modelele reactive \u0219i imperative \u00eentr-un singur mediu de execu\u021bie.<\/p>\n

    La baza Quarkus se afl\u0103 Vert.x \u0219i Netty, deasupra c\u0103rora se folose\u0219te o serie de cadre \u0219i extensii reactive, concepute pentru a ajuta dezvoltatorul. Quarkus este destinat s\u0103 construiasc\u0103 nu doar microservicii HTTP, ci \u0219i arhitecturi bazate pe evenimente. Datorit\u0103 naturii sale reactive, func\u021bioneaz\u0103 foarte eficient cu sistemele de mesagerie (Apache Kafka, AMQP etc.).<\/p>\n

    Toat\u0103 miza st\u0103 \u00een modul de utilizare a aceluia\u0219i motor reactiv at\u00e2t pentru codul imperativ, c\u00e2t \u0219i pentru cel reactiv.<\/p>\n

    \"Cum<\/p>\n

    Quarkus se descurc\u0103 excelent cu asta. Alegerea \u00eentre programarea imperativ\u0103 \u0219i reactiv\u0103 este evident\u0103 \u2013 folosi\u021bi nucleul reactiv at\u00e2t pentru una, c\u00e2t \u0219i pentru cealalt\u0103. \u0218i ceea ce ajut\u0103 mult este codul rapid non-blocant care proceseaz\u0103 aproape tot ce trece prin firul ciclului de evenimente (event-loop thread, de asemenea \u2013 fir IO). Dar dac\u0103 ave\u021bi aplica\u021bii REST clasice sau aplica\u021bii pe partea clientului, Quarkus are modelul de programare imperativ preg\u0103tit. De exemplu, suportul HTTP \u00een Quarkus este construit pe utilizarea unui motor non-blocant \u0219i reactiv (Eclipse Vert.x \u0219i Netty). Toate cererile HTTP primite de aplica\u021bia dumneavoastr\u0103 trec mai \u00eent\u00e2i prin ciclul evenimentelor (IO Thread), apoi sunt trimise p\u0103r\u021bii de cod care se ocup\u0103 de cereri. \u00cen func\u021bie de destina\u021bie, codul de gestionare a cererilor poate fi apelat \u00een cadrul unui fir separat\u0103 (a\u0219a-numitul worker thread, folosit \u00een cazul servletelor \u0219i Jax-RS) sau poate utiliza firul de intrare-i\u0219ire original (ruta reactiv\u0103).<\/p>\n

    \"Cum<\/p>\n

    Pentru conectorii sistemelor de transmitere a mesajelor sunt utiliza\u021bi clien\u021bi non-blocan\u021bi, care func\u021bioneaz\u0103 pe baza motorului Vert.x. Astfel, pute\u021bi trimite, primi \u0219i procesa eficient mesaje din sisteme de tip messaging middleware.<\/p>\n

    se men\u021bioneaz\u0103: Quarkus.io<\/a><\/noindex> sunt disponibile mai multe ghiduri utile pentru a \u00eencepe lucrul cu Quarkus:<\/p>\n