{"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 neile on r\u00e4\u00e4kida raamistikust Quarkus, mis on juba tutvustatud<\/a><\/noindex> Habr's. T\u00e4nane artikkel ei k\u00e4sitle niiv\u00f5rd \"alateemalist superkiiret Java\" \u00fclesehitust, vaid pigem v\u00f5imalusi, mida Quarkus toob ettev\u00f5tte arendusse.<\/p>\n

\"Kuidas
\n
\nJava ja JVM on endiselt \u00fclimalt populaarsed, kuid serverita tehnoloogiate ja pilvep\u00f5histe mikroteenuste kasutamisel rakendatakse Java-d ja teisi JVM-i keeli j\u00e4rjest harvemini, kuna need v\u00f5tavad liiga palju m\u00e4lu ja laadivad liiga aeglaselt, mist\u00f5ttu ei sobi need h\u00e4sti l\u00fchiealiste konteineritega t\u00f6\u00f6tamiseks. \u00d5nneks on see olukord praegu muutumas Quarkuse t\u00e4nu.
\n<\/a><\/noindex><\/p>\n

Superkiire alateemaline Java on j\u00f5udnud uuele tasemele!<\/h3>\n

\n42 v\u00e4ljalaskmist, 8 kuu t\u00f6\u00f6 kogukonnalt ja 177 h\u00e4mmastavat arendajat \u2013 selle k\u00f5ik on tulemuseks novembris 2019 v\u00e4ljaanne Quarkus 1.0<\/a><\/noindex>, v\u00e4ljalase, mis t\u00e4histab olulist verstaposti projekti arengus ja pakub hulgaliselt suurep\u00e4raseid funktsioone ja v\u00f5imalusi (rohkem neist saab lugeda avatud<\/a><\/noindex>).<\/p>\n

T\u00e4na r\u00e4\u00e4gime, kuidas Quarkus \u00fchendab imperatiivsete ja reageerivate programmeerimismudelite alusel \u00fchtset reaktiivset tuuma. Alustame l\u00fchikese ajaloo \u00fclevaatega ja seej\u00e4rel vaatame \u00fcksikasjalikult, mis seisneb Quarkuse reaktiivse tuuma dualismis ja kuidas Java<\/a><\/noindex>-arendajad saavad neid eeliseid kasutada.<\/p>\n

Mikroteenused<\/a><\/noindex>, \u00fcritustel p\u00f5hinevad arhitektuurid<\/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 oluliselt lihtsamaks ja k\u00e4ttesaadavamaks, kuid probleemid on j\u00e4\u00e4nud \u2013 eriti Java-arendajatele. N\u00e4iteks serverless-funktsioonide ja mikroteenuste puhul on \u00e4\u00e4rmiselt vajalik k\u00e4ivitusaega l\u00fchendada, m\u00e4lu tarbimist v\u00e4hendada ja muuta nende arendamine mugavamaks ja meeldivamaks. Java on viimastel aastatel teinud mitmeid t\u00e4iustusi, nagu konteineritele m\u00f5eldud funktsionaalsuse t\u00e4iustamine ning muud. Siiski on Java t\u00f5rgete v\u00e4ltimine konteineris endiselt keeruline. Seet\u00f5ttu alustame sellest, et vaatame m\u00f5ningaid Java sisemisi keerukusi, mis eriti teravalt esinevad konteinerip\u00f5histe Java-rakenduste arendamisel.<\/p>\n

Alustuseks vaatame ajalugu.<\/p>\n

\"Kuidas<\/p>\n

S\u00fcsteemid ja konteinerid<\/h3>\n

\nAlates versioonist 8u131 on Java rohkem-v\u00e4hem hakanud konteinerite jaoks toimetama, t\u00e4nu ergonomika funktsionaalsuse t\u00e4iustamisele. Eriti teab JVM n\u00fc\u00fcd, mitu protsessorituuma see t\u00f6\u00f6tab, ja suudab vastavalt konfigureerida t\u00f6\u00f6voogude gruppe \u2013 tavaliselt fork\/join gruppe. See on loomulikult suurep\u00e4rane, kuid oletame, et meil on traditsiooniline veebirakendus, mis kasutab HTTP-serve ja t\u00f6\u00f6tab Tomcatis, Jetty\u2019s jne. Tulemuseks on see, et rakendus jagab iga p\u00e4ringu jaoks eraldi t\u00f6\u00f6voo ja v\u00f5imaldab sellel voolul blokeerida, oodates sisendi-v\u00e4ljundi operatsioone, n\u00e4iteks k\u00f5nes andmebaasiga, failidega v\u00f5i muude teenustega. See t\u00e4hendab, et sellise rakenduse suurus ei s\u00f5ltu saadaval olevate tuumade arvust, vaid samal ajal tehtavate p\u00e4ringute arvust. Lisaks t\u00e4hendab see, et Kubernetes'i tuumade arvu kvoodid v\u00f5i piirangud ei aita siinkohal palju ning l\u00f5ppkokkuv\u00f5ttes viib see troppimise juurde.<\/p>\n

M\u00e4lu ammendumine<\/h3>\n

\nVoolud on m\u00e4lu. Ja konteinerite piirm\u00e4\u00e4rad ei ole sugugi k\u00f5ikv\u00f5imsad. Alustage lihtsalt rakenduste ja voogude arvu suurendamist, ja varem v\u00f5i hiljem seotud olete silmitsi kriitilise konksude vahetuse kasvu ja seega sooritusv\u00f5ime halvenemisega. Lisaks, kui rakendus kasutab traditsioonilisi mikroteenuste raamistikke v\u00f5i on \u00fchendatud andmebaasidega, v\u00f5i rakendab vahem\u00e4lu, v\u00f5i kuidagi muul viisil kasutab m\u00e4lu, vajate kindlasti t\u00f6\u00f6riista, mis v\u00f5imaldab vaadata JVM-i sisse ja n\u00e4ha, kuidas see m\u00e4lu haldab, samas mitte h\u00e4vitades JVM-i ennast (n\u00e4iteks XX:+UseCGroupMemoryLimitForHeap). Ja isegi hoolimata sellest, et alates Java 9-st on JVM \u00f5ppinud cgroups'e tajuma ja vastavalt kohanduma, j\u00e4\u00e4b m\u00e4lu eraldamine ja haldamine \u00fcsna keeruliseks asjaks.<\/p>\n

Kvoodid ja piirangud<\/h3>\n

\nJava 11 on saanud toetuse CPU-kvootidele (n\u00e4iteks PreferContainerQuotaForCPUCount). Kubernetes pakub samuti tugi piirangutele ja kvootidele. Jah, see k\u00f5ik on m\u00f5ttekas, kuid kui rakendus taas \u00fcletab m\u00e4\u00e4ratud kvoodi, p\u00f6\u00f6rdume tagasi koodi, et suurus \u2014 nagu traditsiooniliste Java-rakenduste puhul \u2014 m\u00e4\u00e4ratakse tuumade arvu ja eraldatud niidi m\u00e4\u00e4ramise p\u00f5hjal iga p\u00e4ringu jaoks, seega on sellest k\u00f5igest v\u00e4he kasu.
\nLisaks, kui kasutada kvoote ja piiranguid v\u00f5i Kubernetesel p\u00f5hineva platvormi horisontaalse (scale-out) skaleerimise funktsioone, ei lahenda probleem iseennast. Me lihtsalt kulutame rohkem ressursse algse probleemi lahendamiseks v\u00f5i satume l\u00f5puks ressursside \u00fclekasutamisse. Ja kui see on k\u00f5rge koormusega s\u00fcsteem avalikus pilves, hakkame peaaegu kindlasti kasutama rohkem ressursse, kui tegelikult vajalik.<\/p>\n

Kuidas sellega k\u00f5igega toime tulla?<\/h3>\n

\nLihtsalt \u00f6eldes, tuleks kasutada as\u00fcnkroonseid ja mitteblokeerivaid I\/O teeke ja raamistikku nagu Netty, Vert.x<\/a><\/noindex> v\u00f5i Akka. Need sobivad konteinerites t\u00f6\u00f6tamiseks palju paremini t\u00e4nu oma reaktiivsele iseloomule. T\u00e4nu mitteblokeerivale sisend-v\u00e4ljundile v\u00f5ib sama niit samal ajal k\u00e4sitleda mitmeid samaaegseid p\u00e4ringuid. Samal ajal kui \u00fcks p\u00e4ring ootab sisend-v\u00e4ljundi tulemusi, vabastatakse see niit, et tegeleda teise p\u00e4ringuga. Kui sisend-v\u00e4ljundi tulemused l\u00f5puks saabuvad, j\u00e4tkatakse esimese p\u00e4ringu t\u00f6\u00f6tlemist. \u00dche ja sama niidi raames p\u00e4ringute vahelduv t\u00f6\u00f6tlemine v\u00f5imaldab v\u00e4hendada niitide koguarvu ja v\u00e4hendada ressursikasutust p\u00e4ringute t\u00f6\u00f6tlemisel.<\/p>\n

Mitteblokeeriva sisend-v\u00e4ljundi korral on tuumade arv kriitiline parameeter, kuna just see m\u00e4\u00e4rab, kui palju sisend-v\u00e4ljundi niite saab samaaegselt k\u00e4itada. \u00d5ige kasutuse korral v\u00f5imaldab see t\u00f5husalt jaotada koormust tuumade vahel ning toime tulla suuremate koormustega v\u00e4iksema ressursikasutusega.<\/p>\n

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

\nEi, siin on veel midagi. Reaktiivne programmeerimine aitab paremini kasutada ressursse, kuid see toob ka oma hinda. Eelk\u00f5ige tuleb kood \u00fcmber kirjutada vastavalt blokeerimise v\u00e4ltimise p\u00f5him\u00f5tetele ja v\u00e4ltida sisendi-v\u00e4ljundi voogude blokkeerimist. See on hoopis teine arenduse ja t\u00e4itmise mudel. Ja kuigi siin on palju kasulikke raamatukogusid, on see ikkagi radikaalne muutus harjumusp\u00e4rases m\u00f5tteviisis.<\/p>\n

Esiteks peate \u00f5ppima kirjutama koodi, mis t\u00e4idetakse as\u00fcnkroonselt. Nagu ainult te hakkate kasutama mitteblokeerivat sisendi-v\u00e4ljundit, peate selgelt m\u00e4\u00e4rama, mis juhtub, kui vastus saabub. Lihtsalt blokeerida ja oodata enam ei \u00f5nnestu. Selle asemel saate edastada tagasikutsumisi, kasutada reaktiivset programmeerimist v\u00f5i j\u00e4tkufunktsioone. Kuid see ei ole veel k\u00f5ik: mitteblokeeriva sisendi-v\u00e4ljundi kasutamiseks vajate mitteblokeerivaid servereid ja kliente, ja soovitavalt igal pool. HTTP puhul on k\u00f5ik lihtne, kuid on veel andmebaasid, failis\u00fcsteemid ja palju muud.<\/p>\n

Kuigi totaalne reaktiivne l\u00e4henemine pakub maksimumt\u00f5husust, on sellise \u00fclemineku praktikas rakendamine sageli keeruline. Seet\u00f5ttu on vajalik \u00fchendama reaktiivne ja imperatiivne kood, et:<\/p>\n

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

    <\/p>\n

    Tutvustame Quarkust<\/h3>\n

    \nSelles peitubki Quarkuse olemus \u2013 \u00fchendada reaktiivne ja imperatiivne mudel \u00fche t\u00e4ideviimise keskkonna raames.<\/p>\n

    Quarkuse aluseks on Vert.x ja Netty, millele rajatakse hulk reaktiivseid raamistikke ja laiendusi, et aidata arendajat. Quarkus on m\u00f5eldud mitte ainult HTTP-mikroteenuste, vaid ka s\u00fcndmustega juhitud arhitektuuride ehitamiseks. T\u00e4nu oma reaktiivsele loomusele t\u00f6\u00f6tab see v\u00e4ga t\u00f5husalt s\u00f5numite saatmise s\u00fcsteemidega (Apache Kafka, AMQP jne).<\/p>\n

    K\u00f5ik ongi selles, kuidas kasutada sama reaktiivset mootort nii imperatiivse kui ka reaktiivse koodi jaoks.<\/p>\n

    \"Kuidas<\/p>\n

    Quarkus teeb sellega suurep\u00e4rase t\u00f6\u00f6. Valik imperatiivse ja reaktiivse vahel on ilmne \u2013 kasutada reaktiivset tuuma nii \u00fche kui teise jaoks. See aitab eriti kiiresti ja mitteblokeerivat koodi luua, mis k\u00e4itleb peaaegu k\u00f5ike, mis l\u00e4bib s\u00fcndmuste ts\u00fckli (event-loop thread, tuntud ka kui IO thread). Kuid kui teil on klassikalised REST-rakendused v\u00f5i kliendi poolel t\u00f6\u00f6tavad rakendused, on Quarkusel olemas imperatiivne programmeerimismudel. N\u00e4iteks HTTP toetus 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 edastatakse seej\u00e4rel koodiosasse, mis haldab p\u00e4ringuid. S\u00f5ltuvalt sihtkohast v\u00f5ib p\u00e4ringute haldamise kood k\u00e4ivituda eraldi l\u00f5imes (nn worker thread, rakendatakse servletide ja Jax-RS puhul) v\u00f5i kasutada originaal sisse-\/v\u00e4ljalaske voogu (reaktiivne marsruut reactive route).<\/p>\n

    \"Kuidas<\/p>\n

    S\u00fcndmustes\u00fcsteemide \u00fchendamiseks kasutatakse mittes\u00fcnkroneeritud kliente, mis t\u00f6\u00f6tavad Vert.x mootori peal. Seet\u00f5ttu saate t\u00f5husalt saata, vastu v\u00f5tta ja t\u00f6\u00f6delda s\u00f5numeid s\u00f5numivahetuse vahekihiga seotud s\u00fcsteemidest.<\/p>\n

    Lehelt Quarkus.io<\/a><\/noindex> oleme kogunud mitmeid h\u00e4id juhendeid, et aidata teil Quarkustega alustada:<\/p>\n