{"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\/da\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","title":{"rendered":"Hvordan Quarkus kombinerer imperativ og reaktiv programmering","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I \u00e5r planl\u00e6gger vi at fokusere p\u00e5 emner omkring containere, Cloud-Native Java<\/a><\/noindex> og Kubernetes<\/a><\/noindex>. En logisk forts\u00e6ttelse af disse emner vil v\u00e6re en fort\u00e6lling om frameworket Quarkus, som allerede er blevet diskuteret<\/a><\/noindex> p\u00e5 Habr. Dagens artikel handler ikke s\u00e5 meget om det, der kaldes \"subatomar superhurtig Java\", men om de muligheder, som Quarkus bringer til Enterprise.<\/p>\n

\"Hvordan
\n
\nJava og JVM er fortsat ekstremt popul\u00e6re, men i arbejdet med serverless teknologier og cloud-orienterede mikrotjenester bliver Java og andre sprog til JVM anvendt mindre og mindre, da de optager for meget plads i hukommelsen og indl\u00e6ses for langsomt, hvilket g\u00f8r dem utilstr\u00e6kkelige til brug med kortvarige containere. Heldigvis begynder denne situation at \u00e6ndre sig takket v\u00e6re Quarkus.
\n<\/a><\/noindex><\/p>\n

Superhurtig subatomar Java er n\u00e5et til et nyt niveau!<\/h3>\n

\n42 udgivelser, 8 m\u00e5neders samarbejde fra f\u00e6llesskabet og 177 fantastiske udviklere \u2013 resultatet af dette var udgivelsen i november 2019 Quarkus 1.0<\/a><\/noindex>, en udgivelse, der markerer en vigtig milep\u00e6l i projektets udvikling og tilbyder en masse fantastiske funktioner og muligheder (l\u00e6s mere om dem i annonceringen<\/a><\/noindex>).<\/p>\n

I dag vil vi fort\u00e6lle, hvordan Quarkus kombinerer modellerne for imperativ og reaktiv programmering baseret p\u00e5 et enkelt reaktivt kerne. Vi vil starte med et kort tilbageblik p\u00e5 historien og derefter grundigt analysere, hvad dualismen i Quarkus' reaktive kerne indeb\u00e6rer, og hvordan Java<\/a><\/noindex>-udviklere kan drage fordel af disse fordele.<\/p>\n

Mikrotjenester<\/a><\/noindex>, begivenhedsdrevne arkitekturer<\/a><\/noindex> og serverless<\/a><\/noindex>-funktioner \u2013 alt dette er i \u00f8jeblikket, hvad man kalder en opadg\u00e5ende tendens. For nylig er det blevet meget lettere og mere tilg\u00e6ngeligt at skabe cloud-orienterede arkitekturer, men der er stadig problemer - is\u00e6r for Java-udviklere. For eksempel, i tilf\u00e6lde af serverless-funktioner og mikrotjenester er der et presserende behov for at reducere opstartstiden, mindske hukommelsesforbruget og g\u00f8re deres udvikling mere praktisk og behagelig. Java har i de senere \u00e5r indf\u00f8rt adskillige forbedringer, s\u00e5som ergonomisk st\u00f8tte til containere m.m. Men det er stadig en udfordring at f\u00e5 Java til at fungere ordentligt i en container. Derfor vil vi starte med at se p\u00e5 nogle af de indre kompleksiteter i Java, som viser sig s\u00e6rlig tydeligt i udviklingen af containerbaserede Java-applikationer.<\/p>\n

Lad os f\u00f8rst se p\u00e5 historien.<\/p>\n

\"Hvordan<\/p>\n

Tr\u00e5de og containere<\/h3>\n

\nFra version 8u131 begyndte Java mere eller mindre at underst\u00f8tte containere ved hj\u00e6lp af forbedringer inden for ergonomik. Is\u00e6r ved JVM i dag ved, hvor mange CPU-kerner den k\u00f8rer p\u00e5, og kan derfor tilpasse tr\u00e5dpoolerne \u2013 typisk fork\/join pooler. Uden tvivl er det fantastisk, men lad os antage, at vi har en traditionel webapplikation, der bruger HTTP-servlets og k\u00f8rer i Tomcat, Jetty osv. Som f\u00f8lge heraf vil denne applikation give hver anmodning en separat tr\u00e5d og tillade den at blokere denne tr\u00e5d, mens den venter p\u00e5 I\/O-operationer, for eksempel ved adgang til databaser, filer eller andre tjenester. Det betyder, at st\u00f8rrelsen p\u00e5 s\u00e5dan en applikation ikke afh\u00e6nger af antallet af tilg\u00e6ngelige kerner, men af antallet af samtidige anmodninger. Desuden betyder det, at kvoter eller gr\u00e6nser i Kubernetes for antallet af kerner ikke vil hj\u00e6lpe meget, og det hele ender med throttling.<\/p>\n

Hukommelsesudt\u00f8mning<\/h3>\n

\nTr\u00e5de er hukommelse. Og begr\u00e6nsninger p\u00e5 hukommelse inde i containere er bestemt ikke en panacea. Bare begynd at \u00f8ge antallet af applikationer og tr\u00e5de, og f\u00f8r eller senere vil du st\u00f8de p\u00e5 en kritisk stigning i skiftfrekvenserne og som f\u00f8lge heraf en degradation af ydeevnen. Derudover, hvis applikationen bruger traditionelle mikrotjenestearkitekturer eller tilslutter sig en database, eller aktiverer caching, eller p\u00e5 anden m\u00e5de bruger mere hukommelse, s\u00e5 har du helt sikkert brug for et v\u00e6rkt\u00f8j, der lader dig kigge ind i JVM og se, hvordan den h\u00e5ndterer hukommelse, og samtidig ikke dr\u00e6ber selve JVM'en (for eksempel XX:+UseCGroupMemoryLimitForHeap). Og selvom JVM siden Java 9 har l\u00e6rt at opfatte cgroups og tilpasse sig derefter, er reservation og h\u00e5ndtering af hukommelse stadig en ret kompleks opgave.<\/p>\n

Kvoter og gr\u00e6nser<\/h3>\n

\nJava 11 introducerede underst\u00f8ttelse af CPU-kvoter (som PreferContainerQuotaForCPUCount). Kubernetes tilbyder ogs\u00e5 st\u00f8tte for gr\u00e6nser og kvoter. Ja, alt dette giver mening, men hvis applikationen endnu en gang overskrider den tildelte kvote, kommer vi tilbage til, at st\u00f8rrelsen \u2013 som med traditionelle Java-applikationer \u2013 bestemmes af antallet af kerner og tildelingen af en separat tr\u00e5d til hver anmodning, hvilket betyder, at det hele kun har lidt v\u00e6rdi.
\nDesuden, hvis man bruger kvoter og gr\u00e6nser eller funktioner til horisontal (scale-out) skalering af platformen, der ligger til grund for Kubernetes, l\u00f8ser problemet sig ikke af sig selv. Vi bruger blot flere ressourcer p\u00e5 at l\u00f8se det oprindelige problem, eller vi ender med at overskride ressourcerne. Og hvis dette er et h\u00f8jt belastet system i et offentligt tilg\u00e6ngeligt cloud-milj\u00f8, begynder vi n\u00e6sten med sikkerhed at bruge flere ressourcer, end der faktisk er n\u00f8dvendigt.<\/p>\n

Og hvad skal man g\u00f8re med alt dette?<\/h3>\n

\nHvis vi siger det enkelt, s\u00e5 brug asynkrone og ikke-blokerende input-output biblioteker og frameworks som Netty, Vert.x<\/a><\/noindex> eller Akka. De er meget bedre egnet til at arbejde i containere p\u00e5 grund af deres reaktive natur. Takket v\u00e6re ikke-blokerende input-output kan den samme tr\u00e5d h\u00e5ndtere flere samtidige foresp\u00f8rgsler samtidigt. Mens \u00e9n foresp\u00f8rgsel venter p\u00e5 input-output-resultater, frig\u00f8res den tr\u00e5d, der behandler den, og g\u00e5r i gang med en anden foresp\u00f8rgsel. Og n\u00e5r input-output-resultaterne endelig kommer, forts\u00e6tter behandlingen af den f\u00f8rste foresp\u00f8rgsel. Ved at skifte mellem behandling af foresp\u00f8rgsler inden for den samme tr\u00e5d kan det samlede antal tr\u00e5de reduceres, og ressourceforbruget til behandling af foresp\u00f8rgslerne mindskes.<\/p>\n

Ved ikke-blokerende input-output bliver antallet af kerner en n\u00f8glev\u00e6rdi, da det bestemmer antallet af input-output tr\u00e5de, der kan udf\u00f8res parallelt. Ved korrekt brug g\u00f8r dette det muligt effektivt at fordele belastningen mellem kernerne og h\u00e5ndtere h\u00f8jere belastninger med f\u00e6rre ressourcer.<\/p>\n

Hvordan, er det hele?<\/h3>\n

\nNej, der er mere. Reaktiv programmering hj\u00e6lper med at udnytte ressourcerne bedre, men det har ogs\u00e5 sin pris. Is\u00e6r skal koden skrives om i henhold til principperne for ikke-blokering og undg\u00e5 blokerende input-output tr\u00e5de. Og det er en helt anden model for udvikling og udf\u00f8relse. Selvom der er mange nyttige biblioteker her, er det stadig en radikal \u00e6ndring i den s\u00e6dvanlige tankegang.<\/p>\n

For det f\u00f8rste skal du l\u00e6re at skrive kode, der udf\u00f8res asynkront. N\u00e5r du begynder at bruge ikke-blokerende input-output, skal du eksplicit angive, hvad der skal ske, n\u00e5r et svar modtages. At blokere og vente fungerer ikke l\u00e6ngere. I stedet kan du sende tilbagekald, bruge reaktiv programmering eller forts\u00e6ttelse. Men det er ikke alt: For at bruge ikke-blokerende input-output har du brug for ikke-blokerende servere og klienter, gerne overalt. I tilf\u00e6lde af HTTP er det enkelt, men der er ogs\u00e5 databaser, filsystemer og meget mere.<\/p>\n

Og selvom total skalerbar reaktivitet giver maksimal effektivitet, kan det v\u00e6re sv\u00e6rt at ford\u00f8je denne \u00e6ndring i praksis. Derfor bliver muligheden for at kombinere reaktiv og imperativ kode en n\u00f8dvendighed for at:<\/p>\n

    \n
  1. Effektivt udnytte ressourcerne i de mest belastede retninger i software-systemet;<\/li>\n
  2. Brug en enklere stil i resten af koden.<\/li>\n<\/ol>\n

    <\/p>\n

    Pr\u00e6senterer Quarkus<\/h3>\n

    \nOg det er essensen af Quarkus \u2013 at kombinere reaktive og imperative modeller inden for \u00e9n k\u00f8replatform.<\/p>\n

    Quarkus er bygget p\u00e5 Vert.x og Netty, der oven p\u00e5 det underst\u00f8tter en r\u00e6kke reaktive rammer og udvidelser for at hj\u00e6lpe udvikleren. Quarkus er designet til at bygge ikke kun HTTP-mikrotjenester, men ogs\u00e5 event-drevne arkitekturer. Takket v\u00e6re sin reaktive natur fungerer det meget effektivt med beskedsystemer (Apache Kafka, AMQP osv.).<\/p>\n

    Fintippet ligger i, hvordan man bruger den samme reaktive motor til b\u00e5de imperativ og reaktiv kode.<\/p>\n

    \"Hvordan<\/p>\n

    Quarkus h\u00e5ndterer dette fremragende. Valget mellem imperativt og reaktivt er indlysende \u2013 at bruge reaktorkernen til begge dele. Det, det hj\u00e6lper meget med, er hurtig ikke-blokerende kode, der h\u00e5ndterer n\u00e6sten alt, hvad der passerer gennem event-loop-tr\u00e5den (event-loop thread, ogs\u00e5 kendt som IO-tr\u00e5den). Men hvis du har klassiske REST-applikationer eller klient-side applikationer, er der en imperativ programmeringsmodel klar til Quarkus. For eksempel er HTTP-underst\u00f8ttelse i Quarkus bygget p\u00e5 brugen af en ikke-blokerende og reaktiv motor (Eclipse Vert.x og Netty). Alle HTTP-anmodninger, der modtages af din applikation, sendes f\u00f8rst gennem event-loop (IO-tr\u00e5den), f\u00f8r de sendes til den del af koden, der h\u00e5ndterer anmodninger. Afh\u00e6ngigt af destinationen kan anmodningsstyringskoden kaldes inden for en separat tr\u00e5d (den s\u00e5kaldte worker thread, der bruges i tilf\u00e6lde af servlets og Jax-RS) eller bruge den oprindelige input-output-str\u00f8m (den reaktive rute).<\/p>\n

    \"Hvordan<\/p>\n

    For connectorer til beskedoverf\u00f8rselsystemer anvendes ikke-blokerende klienter, der k\u00f8rer oven p\u00e5 Vert.x-motoren. Derfor kan du effektivt sende, modtage og behandle beskeder fra messaging middleware-systemer.<\/p>\n

    P\u00e5 hjemmesiden Quarkus.io<\/a><\/noindex> vi har samlet flere gode vejledninger, der kan hj\u00e6lpe dig med at komme i gang med Quarkus:<\/p>\n