Hierdie jaar beplan ons om houer-temas ernstig te ontwikkel, и . 'n Logiese voortsetting van hierdie onderwerpe sal reeds 'n storie oor die Quarkus-raamwerk wees op Habré. Vandag se artikel handel minder oor die ontwerp van "subatomiese supervinnige Java" en meer oor die belofte wat Quarkus aan Enterprise bring.
Java en die JVM is steeds uiters gewild, maar wanneer daar met bedienerlose tegnologieë en wolk-inheemse mikrodienste gewerk word, word Java en ander JVM-tale al hoe minder gebruik omdat hulle te veel geheuespasie opneem en te stadig is om te laai, wat dit maak swak geskik vir gebruik met kortlewende houers. Gelukkig begin hierdie situasie nou verander danksy Quarkus.
Supervinnige subatomiese Java het 'n nuwe vlak bereik!
42 vrystellings, 8 maande se gemeenskapswerk en 177 ongelooflike ontwikkelaars - die resultaat van dit alles was die vrystelling in November 2019 , 'n vrystelling wat 'n belangrike mylpaal in die ontwikkeling van die projek aandui en baie oulike kenmerke en vermoëns bied (jy kan meer daaroor lees in ).
Vandag sal ons jou wys hoe Quarkus imperatiewe en reaktiewe programmeringsmodelle in 'n enkele reaktiewe kern kombineer. Ons begin met 'n kort geskiedenis en gaan dan in detail oor wat Quarkus se reaktiewe kerndualisme is en hoe -Ontwikkelaars kan voordeel trek uit hierdie voordele.
, и -funksies – dit alles is, soos hulle sê, vandag aan die toeneem. Onlangs het die skepping van wolkgesentreerde argitekture baie makliker en meer toeganklik geword, maar probleme bly voort – veral vir Java-ontwikkelaars. Byvoorbeeld, in die geval van bedienerlose funksies en mikrodienste, is daar 'n dringende behoefte om opstarttyd te verminder, geheueverbruik te verminder en steeds die ontwikkeling daarvan geriefliker en aangenamer te maak. Java het die afgelope paar jaar verskeie verbeterings aangebring, soos verbeterde ergonomiese funksionaliteit vir houers ensovoorts. Dit is egter steeds 'n uitdaging om Java behoorlik in 'n houer te kry. Ons sal dus begin deur na sommige van die inherente kompleksiteite van Java te kyk, wat veral akuut is wanneer houer-georiënteerde Java-toepassings ontwikkel word.
Kom ons kyk eers na die geskiedenis.
Strome en houers
Begin met weergawe 8u131, het Java begin om min of meer houers te ondersteun as gevolg van verbeterings in ergonomiese funksionaliteit. In die besonder, die JVM weet nou op hoeveel verwerkerkerne dit loop en kan draadpoele - tipies vurk / aansluit by poele - dienooreenkomstig opstel. Natuurlik is dit wonderlik, maar kom ons sê ons het 'n tradisionele webtoepassing wat HTTP-servlets gebruik en in Tomcat, Jetty, ens. As gevolg hiervan sal hierdie toepassing elke versoek 'n aparte draad gee en dit toelaat om hierdie draad te blokkeer terwyl daar vir I/O-bewerkings gewag word, byvoorbeeld wanneer toegang tot die databasis, lêers of ander dienste verkry word. Dit wil sê, die grootte van so 'n toepassing hang nie af van die aantal beskikbare kerns nie, maar van die aantal gelyktydige versoeke. Boonop beteken dit dat kwotas of beperkings in Kubernetes op die aantal kerns nie hier van veel hulp sal wees nie, en die saak sal uiteindelik op smoor eindig.
Geheue-uitputting
Drade is geheue. En intra-houer geheue beperkings is geensins 'n wondermiddel nie. Begin net om die aantal toepassings en drade te vermeerder, en vroeër of later sal jy 'n kritieke toename in skakelfrekwensie teëkom en, as gevolg daarvan, prestasie-agteruitgang. Ook, as jou toepassing tradisionele mikrodiensraamwerke gebruik, of aan 'n databasis koppel, of kas gebruik, of andersins geheue gebruik, het jy natuurlik 'n instrument nodig wat jou toelaat om binne die JVM te kyk en te sien hoe dit geheue bestuur sonder om dit dood te maak. JVM self (byvoorbeeld, XX:+UseCGroupMemoryLimitForHeap). En al het die JVM sedert Java 9 geleer om cgroups te aanvaar en daarvolgens aan te pas, bly die bewaring en bestuur van geheue 'n taamlik komplekse saak.
Kwotas en limiete
Java 11 het ondersteuning vir SVE-kwotas bekendgestel (soos PreferContainerQuotaForCPUCount). Kubernetes bied ook ondersteuning vir limiete en kwotas. Ja, dit maak alles sin, maar as die toepassing weer die toegekende kwota oorskry, eindig ons weer met die grootte - soos die geval is met tradisionele Java-toepassings - wat bepaal word deur die aantal kerns en met die toekenning van 'n aparte draad vir elke versoek, dan is daar min sin in dit alles.
Daarbenewens, as jy kwotas en limiete of die uitskaalfunksies van die platform onderliggend aan Kubernetes gebruik, los die probleem ook nie vanself op nie. Ons bestee eenvoudig meer hulpbronne om die oorspronklike probleem op te los of eindig met oorbesteding. En as dit 'n hoëladingstelsel in 'n publieke openbare wolk is, gebruik ons byna seker meer hulpbronne as wat ons regtig nodig het.
En wat om met dit alles te doen?
Om dit eenvoudig te stel, gebruik asinchrone en nie-blokkerende I/O biblioteke en raamwerke soos Netty, of Akka. Hulle is baie beter geskik om in houers te werk as gevolg van hul reaktiewe aard. Danksy nie-blokkerende I/O kan dieselfde draad verskeie gelyktydige versoeke verwerk. Terwyl een versoek wag vir I/O-resultate, word die draad wat dit verwerk, vrygestel en deur 'n ander versoek oorgeneem. En wanneer die I/O-resultate uiteindelik aankom, gaan die verwerking van die eerste versoek voort. Deur die verwerking van versoeke binne dieselfde draad te verweef, kan jy die totale aantal drade verminder en die hulpbronverbruik vir die verwerking van versoeke verminder.
Met nie-blokkerende I/O word die aantal kerne 'n sleutelparameter omdat dit die aantal I/O-drade bepaal wat parallel uitgevoer kan word. Wanneer dit korrek gebruik word, laat dit jou toe om die las effektief tussen kerns te versprei en hoër werkladings met minder hulpbronne te hanteer.
Hoe, is dit al?
Nee, daar is iets anders. Reaktiewe programmering help om hulpbronne beter te gebruik, maar het ook 'n prys. In die besonder sal die kode herskryf moet word volgens die beginsels van nie-blokkering en vermy blokkering van I/O-drade. En dit is 'n heeltemal ander model van ontwikkeling en uitvoering. En hoewel hier baie nuttige biblioteke is, is dit steeds 'n radikale verandering in die gewone manier van dink.
Eerstens moet jy leer hoe om kode te skryf wat asynchronies loop. Sodra jy nie-blokkerende I/O begin gebruik, moet jy uitdruklik spesifiseer wat moet gebeur wanneer 'n antwoord op 'n versoek ontvang word. Om bloot te blokkeer en te wag sal nie meer werk nie. In plaas daarvan kan u terugbeloproepe deurgee, reaktiewe programmering of voortsetting gebruik. Maar dit is nie al nie: om nie-blokkerende I/O te gebruik, benodig jy beide nie-blokkerende bedieners en kliënte, verkieslik oral. In die geval van HTTP is alles eenvoudig, maar daar is ook databasisse, lêerstelsels en nog baie meer.
En hoewel totale end-tot-end-reaktiwiteit doeltreffendheid maksimeer, kan so 'n verskuiwing in die praktyk moeilik wees om te verduur. Daarom word die vermoë om reaktiewe en imperatiewe kode te kombineer 'n voorvereiste om:
- Gebruik hulpbronne effektief in die mees gelaaide areas van die sagtewarestelsel;
- Gebruik eenvoudiger stylkode in sy oorblywende dele.
Stel Quarkus bekend
Eintlik is dit die essensie van Quarkus - om reaktiewe en noodsaaklike modelle binne 'n enkele runtime-omgewing te kombineer.
Quarkus is gebaseer op Vert.x en Netty, met 'n reeks reaktiewe raamwerke en uitbreidings bo-op om die ontwikkelaar te help. Quarkus is ontwerp om nie net HTTP-mikrodienste te bou nie, maar ook gebeurtenisgedrewe argitekture. As gevolg van sy reaktiewe aard, werk dit baie effektief met boodskapstelsels (Apache Kafka, AMQP, ens.).
Die truuk is hoe om dieselfde reaktiewe enjin vir beide noodsaaklike en reaktiewe kode te gebruik.
Quarkus doen dit briljant. Die keuse tussen imperatief en reaktief is voor die hand liggend - gebruik 'n reaktiewe kern vir albei. Waarmee dit regtig help, is vinnige, nie-blokkerende kode wat byna alles hanteer wat deur die gebeurtenislusdraad, oftewel IO-draad, gaan. Maar as jy klassieke REST- of kliëntkanttoepassings het, het Quarkus 'n noodsaaklike programmeringsmodel gereed. Byvoorbeeld, HTTP-ondersteuning in Quarkus is gebaseer op die gebruik van 'n nie-blokkerende en reaktiewe enjin (Eclipse Vert.x en Netty). Alle HTTP-versoeke wat deur jou toepassing ontvang word, word eers deur 'n gebeurtenislus (IO Thread) gestuur en dan gestuur na die deel van die kode wat die versoeke bestuur. Afhangende van die bestemming, kan die versoekbestuurskode binne 'n aparte draad geroep word (die sogenaamde werkersdraad, wat gebruik word in die geval van servlets en Jax-RS) of die bron-I/O-draad (reaktiewe roete) gebruik.
Boodskapstelselverbindings gebruik nie-blokkerende kliënte wat bo-op die Vert.x-enjin loop. Daarom kan u effektief boodskappe vanaf boodskapmiddelwarestelsels stuur, ontvang en verwerk.
Die webwerf Hier is 'n paar goeie tutoriale om jou te help om met Quarkus te begin:
Ons het ook aanlyn praktiese tutoriale geskep om jou verskeie aspekte van reaktiewe programmering in net 'n blaaier te leer, geen IDE nodig nie en geen rekenaar nodig nie. Jy kan hierdie lesse vind .
Nuttige hulpbronne
- Quarkus projek webwerf –
- Quarkus-projek op GitHub –
- Quarkus-projek Twitter –
- Quarkus projekklets –
- Quarkus Project Forums – !forum/quarkus-dev
10 videolesse oor Quarkus om vertroud te raak met die onderwerp
Soos hulle op die webwerf sê , - hierdie -georiënteerde Java-stapel, aangepas vir GraalVM en OpenJDK HotSpot en saamgestel uit die beste Java-biblioteke en -standaarde.
Om jou te help om die onderwerp te verstaan, het ons 10 video-tutoriale gekies wat verskeie aspekte van Quarkus dek en voorbeelde van die gebruik daarvan:
1. Bekendstelling van Quarkus: Die volgende generasie Java-raamwerk vir Kubernetes
Deur Thomas Qvarnstrom en Jason Greene
Die doel van die Quarkus-projek is om 'n Java-platform vir Kubernetes en bedienerlose omgewings te skep, en om reaktiewe en noodsaaklike programmeringsmodelle in 'n enkele looptydomgewing te kombineer sodat ontwikkelaars hul benadering buigsaam kan verander wanneer hulle met 'n wye reeks verspreide toepassingsargitekture werk. Kom meer te wete in die inleidende lesing hieronder.
2. Quarkus: Supervinnige Subatomiese Java
Deur: Burr Sutter
Hierdie video-tutoriaal van DevNation Live demonstreer hoe om Quarkus te gebruik om ondernemings Java-toepassings, API's, mikrodienste en bedienerlose funksies in 'n Kubernetes/OpenShift-omgewing te optimaliseer, wat hulle baie kleiner, vinniger en meer skaalbaar maak.
3. Quarkus en GraalVM: versnel Hibernate tot superspoed en krimp dit tot subatomiese groottes
Skrywer: Sanne Grinovero
Uit die aanbieding sal jy leer hoe Quarkus ontstaan het, hoe dit werk en hoe dit jou toelaat om komplekse biblioteke, soos Hibernate ORM, versoenbaar te maak met inheemse GraalVM-beelde.
4. Leer om bedienerlose toepassings te ontwikkel
Skrywer: Martin Luther
Die video hieronder wys hoe om 'n eenvoudige Java-toepassing met Quarkus te skep en dit as 'n bedienerlose toepassing op Knative te ontplooi.
5. Quarkus: Geniet die kodering
Skrywer: Edson Yanaga
'n Videogids om jou eerste Quarkus-projek te skep, wat jou toelaat om te verstaan hoekom Quarkus die harte van ontwikkelaars wen.
6. Java en houers - wat hul toekoms saam sal wees
Geplaas deur Mark Little
Hierdie aanbieding stel die geskiedenis van Java bekend en verduidelik waarom Quarkus die toekoms van Java is.
7. Quarkus: Supervinnige Subatomiese Java
Skrywer: Dimitris Andreadis
'n Oorsig van die voordele van Quarkus wat erkenning van ontwikkelaars ontvang het: eenvoud, ultrahoë spoed, die beste biblioteke en standaarde.
8. Quarkus en subatomiese vuurpylstelsels
Skrywer: Clement Escoffier
Deur integrasie met GraalVM bied Quarkus 'n ultravinnige ontwikkelingservaring en 'n subatomiese looptydomgewing. Die skrywer praat oor die reaktiewe kant van Quarkus en hoe om dit te gebruik om reaktiewe en stromende toepassings te bou.
9. Quarkus en vinnige toepassingsontwikkeling in Eclipse MicroProfile
Skrywer: John Clingan
Deur Eclipse MicroProfile en Quarkus te kombineer, kan ontwikkelaars volledige houer MicroProfile-toepassings skep wat binne tien millisekondes begin. Die video gaan in detail in oor hoe om 'n mikroprofiel-toepassing in container te kodeer vir ontplooiing op die Kubernetes-platform.
10. Java, "Turbo" weergawe
Skrywer: Marcus Biel
Die skrywer wys hoe om Quarkus te gebruik om superklein, supervinnige Java-houers te skep wat werklike deurbrake moontlik maak, veral in bedienerlose omgewings.
Bron: will.com