{"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\/et\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","title":{"rendered":"Kuidas Quarkus \u00fchendab imperatiivset ja reaktiivset programmeerimist","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sel aastal plaanime t\u00f5siselt arendada konteinerite teemasid, Cloud-Native Java<\/a><\/noindex> ja Kubernetes<\/a><\/noindex>. Loomulik j\u00e4tk nendele teemadele on jutustamine raamistikust Quarkus, mida on juba tutvustatud<\/a><\/noindex> Habr\u00e9. T\u00e4na on artikkel p\u00fchendatud mitte niiv\u00f5rd \u201esubatomaarse \u00fcli kiire Java\u201c seadusele, kuiv\u00f5rd sellele, millised perspektiivid Quarkus toob Enterprise'i.<\/p>\n

\"Kuidas
\n
\nJava ja JVM on endiselt \u00e4\u00e4rmiselt populaarsed, kuid serveriteta tehnoloogiate ja pilvep\u00f5histe mikroteenustega t\u00f6\u00f6tades kasutatakse Java't ja teisi JVM-i keeli j\u00e4rjest harvemini, kuna need kasutavad liiga palju m\u00e4lu ja laaditakse liiga aeglaselt, mist\u00f5ttu need ei sobi h\u00e4sti l\u00fchiealiste konteinerite kasutamiseks. \u00d5nneks hakkab praegune olukord t\u00e4nu Quarkusele muutuma.
\n<\/a><\/noindex><\/p>\n

\u00dcli kiire subatomaarne Java on saavutanud uue taseme!<\/h3>\n

\n42 versiooni, 8 kuud kogukonna t\u00f6\u00f6d ja 177 h\u00e4mmastavat arendajat \u2013 selle k\u00f5ikide tulemuseks oli Quarkus 1.0 v\u00e4ljaandmine novembris 2019. Quarkus 1.0<\/a><\/noindex>, v\u00e4ljaanne, mis t\u00e4histab olulist verstaposti projekti arengus ja pakub hulgaliselt lahedaid funktsioone ja v\u00f5imalusi (t\u00e4iendavat teavet nende kohta saab lugeda teated<\/a><\/noindex>).<\/p>\n

T\u00e4na r\u00e4\u00e4gime sellest, kuidas Quarkus \u00fchendab imperatiivse ja reaktiivse programmeerimise mudelid \u00fchtse reaktiivse tuuma p\u00f5hjal. Alustame l\u00fchikese ajaloo\u00fclevaatega ja seej\u00e4rel vaatame p\u00f5hjalikult, kus seisneb Quarkuse reaktiivse tuuma dualism ja kuidas Java<\/a><\/noindex>-arendajad saavad neist eelistest kasu.<\/p>\n

Mikroteenused<\/a><\/noindex>, s\u00fcndmustega juhitavate arhitektuuride<\/a><\/noindex> ja serverless<\/a><\/noindex>-funktsioonid \u2013 k\u00f5ik see on t\u00e4nap\u00e4eval, nagu \u00f6eldakse, t\u00f5usuteel. Hiljuti on pilvep\u00f5histe arhitektuuride loomine muutunud palju lihtsamaks ja k\u00e4ttesaadavamaks, kuid probleemid j\u00e4\u00e4vad \u2013 eriti Java arendajatele. N\u00e4iteks serverless-funktsioonide ja mikroteenuste puhul on \u00e4\u00e4rmiselt oluline v\u00e4hendada k\u00e4ivitusaega, v\u00e4hendada m\u00e4lu kasutust ja muuta nende arendamine mugavamaks ja meeldivamaks. Java on viimastel aastatel teinud mitmeid t\u00e4iustusi, sealhulgas konteinerite toetava funktsionaalsuse ergonoomikat jne. Kuid enamasti ei ole Java sujuva t\u00f6\u00f6 saavutamine konteineris endiselt lihtne. Seet\u00f5ttu alustame m\u00f5ningate Java sisemiste keerukustega, mis ilmnevad eriti teravalt konteinerip\u00f5histe Java rakenduste arendamisel.<\/p>\n

Alustame ajaloost.<\/p>\n

\"Kuidas<\/p>\n

Voogud ja konteinerid<\/h3>\n

\nAlates versioonist 8u131 on Java hakanud paremini toetama konteinerite kasutust, t\u00e4nu ergonomika funktsionaalsuse parendustele. Eelk\u00f5ige teab JVM n\u00fc\u00fcd, kui palju protsessori tuumasid see kasutab, ja saab vastavalt sellele kohandada l\u00f5ime gruppe \u2013 enamasti fork\/join gruppe. Muidugi on see suurep\u00e4rane, kuid oletame, et meil on traditsiooniline veebirakendus, mis kasutab HTTP-servlette ja t\u00f6\u00f6tab Tomcatis, Jetty's jne. Tulemuseks on, et see rakendus eraldab igale p\u00e4ringule eraldi l\u00f5ime ja v\u00f5imaldab tal blokeerida selle l\u00f5ime sisend-v\u00e4ljund operatsioonide ootel, n\u00e4iteks andmebaasi, failide v\u00f5i teiste teenuste kutsumisel. See t\u00e4hendab, et sellise rakenduse suurus ei s\u00f5ltu k\u00e4ttesaadavate tuumade arvust, vaid samaaegsete p\u00e4ringute arvust. Lisaks t\u00e4hendab see, et Kubernetes'i tuumade arvu kvoodid v\u00f5i piirangud ei aita siin eriti, ja asi l\u00f5ppeb l\u00f5puks throttling'uga.<\/p>\n

M\u00e4lu ammendumine<\/h3>\n

\nL\u00f5imed on m\u00e4lu. Ja konteinerite sisemised m\u00e4lu piirangud ei ole kaugeltki imerohi. Alustage rakenduste ja l\u00f5imede arvu suurendamist ja varem v\u00f5i hiljem seisate silmitsi kriitilise kl\u00f5psamissageduse kasvuga, mis omakorda toob kaasa j\u00f5udluse languse. Lisaks, kui rakendus kasutab traditsioonilisi mikroteenuste raamistikku v\u00f5i \u00fchendub andmebaasidega, v\u00f5i kasutab cache'ingut, v\u00f5i tarbib kuidagi muul moel m\u00e4lu, vajate kindlasti t\u00f6\u00f6riista, mis v\u00f5imaldab vaadata JVM-i sisse ja n\u00e4ha, kuidas ta m\u00e4lu haldab, tapmata samas JVM-i (nt XX:+UseCGroupMemoryLimitForHeap). Ning kuigi alates Java 9-st on JVM \u00f5ppinud tundma cgroup'e ja kohandub vastavalt, j\u00e4\u00e4b m\u00e4lu reserveerimine ja haldamine ikka \u00fcsna keeruliseks.<\/p>\n

Kvoodid ja piirangud<\/h3>\n

\nJava 11-s lisandus CPU kvootide tugi (nt PreferContainerQuotaForCPUCount). Kubernetes pakub samuti toetust piirangutele ja kvootidele. Jah, see k\u00f5ik on m\u00f5ttekas, kuid kui rakendus j\u00e4lle \u00fcletab m\u00e4\u00e4ratud kvooti, j\u00f5uame j\u00e4lle selleni, et suurus \u2013 nagu traditsiooniliste Java rakenduste puhul \u2013 m\u00e4\u00e4ratakse tuumade arvu j\u00e4rgi, eraldades igale p\u00e4ringule eraldi l\u00f5ime, see t\u00e4hendab, et kogu sellest ei ole suurt kasu.
\nLisaks, isegi kui kasutada Kubernetes'i aluseks olevat platvormi kvote ja limiite v\u00f5i horisontaalse (scale-out) skaleerimise funktsioone, ei lahenda probleem iseenesest. Me lihtsalt kulutame rohkem ressursse algse probleemi lahendamiseks v\u00f5i l\u00f5puks j\u00e4\u00e4me ressursse \u00fcle. Ja kui see on k\u00f5rge koormusega s\u00fcsteem avalikus pilves, hakkame peaaegu kindlasti kasutama rohkem ressursse, kui tegelikult vajalik on.<\/p>\n

Ja mida k\u00f5igega sellega teha?<\/h3>\n

\nLihtsalt \u00f6eldes, tuleks kasutada as\u00fcnkroonseid ja blokeerimata sisendi-v\u00e4ljundi teeke ning raamistikke nagu Netty, Vert.x<\/a><\/noindex> v\u00f5i Akka. Need sobivad konteinerites t\u00f6\u00f6tamiseks palju paremini oma reaktiivse olemuse t\u00f5ttu. Blokeerimata sisendi-v\u00e4ljundi t\u00f5ttu saab sama niidi t\u00f6\u00f6tleja korraga t\u00f6\u00f6delda mitmeid samaaegseid p\u00e4ringuid. Samal ajal kui \u00fcks p\u00e4ring ootab sisendi-v\u00e4ljundi tulemusi, vabastatakse selle t\u00f6\u00f6tlev niit ja asub teise p\u00e4ringu juurde. Ja kui sisendi-v\u00e4ljundi tulemused l\u00f5puks saadakse, j\u00e4tkub esimese p\u00e4ringu t\u00f6\u00f6tlemine. Korrates p\u00e4ringute t\u00f6\u00f6tlemist \u00fche ja sama niidi raames, saab v\u00e4hendada \u00fcldiste niitide arvu ja v\u00e4hendada p\u00e4ringute t\u00f6\u00f6tlemise jaoks vajalike ressursside kulu.<\/p>\n

Blokeerimata sisendi-v\u00e4ljundi korral muutub protsessorite arv kriitiliseks parameetriks, kuna see m\u00e4\u00e4rab sisendi-v\u00e4ljundi niitide arvu, mida saab samaaegselt t\u00f6\u00f6delda. \u00d5ige kasutamise korral v\u00f5imaldab see t\u00f5husalt jaotada koormust protsessorite vahel ja hallata suuremaid koormusi v\u00e4iksema ressursikasutusega.<\/p>\n

Kuidas, ja kas see on k\u00f5ik?<\/h3>\n

\nEi, on veel midagi. Reaktiivne programmeerimine aitab paremini kasutada ressursse, kuid sellel on ka oma hind. Eelk\u00f5ige tuleb kood \u00fcmber kirjutada vastavalt blokeerimise v\u00e4ltimise p\u00f5him\u00f5tetele ja v\u00e4ltida sisendi-v\u00e4ljundi niitide blokeerimist. Ja see on hoopis teine arendamise ja t\u00e4itmise mudel. Ja kuigi seal on palju kasulikke teeke, on see ikkagi radikaalne muutus harjumusp\u00e4rastest m\u00f5ttemustritest.<\/p>\n

Esiteks peate \u00f5ppima kirjutama koodi, mis t\u00f6\u00f6tab as\u00fcnkroonselt. Kui hakkate kasutama blokeerimata sisend-v\u00e4ljundit, peate selgelt m\u00e4\u00e4rama, mis peaks toimuma vastuse saamisel p\u00e4ringule. Lihtsalt blokeerida ja oodata enam ei saa. Selle asemel v\u00f5ite edastada tagasiside, kasutada reaktiivprogrammeerimist v\u00f5i continuation-i. Kuid see pole veel k\u00f5ik: blokeerimata sisend-v\u00e4ljundi kasutamiseks vajate ka blokeerimata servereid ja kliente, eelistatult igal pool. HTTP puhul on k\u00f5ik lihtne, kuid on veel andmebaasid, failis\u00fcsteemid ja palju muud.<\/p>\n

Ja kuigi totaalne l\u00e4bipaistev reaktiivsus pakub maksimaalset efektiivsust, v\u00f5ib selline muutus olla praktikas raske seedida. Seet\u00f5ttu muutub reaktiivse ja imperatiivse koodi kombineerimise v\u00f5imalus h\u00e4davajalikuks, et:<\/p>\n

    \n
  1. T\u00f5husalt kasutada ressursse k\u00f5ige koormatumates programmide s\u00fcsteemides;<\/li>\n
  2. Kasutada lihtsamat stiili koodi \u00fclej\u00e4\u00e4nud osades.<\/li>\n<\/ol>\n

    <\/p>\n

    Tutvustame Quarkust<\/h3>\n

    \nOtsustav ongi see, et Quarkus \u00fchendab reaktiivsed ja imperatiivsed mudelid \u00fches t\u00e4itmiskeskkonnas.<\/p>\n

    Quarkuse aluseks on Vert.x ja Netty, mille peal on rida reaktiivseid raamistikke ja laiendusi, mis aitavad arendajal. Quarkus on m\u00f5eldud mitte ainult HTTP-mikroteenuste, vaid ka s\u00fcndmustega juhitud arhitektuuride loomiseks. T\u00e4nu oma reaktiivsele iseloomule t\u00f6\u00f6tab see v\u00e4ga t\u00f5husalt s\u00f5numite edastamise s\u00fcsteemidega (Apache Kafka, AMQP jms).<\/p>\n

    K\u00f5ik on h\u00f5lmatud selles, kuidas kasutada \u00fchte ja sama reaktiivset mootorit nii imperatiivse kui ka reaktiivse koodi jaoks.<\/p>\n

    \"Kuidas<\/p>\n

    Quarkus lahendab selle suurep\u00e4raselt. Valik imperatiivse ja reaktiivse vahel on selge \u2013 kasutada reaktiivset tuuma nii \u00fche kui teise jaoks. Ja see, millega see t\u00f5eliselt aitab, on kiire mitteblokeeriv kood, mis t\u00f6\u00f6tleb peaaegu k\u00f5ike, mis l\u00e4bib s\u00fcndmuste ts\u00fckli (event-loop thread, tuntud ka kui IO thread). Kuid kui teil on klassikalised REST-iga rakendused v\u00f5i kliendipoolseid rakendusi, on Quarkusel valmis imperatiivne programmeerimisviis. N\u00e4iteks HTTP tugi Quarkuses p\u00f5hineb mitteblokeeriva ja reaktiivse mootori (Eclipse Vert.x ja Netty) kasutamisel. K\u00f5ik HTTP p\u00e4ringud, mis teie rakendusse j\u00f5uavad, l\u00e4bivad esmalt s\u00fcndmuste ts\u00fckli (IO Thread) ja seej\u00e4rel saadetakse koodiosale, mis haldab p\u00e4ringuid. S\u00f5ltuvalt sihtkohast v\u00f5ib p\u00e4ringute haldamise kood k\u00e4ivituda eraldi l\u00f5imes (nii tuntud worker thread, mis on kasutusel servletite ja Jax-RS puhul) v\u00f5i kasutada algset sisend-v\u00e4ljundit (reaktiivne marsruut).<\/p>\n

    \"Kuidas<\/p>\n

    S\u00f5numite edastamise s\u00fcsteemide konnektorite jaoks kasutatakse mitteblokeerivaid kliente, mis t\u00f6\u00f6tavad Vert.x mootori peal. Seega saate t\u00f5husalt saata, vastu v\u00f5tta ja t\u00f6\u00f6delda s\u00f5numeid s\u00f5numite vahendusklassi s\u00fcsteemidest.<\/p>\n

    Meie veebisaidil Quarkus.io<\/a><\/noindex> on koostatud mitu head juhendit, mis aitavad Quarkusega alustada:<\/p>\n