{"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\/hu\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","title":{"rendered":"Hogyan egyes\u00edti a Quarkus az imperat\u00edv \u00e9s reakt\u00edv programoz\u00e1st","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Id\u00e9n komolyan tervezz\u00fck a kont\u00e9neres t\u00e9m\u00e1k el\u0151mozd\u00edt\u00e1s\u00e1t, Cloud-Native Java<\/a><\/noindex> \u00e9s Kubernetes<\/a><\/noindex>. Ennek a t\u00e9m\u00e1nak a logikus folytat\u00e1sa a Quarkus keretr\u0151l sz\u00f3l\u00f3 besz\u00e1mol\u00f3, amelyet m\u00e1r \u00e1ttekintett\u00fcnk<\/a><\/noindex> a Habr-on. A mai cikk nem annyira a \u201eszubatomi szupergyors Java\u201d m\u0171k\u00f6d\u00e9s\u00e9re vonatkozik, hanem arra a perspekt\u00edv\u00e1ra, amelyet a Quarkus az Enterprise-ba hoz.<\/p>\n

\"Hogyan
\n
\nA Java \u00e9s a JVM tov\u00e1bbra is rendk\u00edv\u00fcl n\u00e9pszer\u0171, de a serverless technol\u00f3gi\u00e1k \u00e9s a felh\u0151alap\u00fa mikroszolg\u00e1ltat\u00e1sok ter\u00e9n egyre ritk\u00e1bban haszn\u00e1lj\u00e1k a Java-t \u00e9s a JVM m\u00e1s nyelveit, mivel t\u00fal sok mem\u00f3ri\u00e1t foglalnak el \u00e9s t\u00fal lassan t\u00f6ltenek be, \u00edgy nem alkalmasak a r\u00f6vid \u00e9let\u0171 kont\u00e9nerekkel val\u00f3 haszn\u00e1latra. Szerencs\u00e9re mostanra ez a helyzet kezd v\u00e1ltozni a Quarkus-nak k\u00f6sz\u00f6nhet\u0151en.
\n<\/a><\/noindex><\/p>\n

A szupergyors szubatomi Java \u00faj szintre l\u00e9pett!<\/h3>\n

\n42 kiad\u00e1s, 8 h\u00f3nap k\u00f6z\u00f6ss\u00e9gi munka \u00e9s 177 leny\u0171g\u00f6z\u0151 fejleszt\u0151 \u2013 mindez november 2019-ben a Quarkus 1.0 kiad\u00e1shoz vezetett, , amely m\u00e9rf\u00f6ldk\u0151 a projekt fejl\u0151d\u00e9s\u00e9ben, \u00e9s sz\u00e1mos klassz funkci\u00f3t \u00e9s lehet\u0151s\u00e9get k\u00edn\u00e1l (t\u00f6bbet olvashat a<\/a><\/noindex>Ma arr\u00f3l besz\u00e9l\u00fcnk, hogyan egyes\u00edti a Quarkus az imperat\u00edv \u00e9s reakt\u00edv programoz\u00e1si modelleket egyetlen reakt\u00edv mag k\u00f6r\u00e9. Kezdj\u00fck egy r\u00f6vid t\u00f6rt\u00e9neti \u00e1ttekint\u00e9ssel, majd r\u00e9szletesen megvizsg\u00e1ljuk, hogy mi rejlik a Quarkus reakt\u00edv magj\u00e1nak dualizmus\u00e1ban, \u00e9s hogy bejelent\u00e9s<\/a><\/noindex>).<\/p>\n

-fejleszt\u0151k hogyan haszn\u00e1lhatj\u00e1k ki ezeket az el\u0151ny\u00f6ket. Java<\/a><\/noindex>A mikroszolg\u00e1ltat\u00e1sok<\/p>\n

esem\u00e9ny-vez\u00e9relt architekt\u00far\u00e1k,<\/a><\/noindex>, a serverless<\/a><\/noindex> \u00e9s -funkci\u00f3k \u2013 mindez ma, mondhatni, felfut\u00f3ban van. Az ut\u00f3bbi id\u0151ben a felh\u0151alap\u00fa architekt\u00far\u00e1k l\u00e9trehoz\u00e1sa sokkal egyszer\u0171bb\u00e9 \u00e9s el\u00e9rhet\u0151bb\u00e9 v\u00e1lt, azonban a probl\u00e9m\u00e1k megmaradtak \u2013 k\u00fcl\u00f6n\u00f6sen a Java-fejleszt\u0151k sz\u00e1m\u00e1ra. P\u00e9ld\u00e1ul a serverless-funkci\u00f3k \u00e9s mikroszolg\u00e1ltat\u00e1sok eset\u00e9ben s\u00fcrget\u0151 sz\u00fcks\u00e9g van a ind\u00edt\u00e1si id\u0151 cs\u00f6kkent\u00e9s\u00e9re, a mem\u00f3riahaszn\u00e1lat cs\u00f6kkent\u00e9s\u00e9re \u00e9s arra, hogy a fejleszt\u00e9s k\u00e9nyelmesebb\u00e9 \u00e9s \u00e9lvezetesebb\u00e9 v\u00e1ljon. Az ut\u00f3bbi \u00e9vekben a Java sz\u00e1mos fejleszt\u00e9st \u00e9rt el, p\u00e9ld\u00e1ul a kont\u00e9nerekhez optimaliz\u00e1lt ergonomikus funkci\u00f3kat stb. De a Java norm\u00e1lis m\u0171k\u00f6d\u00e9s\u00e9nek el\u00e9r\u00e9se kont\u00e9nerben tov\u00e1bbra sem egyszer\u0171. Ez\u00e9rt el\u0151sz\u00f6r megvizsg\u00e1ljuk a Java n\u00e9h\u00e1ny bels\u0151 bonyolults\u00e1g\u00e1t, amelyek k\u00fcl\u00f6n\u00f6sen \u00e9les hat\u00e1st gyakorolnak a kont\u00e9ner-alap\u00fa Java-alkalmaz\u00e1sok fejleszt\u00e9sekor.<\/a><\/noindex>-A funkci\u00f3k mind olyan ter\u00fcletek, amelyeket ma m\u00e1r fellend\u00fcl\u00e9s jellemez. Az ut\u00f3bbi id\u0151ben a felh\u0151alap\u00fa architekt\u00far\u00e1k l\u00e9trehoz\u00e1sa sokkal egyszer\u0171bb\u00e9 \u00e9s el\u00e9rhet\u0151bb\u00e9 v\u00e1lt, azonban a probl\u00e9m\u00e1k megmaradtak \u2013 k\u00fcl\u00f6n\u00f6sen a Java-fejleszt\u0151k sz\u00e1m\u00e1ra. P\u00e9ld\u00e1ul a serverless funkci\u00f3k \u00e9s mikroszolg\u00e1ltat\u00e1sok eset\u00e9ben s\u00fcrget\u0151 sz\u00fcks\u00e9g van a kezdeti ind\u00edt\u00e1si id\u0151 cs\u00f6kkent\u00e9s\u00e9re, a mem\u00f3riafogyaszt\u00e1s m\u00e9rs\u00e9kl\u00e9s\u00e9re, \u00e9s arra, hogy a fejleszt\u00e9si folyamat k\u00e9nyelmesebb \u00e9s \u00e9lvezetesebb legyen. Az ut\u00f3bbi \u00e9vekben a Java sz\u00e1mos fejleszt\u00e9st eszk\u00f6z\u00f6lt, p\u00e9ld\u00e1ul a kont\u00e9nerek sz\u00e1m\u00e1ra kifejlesztett ergonomikai funkci\u00f3kat \u00e9s egyebeket. Ennek ellen\u00e9re a Java megfelel\u0151 m\u0171k\u00f6dtet\u00e9se kont\u00e9nerben tov\u00e1bbra is neh\u00e9zs\u00e9gekbe \u00fctk\u00f6zik. Ez\u00e9rt el\u0151sz\u00f6r n\u00e9h\u00e1ny bels\u0151 neh\u00e9zs\u00e9get fogunk megvizsg\u00e1lni, amelyek k\u00fcl\u00f6n\u00f6sen \u00e9lesebben jelentkeznek a kont\u00e9neralap\u00fa Java-alkalmaz\u00e1sok fejleszt\u00e9se sor\u00e1n.<\/p>\n

El\u0151sz\u00f6r n\u00e9zz\u00fck meg a t\u00f6rt\u00e9netet.<\/p>\n

\"Hogyan<\/p>\n

Sz\u00e1lak \u00e9s kont\u00e9nerek<\/h3>\n

\nA 8u131-es verzi\u00f3t\u00f3l kezdve a Java nagyj\u00e1b\u00f3l elkezdte t\u00e1mogatni a kont\u00e9nereket a funkcion\u00e1lis ergon\u00f3mi\u00e1ban t\u00f6rt\u00e9nt fejleszt\u00e9sek r\u00e9v\u00e9n. K\u00fcl\u00f6n\u00f6sen, mostant\u00f3l a JVM tudja, h\u00e1ny processzormag fut \u00e9ppen, \u00e9s ennek megfelel\u0151en tudja optimaliz\u00e1lni a sz\u00e1lpools \u2013 \u00e1ltal\u00e1ban a fork\/join poolokat. Ez k\u00e9ts\u00e9gtelen\u00fcl nagyszer\u0171, de tegy\u00fck fel, hogy van egy hagyom\u00e1nyos webalkalmaz\u00e1sunk, amely HTTP-szervleteket haszn\u00e1l, \u00e9s Tomcat-ban, Jetty-ben \u00e9s hasonl\u00f3kban fut. Ennek eredm\u00e9nyek\u00e9nt ez az alkalmaz\u00e1s minden egyes k\u00e9r\u00e9shez k\u00fcl\u00f6n sz\u00e1lat biztos\u00edt, \u00e9s lehet\u0151v\u00e9 teszi, hogy ez a sz\u00e1l blokkolva legyen, am\u00edg I\/O m\u0171veletekre v\u00e1r, p\u00e9ld\u00e1ul adatb\u00e1zis, f\u00e1jlok vagy m\u00e1s szolg\u00e1ltat\u00e1sok el\u00e9r\u00e9sekor. Ez azt jelenti, hogy egy ilyen alkalmaz\u00e1s m\u00e9rete nem a rendelkez\u00e9sre \u00e1ll\u00f3 magok sz\u00e1m\u00e1t\u00f3l f\u00fcgg, hanem az egyidej\u0171 k\u00e9r\u00e9sek sz\u00e1m\u00e1t\u00f3l. Ezenk\u00edv\u00fcl ez azt jelenti, hogy a Kubernetes kv\u00f3t\u00e1k vagy korl\u00e1tok a magok sz\u00e1m\u00e1nak tekintet\u00e9ben nem sokat seg\u00edtenek, \u00e9s a v\u00e9g\u00e9n throttlinghoz vezet.<\/p>\n

Mem\u00f3riakimer\u00fcl\u00e9s<\/h3>\n

\nA sz\u00e1lak a mem\u00f3ria. \u00c9s a bels\u0151 kont\u00e9ner mem\u00f3ria korl\u00e1toz\u00e1sok nem csodaszer. Csak kezdj el n\u00f6velni az alkalmaz\u00e1sok \u00e9s sz\u00e1lak sz\u00e1m\u00e1t, \u00e9s el\u0151bb-ut\u00f3bb kritikus n\u00f6veked\u00e9ssel tal\u00e1lkozol a v\u00e1lt\u00e1sok gyakoris\u00e1g\u00e1ban, ez pedig teljes\u00edtm\u00e9nyroml\u00e1shoz vezet. Ezenk\u00edv\u00fcl, ha az alkalmaz\u00e1s hagyom\u00e1nyos mikroszolg\u00e1ltat\u00e1s-keretrendszereket haszn\u00e1l, vagy adatb\u00e1zishoz csatlakozik, vagy cache-el\u00e9st alkalmaz, vagy valahogy tov\u00e1bbi mem\u00f3ri\u00e1t fogyaszt, akkor nyilv\u00e1nval\u00f3an sz\u00fcks\u00e9ged van egy eszk\u00f6zre, amely lehet\u0151v\u00e9 teszi, hogy belen\u00e9zz a JVM-be, \u00e9s megn\u00e9zd, hogyan kezeli azt a mem\u00f3ri\u00e1t, an\u00e9lk\u00fcl, hogy mag\u00e1t a JVM-et meg\u00f6leln\u00e9d (p\u00e9ld\u00e1ul XX:+UseCGroupMemoryLimitForHeap). \u00c9s annak ellen\u00e9re, hogy a Java 9-t\u0151l kezdve a JVM megtanult cgroups-ot kezelni \u00e9s ennek megfelel\u0151en alkalmazkodni, a mem\u00f3ria fenntart\u00e1sa \u00e9s kezel\u00e9se tov\u00e1bbra is meglehet\u0151sen bonyolult feladat.<\/p>\n

Kv\u00f3t\u00e1k \u00e9s korl\u00e1tok<\/h3>\n

\nA Java 11-ben megjelent a CPU-kv\u00f3t\u00e1k t\u00e1mogat\u00e1sa (p\u00e9ld\u00e1ul PreferContainerQuotaForCPUCount). A Kubernetes szint\u00e9n t\u00e1mogatja a korl\u00e1tokat \u00e9s kv\u00f3t\u00e1kat. Igen, ennek van \u00e9rtelme, de ha az alkalmaz\u00e1s \u00fajra kiker\u00fcl a kijel\u00f6lt kv\u00f3t\u00e1kb\u00f3l, akkor ism\u00e9t azon a ponton vagyunk, hogy a m\u00e9ret \u2013 a hagyom\u00e1nyos Java-alkalmaz\u00e1sok eset\u00e9n \u2013 a magok sz\u00e1m\u00e1val, valamint minden k\u00e9r\u00e9shez k\u00fcl\u00f6n sz\u00e1l biztos\u00edt\u00e1s\u00e1val van meghat\u00e1rozva, \u00edgy ennek nem sok \u00e9rtelme van.
\nEzenk\u00edv\u00fcl, ha kv\u00f3t\u00e1kat \u00e9s limiteket vagy a Kubernetes alapj\u00e1t k\u00e9pez\u0151 platform horizont\u00e1lis (scale-out) sk\u00e1l\u00e1z\u00e1si funkci\u00f3it haszn\u00e1ljuk, a probl\u00e9ma nem old\u00f3dik meg mag\u00e1t\u00f3l. Csak t\u00f6bb er\u0151forr\u00e1st k\u00f6lt\u00fcnk el az alapvet\u0151 probl\u00e9ma megold\u00e1s\u00e1ra, vagy v\u00e9g\u00fcl t\u00falfogyaszt\u00e1sra jutunk. Ha ez egy nagy terhel\u00e9s\u0171 rendszer egy nyilv\u00e1nos felh\u0151ben, akkor szinte biztos, hogy t\u00f6bb er\u0151forr\u00e1st haszn\u00e1lunk, mint amennyire val\u00f3j\u00e1ban sz\u00fcks\u00e9g van.<\/p>\n

\u00c9s mit lehet kezdeni mindezekkel?<\/h3>\n

\nHa egyszer\u0171en akarjuk, aszinkron \u00e9s nem blokkol\u00f3 bemeneti-kimeneti k\u00f6nyvt\u00e1rakat \u00e9s keretrendszereket kell haszn\u00e1lni, mint p\u00e9ld\u00e1ul a Netty, Vert.x<\/a><\/noindex> vagy Akka. Ezek sokkal jobban alkalmasak a kont\u00e9nerekben val\u00f3 munk\u00e1ra reakt\u00edv term\u00e9szet\u00fck miatt. A nem blokkol\u00f3 bemeneti-kimeneti seg\u00edts\u00e9g\u00e9vel ugyanaz a sz\u00e1l t\u00f6bb p\u00e1rhuzamos k\u00e9r\u00e9s feldolgoz\u00e1s\u00e1ra is k\u00e9pes. Am\u00edg egy k\u00e9r\u00e9s a bemeneti-kimeneti eredm\u00e9nyekre v\u00e1r, a kezel\u0151 sz\u00e1l felold\u00f3dik \u00e9s \u00e1tv\u00e1lt egy m\u00e1sik k\u00e9r\u00e9sre. Amikor a bemeneti-kimeneti eredm\u00e9nyek v\u00e9gre meg\u00e9rkeznek, az els\u0151 k\u00e9r\u00e9s feldolgoz\u00e1sa folytat\u00f3dik. A k\u00e9r\u00e9sek feldolgoz\u00e1s\u00e1nak v\u00e1ltogat\u00e1s\u00e1val ugyanazon sz\u00e1l keretein bel\u00fcl cs\u00f6kkenteni lehet a sz\u00e1lak sz\u00e1m\u00e1t \u00e9s cs\u00f6kkenteni a k\u00e9r\u00e9sek feldolgoz\u00e1s\u00e1hoz sz\u00fcks\u00e9ges er\u0151forr\u00e1sokat.<\/p>\n

Nem blokkol\u00f3 bemeneti-kimeneti eset\u00e9n a magok sz\u00e1ma kulcsfontoss\u00e1g\u00fa param\u00e9terr\u00e9 v\u00e1lik, mivel ez hat\u00e1rozza meg a p\u00e1rhuzamosan v\u00e9grehajthat\u00f3 bemeneti-kimeneti sz\u00e1lak sz\u00e1m\u00e1t. Ha helyesen haszn\u00e1lj\u00e1k, ez lehet\u0151v\u00e9 teszi a terhek hat\u00e9kony eloszt\u00e1s\u00e1t a magok k\u00f6z\u00f6tt, \u00e9s nagyobb terhel\u00e9sek kezel\u00e9s\u00e9t kevesebb er\u0151forr\u00e1ssal.<\/p>\n

Hogyan, \u00e9s ennyi?<\/h3>\n

\nNem, van m\u00e9g valami. A reakt\u00edv programoz\u00e1s seg\u00edt jobban kihaszn\u00e1lni az er\u0151forr\u00e1sokat, de ennek is van k\u00f6lts\u00e9ge. K\u00fcl\u00f6n\u00f6sen a k\u00f3dot a nem blokkol\u00e1s elvei szerint kell \u00e1t\u00edrni, \u00e9s ker\u00fclni kell a bemeneti-kimeneti sz\u00e1lak blokkol\u00e1s\u00e1t. Ez egy teljesen m\u00e1s fejleszt\u00e9si \u00e9s v\u00e9grehajt\u00e1si modell. B\u00e1r rengeteg hasznos k\u00f6nyvt\u00e1r \u00e1ll rendelkez\u00e9sre, ennek ellen\u00e9re ez radik\u00e1lis v\u00e1ltoz\u00e1st jelent a megszokott gondolkod\u00e1sm\u00f3dhoz k\u00e9pest.<\/p>\n

El\u0151sz\u00f6r is, meg kell tanulnod olyan k\u00f3dot \u00edrni, amely aszinkron m\u00f3don fut. Mihelyt elkezded haszn\u00e1lni a blokkol\u00e1s n\u00e9lk\u00fcli bemeneti-kimeneti funkci\u00f3t, egy\u00e9rtelm\u0171en meg kell hat\u00e1roznod, hogy mi t\u00f6rt\u00e9njen, amikor v\u00e1lasz \u00e9rkezik a k\u00e9r\u00e9sre. T\u00f6bb\u00e9 nem blokkolhatod \u00e9s v\u00e1rhatsz. Ehelyett haszn\u00e1lhatsz visszah\u00edv\u00e1sokat, reakt\u00edv programoz\u00e1st vagy folytonoss\u00e1got. De ez m\u00e9g nem minden: a blokkol\u00e1s n\u00e9lk\u00fcli bemeneti-kimenet haszn\u00e1lat\u00e1hoz blokkol\u00e1s n\u00e9lk\u00fcli kiszolg\u00e1l\u00f3kra \u00e9s kliensekre van sz\u00fcks\u00e9ged, \u00e9s lehet\u0151leg minden\u00fctt. HTTP eset\u00e9n egyszer\u0171 a helyzet, de vannak adatb\u00e1zisok, f\u00e1jlrendszerek \u00e9s m\u00e9g sok egy\u00e9b is.<\/p>\n

B\u00e1r a tot\u00e1lis \u00e1tj\u00e1rhat\u00f3 reaktivit\u00e1s maxim\u00e1lis hat\u00e9konys\u00e1got biztos\u00edt, az ilyen v\u00e1lt\u00e1sokat neh\u00e9z lehet gyakorlatba \u00fcltetni. Ez\u00e9rt sz\u00fcks\u00e9gess\u00e9 v\u00e1lik a reakt\u00edv \u00e9s imperat\u00edv k\u00f3d \u00f6tv\u00f6z\u00e9se.<\/p>\n

    \n
  1. Hat\u00e9konyan haszn\u00e1lni az er\u0151forr\u00e1sokat a szoftverrendszer legnagyobb terhelts\u00e9g\u0171 ter\u00fcletein;<\/li>\n
  2. Egyszer\u0171bb st\u00edlus\u00fa k\u00f3dot alkalmazni a rendszer t\u00f6bbi r\u00e9sz\u00e9n.<\/li>\n<\/ol>\n

    <\/p>\n

    Bemutatjuk a Quarkus-t<\/h3>\n

    \nMag\u00e1ban a Quarkus l\u00e9nyeg\u00e9ben az imperat\u00edv \u00e9s reakt\u00edv modellek egyes\u00edt\u00e9se egyetlen fut\u00e1si k\u00f6rnyezet keretein bel\u00fcl.<\/p>\n

    A Quarkus alapj\u00e1t a Vert.x \u00e9s a Netty k\u00e9pezi, amelyen egy sor reakt\u00edv keretrendszer \u00e9s kieg\u00e9sz\u00edt\u0151 m\u0171k\u00f6dik, amelyek seg\u00edtik a fejleszt\u0151ket. A Quarkus nemcsak HTTP-mikroszolg\u00e1ltat\u00e1sok, hanem esem\u00e9nyvez\u00e9relt architekt\u00far\u00e1k \u00e9p\u00edt\u00e9s\u00e9re is szolg\u00e1l. Reakt\u00edv term\u00e9szet\u00e9nek k\u00f6sz\u00f6nhet\u0151en rendk\u00edv\u00fcl hat\u00e9konyan m\u0171k\u00f6dik \u00fczenetv\u00e1lt\u00f3 rendszerekkel (Apache Kafka, AMQP stb.).<\/p>\n

    A tr\u00fckk az, hogyan lehet ugyanazt a reakt\u00edv motort haszn\u00e1lni ak\u00e1r imperat\u00edv, ak\u00e1r reakt\u00edv k\u00f3dhoz.<\/p>\n

    \"Hogyan<\/p>\n

    A Quarkus kiv\u00e1l\u00f3an kezeli ezt. A v\u00e1laszt\u00e1s az imperat\u00edv \u00e9s reakt\u00edv megk\u00f6zel\u00edt\u00e9s k\u00f6z\u00f6tt egy\u00e9rtelm\u0171 \u2013 mindkett\u0151h\u00f6z a reakt\u00edv magot haszn\u00e1ljuk. Nagyon seg\u00edt a gyors, nem blokkol\u00f3 k\u00f3d, amely szinte mindent kezel, ami az esem\u00e9nyk\u00f6r (event-loop thread, m\u00e1s n\u00e9ven IO thread) \u00e1tfolyik. De ha klasszikus REST alkalmaz\u00e1sokkal vagy kliensoldali alkalmaz\u00e1sokkal dolgozik, a Quarkus rendelkezik egy imperat\u00edv programoz\u00e1si modellel. P\u00e9ld\u00e1ul a Quarkus HTTP-t\u00e1mogat\u00e1sa a nem blokkol\u00f3 \u00e9s reakt\u00edv motor (Eclipse Vert.x \u00e9s Netty) haszn\u00e1lat\u00e1n alapul. Minden HTTP-k\u00e9r\u00e9s, amelyet az alkalmaz\u00e1sa kap, el\u0151sz\u00f6r az esem\u00e9nyk\u00f6r\u00f6n (IO Thread) halad \u00e1t, majd a k\u00e9rd\u00e9sek kezel\u00e9s\u00e9\u00e9rt felel\u0151s k\u00f3dhoz ker\u00fcl. A k\u00e9r\u00e9skezel\u0151 k\u00f3d a c\u00e9lpontt\u00f3l f\u00fcgg\u0151en k\u00fcl\u00f6n sz\u00e1l keretein bel\u00fcl h\u00edvhat\u00f3 meg (\u00fan. worker thread, amely servlet \u00e9s Jax-RS eset\u00e9n alkalmazott), vagy az alapvet\u0151 bemeneti\/kimeneti sz\u00e1lat haszn\u00e1lja (reakt\u00edv \u00fatvonal, reactive route).<\/p>\n

    \"Hogyan<\/p>\n

    A k\u00e9relmezett \u00fczenet\u00e1tviteli rendszerekhez nem blokkol\u00f3 klienseket haszn\u00e1lunk, amelyek a Vert.x motor felett m\u0171k\u00f6dnek. \u00cdgy hat\u00e9konyan k\u00fcldheti, fogadhatja \u00e9s feldolgozhatja az \u00fczeneteket a messaging middleware rendszerekb\u0151l.<\/p>\n

    A weboldalon Quarkus.io<\/a><\/noindex> \u00d6sszegy\u0171jt\u00f6tt\u00fcnk n\u00e9h\u00e1ny j\u00f3 \u00fatmutat\u00f3t, amelyek seg\u00edtenek a Quarkus haszn\u00e1lat\u00e1nak megkezd\u00e9s\u00e9ben:<\/p>\n