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

I \u00e5r planerar vi att p\u00e5 allvar utveckla \u00e4mnena kring containrar, Cloud-Native Java<\/a><\/noindex> och Kubernetes<\/a><\/noindex>. En logisk forts\u00e4ttning p\u00e5 dessa \u00e4mnen blir att ber\u00e4tta om ramverket Quarkus, som redan diskuterats<\/a><\/noindex> p\u00e5 Habr\u00e9. Dagens artikel handlar inte s\u00e5 mycket om strukturen av \"subatom\u00e4r superhj\u00e4lpsam Java\", utan om de m\u00f6jligheter som Quarkus f\u00f6r med sig i f\u00f6retagssammanhang.<\/p>\n

\"Hur
\n
\nJava och JVM \u00e4r fortfarande extremt popul\u00e4ra, men vid arbete med serverl\u00f6sa teknologier och molnorienterade mikrotj\u00e4nster anv\u00e4nds Java och andra spr\u00e5k f\u00f6r JVM alltmer s\u00e4llan, eftersom de tar f\u00f6r mycket minne och har f\u00f6r l\u00e5ng laddningstid, vilket g\u00f6r dem mindre l\u00e4mpliga f\u00f6r kortlivade containrar. Lyckligtvis b\u00f6rjar denna situation f\u00f6r\u00e4ndras tack vare Quarkus.
\n<\/a><\/noindex><\/p>\n

Subatom\u00e4r superhj\u00e4lpsam Java har n\u00e5tt en ny niv\u00e5!<\/h3>\n

\n42 versioner, 8 m\u00e5naders arbete fr\u00e5n gemenskapen och 177 fantastiska utvecklare \u2013 resultatet av allt detta blev lanseringen av Quarkus 1.0<\/a><\/noindex>, en release som markerar en viktig milep\u00e6l i projektets utveckling och erbjuder en massa coola funktioner och m\u00f6jligheter (mer om dem kan l\u00e4sas i annonsen<\/a><\/noindex>).<\/p>\n

Idag kommer vi att ber\u00e4tta hur Quarkus f\u00f6renar modeller av imperativ och reaktiv programmering baserat p\u00e5 en enhetlig reaktiv k\u00e4rna. Vi b\u00f6rjar med en kort tillbakablick p\u00e5 historien och g\u00e5r sedan igenom i detalj vad dualiteten hos Quarks reaktiva k\u00e4rna inneb\u00e4r och hur Java<\/a><\/noindex>-utvecklare kan dra nytta av dessa f\u00f6rdelar.<\/p>\n

Mikrotj\u00e4nster<\/a><\/noindex>, med h\u00e4ndelsestyrd arkitektur<\/a><\/noindex> och serverl\u00f6sa<\/a><\/noindex>-funktioner \u2013 allt detta \u00e4r idag, som man s\u00e4ger, p\u00e5 uppg\u00e5ng. P\u00e5 senare tid har skapandet av molnorienterade arkitekturer blivit mycket enklare och mer tillg\u00e4ngligt, men problemen kvarst\u00e5r \u2013 s\u00e4rskilt f\u00f6r Java-utvecklare. Till exempel, n\u00e4r det g\u00e4ller serverl\u00f6sa funktioner och mikrotj\u00e4nster finns det ett akut behov av att minska starttiden, minska minnesanv\u00e4ndningen och g\u00f6ra deras utveckling mer praktisk och trevlig. Java har under de senaste \u00e5ren gjort flera f\u00f6rb\u00e4ttringar, s\u00e5som f\u00f6rb\u00e4ttrad ergonomik f\u00f6r containrar och s\u00e5 vidare. Men det \u00e4r fortfarande inte l\u00e4tt att f\u00e5 Java att fungera normalt i en container. D\u00e4rf\u00f6r b\u00f6rjar vi med att titta p\u00e5 n\u00e5gra av de interna sv\u00e5righeterna med Java, som s\u00e4rskilt tydligt uppst\u00e5r vid utveckling av containerorienterade Java-applikationer.<\/p>\n

L\u00e5t oss b\u00f6rja med historien.<\/p>\n

\"Hur<\/p>\n

Str\u00f6mmar och beh\u00e5llare<\/h3>\n

\nFr\u00e5n och med version 8u131 har Java mer eller mindre b\u00f6rjat st\u00f6dja beh\u00e5llare genom f\u00f6rb\u00e4ttringar i ergonomifunktionaliteten. Specifikt vet JVM nu hur m\u00e5nga processork\u00e4rnor den k\u00f6rs p\u00e5 och kan d\u00e4rmed anpassa tr\u00e5dpoolerna \u2013 vanligtvis fork\/join-pooler. Det \u00e4r s\u00e4kert bra, men anta att vi har en traditionell webbapplikation som anv\u00e4nder HTTP-servlets och k\u00f6rs i Tomcat, Jetty och liknande. Som ett resultat kommer denna applikation att tilldela en separat tr\u00e5d f\u00f6r varje beg\u00e4ran och l\u00e5ta den blockera denna tr\u00e5d medan den v\u00e4ntar p\u00e5 in- och utoperationer, till exempel vid \u00e5tkomst till databaser, filer eller andra tj\u00e4nster. Det inneb\u00e4r att storleken p\u00e5 en s\u00e5dan applikation beror inte p\u00e5 antalet tillg\u00e4ngliga k\u00e4rnor utan p\u00e5 antal samtidiga beg\u00e4rningar. Dessutom betyder detta att kvoter eller gr\u00e4nser i Kubernetes f\u00f6r antalet k\u00e4rnor knappt kommer att hj\u00e4lpa, och i slut\u00e4ndan kommer det att sluta med d\u00e4mpning.<\/p>\n

Minnesutarmning<\/h3>\n

\nTr\u00e5dar \u00e4r minne. Och interna beh\u00e5llarbegr\u00e4nsningar f\u00f6r minne \u00e4r l\u00e5ngt ifr\u00e5n en universal l\u00f6sning. B\u00f6rja bara \u00f6ka antalet applikationer och tr\u00e5dar, och f\u00f6rr eller senare kommer du att st\u00f6ta p\u00e5 en kritisk \u00f6kning av v\u00e4xelfrekvensen och d\u00e4rmed en nedg\u00e5ng i prestanda. Dessutom, om applikationen anv\u00e4nder traditionella mikrotj\u00e4nstarkitekturer eller ansluter till databaser, eller anv\u00e4nder caching, eller p\u00e5 n\u00e5got annat s\u00e4tt ytterligare f\u00f6rbrukar minne, beh\u00f6ver du uppenbarligen ett verktyg som l\u00e5ter dig titta in i JVM och se hur den hanterar minnet utan att skada sj\u00e4lva JVM (till exempel XX:+UseCGroupMemoryLimitForHeap). \u00c4ven om JVM fr\u00e5n och med Java 9 har l\u00e4rt sig att ta h\u00e4nsyn till cgroups och anpassa sig d\u00e4refter, \u00e4r minnesreservation och hantering fortfarande en ganska komplicerad sak.<\/p>\n

Kvoter och gr\u00e4nser<\/h3>\n

\nJava 11 introducerade st\u00f6d f\u00f6r CPU-kvoter (som PreferContainerQuotaForCPUCount). Kubernetes erbjuder ocks\u00e5 st\u00f6d f\u00f6r gr\u00e4nser och kvoter. Ja, allt detta ger mening, men om applikationen igen \u00f6verskrider den tilldelade kvoten, \u00e5terkommer vi till att storleken \u2013 som i fallet med traditionella Java-applikationer \u2013 best\u00e4ms av antalet k\u00e4rnor och tilldelning av en separat tr\u00e5d f\u00f6r varje beg\u00e4ran, vilket inneb\u00e4r att det inte \u00e4r mycket vits med allt detta.
\nDessutom, om vi anv\u00e4nder kvoter och gr\u00e4nser eller funktioner f\u00f6r horisontell (scale-out) skalning av plattformen som ligger bakom Kubernetes, l\u00f6ser inte problemet sig sj\u00e4lvt. Vi sl\u00f6sar bara mer resurser p\u00e5 att l\u00f6sa det ursprungliga problemet, eller i slut\u00e4ndan kommer vi att hamna i en situation med resurssl\u00f6seri. Och om detta \u00e4r ett h\u00f6gbelastat system i en offentlig molntj\u00e4nst, b\u00f6rjar vi n\u00e4stan s\u00e4kert anv\u00e4nda mer resurser \u00e4n vad som verkligen beh\u00f6vs.<\/p>\n

Vad ska man g\u00f6ra med allt detta?<\/h3>\n

\nEnkelt sagt, anv\u00e4nd asynkrona och icke-blockerande bibliotek f\u00f6r in- och utdata samt ramverk som Netty, Vert.x<\/a><\/noindex> eller Akka. De \u00e4r mycket b\u00e4ttre anpassade f\u00f6r att fungera i containrar p\u00e5 grund av sin reaktiva natur. Tack vare icke-blockerande in- och utdata kan samma tr\u00e5d hantera flera samtidiga f\u00f6rfr\u00e5gningar. Medan en f\u00f6rfr\u00e5gan v\u00e4ntar p\u00e5 in- och utdataresultat, frig\u00f6rs den tr\u00e5d som behandlar den och kan ta sig an en annan f\u00f6rfr\u00e5gan. Och n\u00e4r resultaten av in- och utdata slutligen kommer in forts\u00e4tter bearbetningen av den f\u00f6rsta f\u00f6rfr\u00e5gan. Genom att v\u00e4xla mellan att bearbeta f\u00f6rfr\u00e5gningar inom samma tr\u00e5d kan vi minska det totala antalet tr\u00e5dar och minska resursanv\u00e4ndningen vid bearbetning av f\u00f6rfr\u00e5gningar.<\/p>\n

Vid icke-blockerande in- och utdata blir antalet k\u00e4rnor en nyckelparameter, eftersom det definierar hur m\u00e5nga in- och utdata-tr\u00e5dar som kan utf\u00f6ras parallellt. Vid korrekt anv\u00e4ndning m\u00f6jligg\u00f6r detta en effektiv belastningsf\u00f6rdelning mellan k\u00e4rnorna och att hantera h\u00f6gre belastningar med f\u00e4rre resurser.<\/p>\n

Och, \u00e4r det allt?<\/h3>\n

\nNej, det finns mer. Reaktiv programmering hj\u00e4lper till att b\u00e4ttre utnyttja resurser, men har ocks\u00e5 sin kostnad. Specifikt m\u00e5ste koden skrivas om enligt principerna f\u00f6r icke-blockerande och undvika blockering av in- och utdata-tr\u00e5dar. Och det \u00e4r en helt annan utvecklings- och exekveringsmodell. \u00c4ven om det finns m\u00e5nga anv\u00e4ndbara bibliotek h\u00e4r, \u00e4r det \u00e4nd\u00e5 en radikal f\u00f6r\u00e4ndring av det vanliga s\u00e4ttet att t\u00e4nka.<\/p>\n

F\u00f6r det f\u00f6rsta m\u00e5ste du l\u00e4ra dig att skriva kod som k\u00f6rs asynkront. S\u00e5 snart du b\u00f6rjar anv\u00e4nda icke-blockerande in- och utdata m\u00e5ste du tydligt ange vad som ska h\u00e4nda n\u00e4r svaret p\u00e5 en f\u00f6rfr\u00e5gan kommer in. Att bara blockera och v\u00e4nta g\u00e5r inte l\u00e4ngre. Ist\u00e4llet kan du skicka tillbaka samtal, anv\u00e4nda reaktiv programmering eller continuation. Men det \u00e4r inte allt: f\u00f6r att anv\u00e4nda icke-blockerande in- och utdata beh\u00f6ver du \u00e4ven icke-blockerande servrar och klienter, helst \u00f6verallt. F\u00f6r HTTP \u00e4r det enkelt, men det finns ocks\u00e5 databaser, filsystem och mycket mer.<\/p>\n

Och \u00e4ven om total genomg\u00e5ende reaktivitet ger maximal effektivitet kan en s\u00e5dan f\u00f6r\u00e4ndring vara sv\u00e5r att sm\u00e4lta i praktiken. D\u00e4rf\u00f6r blir m\u00f6jligheten att kombinera reaktiv och imperativ kod ett n\u00f6dv\u00e4ndigt villkor f\u00f6r att:<\/p>\n

    \n
  1. Effektivt anv\u00e4nda resurser p\u00e5 de mest belastade delarna av det programvarusystemet;<\/li>\n
  2. Anv\u00e4nda enklare kodstil i de andra delarna.<\/li>\n<\/ol>\n

    <\/p>\n

    Vi presenterar Quarkus<\/h3>\n

    \nDet \u00e4r egentligen inneb\u00f6rden av Quarkus \u2013 att f\u00f6rena reaktiva och imperativa modeller inom en och samma k\u00f6rmilj\u00f6.<\/p>\n

    K\u00e4rnan i Quarkus bygger p\u00e5 Vert.x och Netty, ovanp\u00e5 vilka ett antal reaktiva ramverk och till\u00e4gg anv\u00e4nds f\u00f6r att hj\u00e4lpa utvecklaren. Quarkus \u00e4r avsedd f\u00f6r att bygga inte bara HTTP-mikrotj\u00e4nster, utan \u00e4ven h\u00e4ndelsehanterade arkitekturer. Tack vare sin reaktiva natur fungerar den mycket effektivt med meddelandesystem (Apache Kafka, AMQP etc.).<\/p>\n

    Hela tricket ligger i hur man anv\u00e4nder samma reaktiva motor f\u00f6r b\u00e5de imperativ och reaktiv kod.<\/p>\n

    \"Hur<\/p>\n

    Quarkus hanterar detta utm\u00e4rkt. Valet mellan imperativ och reaktiv \u00e4r tydligt \u2013 anv\u00e4nd det reaktiva k\u00e4rnan f\u00f6r b\u00e5da. Det hj\u00e4lper enormt med snabb, icke-blockerande kod som hanterar n\u00e4stan allt som passerar genom h\u00e4ndelse-loopens tr\u00e5d (event-loop thread, \u00e4ven k\u00e4nd som IO-thread). Men om du har klassiska REST-appar eller klientbaserade applikationer st\u00e5r Quarkus redo med en imperativ programmeringsmodell. Till exempel byggs HTTP-st\u00f6det i Quarkus p\u00e5 anv\u00e4ndningen av en icke-blockerande och reaktiv motor (Eclipse Vert.x och Netty). Alla HTTP-f\u00f6rfr\u00e5gningar som mottas av din applikation passerar f\u00f6rst genom h\u00e4ndelse-loopen (IO Thread) och skickas sedan till den del av koden som hanterar f\u00f6rfr\u00e5gningar. Beroende p\u00e5 destination kan koden f\u00f6r hantering av f\u00f6rfr\u00e5gningar k\u00f6ras i en separat tr\u00e5d (den s\u00e5 kallade worker thread, anv\u00e4nds f\u00f6r servlets och Jax-RS) eller anv\u00e4nda den ursprungliga in- och utstr\u00f6mmen (reaktiv rutt).<\/p>\n

    \"Hur<\/p>\n

    F\u00f6r meddelande\u00f6verf\u00f6ringssystemens kopplingar anv\u00e4nds icke-blockerande klienter som arbetar ovanp\u00e5 Vert.x-motorn. D\u00e4rf\u00f6r kan du effektivt skicka, ta emot och bearbeta meddelanden fr\u00e5n meddelandemiddleware-system.<\/p>\n

    P\u00e5 webbplatsen Quarkus.io<\/a><\/noindex> ett antal bra guider har sammanst\u00e4llts f\u00f6r att hj\u00e4lpa dig att komma ig\u00e5ng med Quarkus:<\/p>\n