Tänä vuonna aiomme kehittää konttiteemoja vakavasti, и . Looginen jatko näille aiheille on jo tarina Quarkus-kehyksestä Habrella. Tämän päivän artikkeli käsittelee vähemmän "subatomisen supernopean Javan" suunnittelua ja enemmän Quarkuksen Enterpriselle antamasta lupauksesta.
Java ja JVM ovat edelleen erittäin suosittuja, mutta palvelimettomien teknologioiden ja pilvipohjaisten mikropalvelujen kanssa työskennellessä Javaa ja muita JVM-kieliä käytetään yhä vähemmän, koska ne vievät liikaa muistitilaa ja ovat liian hitaita latautumaan. soveltuu huonosti käytettäväksi lyhytikäisten säiliöiden kanssa. Onneksi tämä tilanne alkaa nyt muuttua Quarkuksen ansiosta.
Supernopea subatominen Java on saavuttanut uuden tason!
42 julkaisua, 8 kuukautta yhteisötyötä ja 177 upeaa kehittäjää – kaiken tuloksena julkaisu marraskuussa 2019 , julkaisu, joka on tärkeä virstanpylväs projektin kehityksessä ja tarjoaa paljon hienoja ominaisuuksia ja ominaisuuksia (voit lukea niistä lisää osoitteessa ).
Tänään näytämme sinulle, kuinka Quarkus yhdistää pakolliset ja reaktiiviset ohjelmointimallit yhdeksi reaktiiviseksi ytimeksi. Aloitamme lyhyellä historialla ja menemme sitten yksityiskohtiin siitä, mitä Quarkuksen reaktiivinen ydindualismi on ja miten -Kehittäjät voivat hyötyä näistä eduista.
, и -toiminnot – kaikki tämä on, kuten sanotaan, nousussa tänään. Viime aikoina pilvikeskeisten arkkitehtuurien luomisesta on tullut paljon helpompaa ja helpompaa, mutta ongelmia on edelleen - etenkin Java-kehittäjille. Esimerkiksi palvelimettomien toimintojen ja mikropalvelujen tapauksessa on kiireesti lyhennettävä käynnistysaikaa, vähennettävä muistin kulutusta ja silti tehtävä niiden kehittämisestä mukavampaa ja nautinnollisempaa. Java on tehnyt useita parannuksia viime vuosina, kuten parantunut konttien ergonomiatoimintoja ja niin edelleen. Java-ohjelman saaminen toimimaan kunnolla säilössä on kuitenkin edelleen haastavaa. Joten aloitamme tarkastelemalla joitain Javan luontaisia monimutkaisia tekijöitä, jotka ovat erityisen akuutteja kehitettäessä säilökohtaisia Java-sovelluksia.
Ensin katsotaan historiaa.
Virrat ja kontit
Versiosta 8u131 alkaen Java alkoi enemmän tai vähemmän tukea kontteja ergonomisten toimintojen parannuksien ansiosta. Erityisesti JVM tietää nyt, kuinka monessa prosessoriytimessä se toimii, ja voi määrittää säievarastot – tyypillisesti haarautumaan/liittymään pooleihin – vastaavasti. Tämä on tietysti hienoa, mutta oletetaan, että meillä on perinteinen verkkosovellus, joka käyttää HTTP-servlettejä ja toimii Tomcatissa, Jettyssä jne. Tämän seurauksena tämä sovellus antaa jokaiselle pyynnölle erillisen säikeen ja sallii sen estää tämän säikeen odottaessaan I/O-toimintoja, esimerkiksi käytettäessä tietokantaa, tiedostoja tai muita palveluita. Toisin sanoen tällaisen sovelluksen koko ei riipu käytettävissä olevien ytimien lukumäärästä, vaan samanaikaisten pyyntöjen määrästä. Lisäksi tämä tarkoittaa, että Kubernetesin kiintiöt tai ytimien lukumäärän rajoitukset eivät tässä juuri auta, ja asia päättyy lopulta kuristukseen.
Muistin loppuminen
Langat ovat muistia. Ja säilön sisäiset muistin rajoitukset eivät ole mikään ihmelääke. Aloita vain sovellusten ja säikeiden määrän lisääminen, ja ennemmin tai myöhemmin kohtaat kriittisen kytkentätaajuuden kasvun ja sen seurauksena suorituskyvyn heikkenemisen. Lisäksi, jos sovelluksesi käyttää perinteisiä mikropalvelukehyksiä, muodostaa yhteyden tietokantaan tai käyttää välimuistia tai muuten kuluttaa muistia, tarvitset tietysti työkalun, jonka avulla voit katsoa JVM:n sisään ja nähdä, kuinka se hallitsee muistia tappamatta sitä. JVM itse (esimerkiksi XX:+UseCGroupMemoryLimitForHeap). Ja vaikka Java 9:stä lähtien JVM on oppinut hyväksymään c-ryhmiä ja mukautumaan sen mukaisesti, muistin varaaminen ja hallinta on edelleen melko monimutkainen asia.
Kiintiöt ja rajoitukset
Java 11 esitteli prosessorikiintiöiden tuen (kuten PreferContainerQuotaForCPUCount). Kubernetes tarjoaa myös tukea rajoituksille ja kiintiöille. Kyllä, tämä kaikki on järkevää, mutta jos sovellus jälleen ylittää allokoidun kiintiön, päädymme jälleen koon - kuten perinteisten Java-sovellusten tapauksessa - määräytyy ytimien lukumäärän mukaan ja erillisen säikeen varaamiseen kullekin. pyyntöön, niin tässä kaikessa ei ole juurikaan järkeä.
Lisäksi, jos käytät kiintiöitä ja rajoja tai Kubernetesin taustalla olevan alustan skaalaustoimintoja, ongelma ei myöskään ratkea itsestään. Käytämme yksinkertaisesti enemmän resursseja alkuperäisen ongelman ratkaisemiseen tai päädymme ylikulutukseen. Ja jos kyseessä on paljon kuormitettu järjestelmä julkisessa julkisessa pilvessä, käytämme lähes varmasti enemmän resursseja kuin todella tarvitsemme.
Ja mitä tehdä tämän kaiken kanssa?
Yksinkertaisesti sanottuna käytä asynkronisia ja estämättömiä I/O-kirjastoja ja kehyksiä, kuten Netty, tai Akka. Ne soveltuvat paljon paremmin töihin konteissa reaktiivisen luonteensa vuoksi. Estottoman I/O:n ansiosta sama säie voi käsitellä useita samanaikaisia pyyntöjä. Kun yksi pyyntö odottaa I/O-tuloksia, sen säikeenkäsittely vapautetaan ja toinen pyyntö ottaa haltuunsa. Ja kun I/O-tulokset vihdoin saapuvat, ensimmäisen pyynnön käsittely jatkuu. Käsittelemällä pyyntöjä samassa säikeessä limittämällä voit vähentää säikeiden kokonaismäärää ja vähentää pyyntöjen käsittelyn resurssien kulutusta.
Ei-estossa I/O:ssa ytimien määrästä tulee avainparametri, koska se määrittää rinnakkaisten I/O-säikeiden määrän. Oikein käytettynä voit jakaa kuorman tehokkaasti ytimien välillä ja käsitellä suurempia työkuormia pienemmillä resursseilla.
Miten, onko siinä kaikki?
Ei, siinä on jotain muuta. Reaktiivinen ohjelmointi auttaa hyödyntämään resursseja paremmin, mutta sillä on myös hintansa. Erityisesti koodi on kirjoitettava uudelleen estämisen periaatteiden mukaisesti ja vältettävä I/O-säikeiden estämistä. Ja tämä on täysin erilainen kehitys- ja toteutusmalli. Ja vaikka täällä on paljon hyödyllisiä kirjastoja, se on silti radikaali muutos tavanomaiseen ajattelutapaan.
Ensin sinun on opittava kirjoittamaan koodia, joka toimii asynkronisesti. Kun aloitat estottoman I/O:n käytön, sinun on määritettävä tarkasti, mitä pitäisi tapahtua, kun pyyntöön vastataan. Pelkkä estäminen ja odottaminen eivät enää toimi. Sen sijaan voit välittää takaisinsoittoja, käyttää reaktiivista ohjelmointia tai jatkoa. Mutta siinä ei vielä kaikki: käyttääksesi estämätöntä I/O:ta, tarvitset sekä estämättömiä palvelimia että asiakkaita, mieluiten kaikkialla. HTTP:n tapauksessa kaikki on yksinkertaista, mutta on myös tietokantoja, tiedostojärjestelmiä ja paljon muuta.
Ja vaikka täydellinen päästä päähän -reaktiivisuus maksimoi tehokkuuden, tällainen muutos voi olla käytännössä vaikeaa hillitä. Siksi kyvystä yhdistää reaktiivinen ja pakottava koodi tulee edellytys, jotta:
- Käytä resursseja tehokkaasti ohjelmistojärjestelmän kuormitetuimmilla alueilla;
- Käytä yksinkertaisempaa tyylikoodia sen muissa osissa.
Esittelyssä Quarkus
Itse asiassa tämä on Quarkuksen ydin - yhdistää reaktiiviset ja pakottavat mallit yhdessä ajonaikaisessa ympäristössä.
Quarkus perustuu Vert.x:ään ja Nettiin, ja sen päällä on valikoima reaktiivisia kehyksiä ja laajennuksia kehittäjän auttamiseksi. Quarkus on suunniteltu HTTP-mikropalveluiden lisäksi myös tapahtumalähtöisten arkkitehtuurien rakentamiseen. Reaktiivisen luonteensa ansiosta se toimii erittäin tehokkaasti viestijärjestelmien kanssa (Apache Kafka, AMQP jne.).
Temppu on, kuinka käyttää samaa reaktiivista moottoria sekä pakottavalle että reaktiiviselle koodille.
Quarkus tekee tämän loistavasti. Valinta pakottavan ja reaktiivisen välillä on ilmeinen - käytä reaktiivista ydintä molemmille. Se todella auttaa on nopea, estävä koodi, joka käsittelee melkein kaiken, mikä kulkee tapahtumasilmukkasäikeen eli IO-säikeen läpi. Mutta jos sinulla on klassisia REST- tai asiakaspuolen sovelluksia, Quarkuksella on pakollinen ohjelmointimalli valmiina. Esimerkiksi Quarkuksen HTTP-tuki perustuu estämättömän ja reaktiivisen moottorin (Eclipse Vert.x ja Netty) käyttöön. Kaikki sovelluksesi vastaanottamat HTTP-pyynnöt välitetään ensin tapahtumasilmukan (IO Thread) läpi ja lähetetään sitten koodin osaan, joka hallitsee pyyntöjä. Kohteesta riippuen pyynnönhallintakoodi voidaan kutsua erillisessä säikeessä (ns. työsäie, jota käytetään servlettien ja Jax-RS:n tapauksessa) tai käyttää lähde-I/O-säiettä (reaktiivinen reitti).
Viestintäjärjestelmän liittimet käyttävät ei-estäviä asiakkaita, jotka toimivat Vert.x-moottorin päällä. Siksi voit tehokkaasti lähettää, vastaanottaa ja käsitellä viestejä viestintäväliohjelmistojärjestelmistä.
Sivusto Tässä on muutamia hyviä opetusohjelmia, jotka auttavat sinua pääsemään alkuun Quarkuksen kanssa:
Olemme myös luoneet käytännönläheisiä online-opetusohjelmia, joiden avulla voit opettaa sinulle erilaisia reaktiivisen ohjelmoinnin näkökohtia pelkällä selaimella, ilman IDE:tä tai tietokonetta. Löydät nämä oppitunnit .
Hyödyllisiä resursseja
- Quarkus-projektin nettisivut –
- Quarkus-projekti GitHubissa –
- Quarkus-projekti Twitter –
- Quarkus-projektin chat –
- Quarkus-projektifoorumit – !forum/quarkus-dev
10 videotuntia Quarkuksessa aiheeseen tutustumiseksi
Kuten nettisivuilla sanotaan , - Onko -suuntautunut Java-pino, joka on räätälöity GraalVM:lle ja OpenJDK HotSpotille ja koottu parhaista Java-kirjastoista ja -standardeista.
Auttamaan sinua ymmärtämään aihetta, olemme valinneet 10 opetusvideota, jotka kattavat Quarkuksen eri puolia ja esimerkkejä sen käytöstä:
1. Esittelyssä Quarkus: The Next Generation Java Framework Kubernetesille
Kirjailija: Thomas Qvarnstrom ja Jason Greene
Quarkus-projektin tavoitteena on luoda Java-alusta Kubernetesille ja palvelimettomille ympäristöille sekä yhdistää reaktiiviset ja pakottavat ohjelmointimallit yhdeksi ajonaikaiseksi ympäristöksi, jotta kehittäjät voivat joustavasti vaihdella lähestymistapaansa työskennellessään laajan valikoiman hajautettujen sovellusarkkitehtuurien kanssa. Lue lisää alla olevasta johdantoluennosta.
2. Quarkus: Supernopea Subatomic Java
Kirjailija: Burr Sutter
Tämä DevNation Liven opetusvideo osoittaa, kuinka Quarkuksen avulla optimoidaan yrityksen Java-sovelluksia, API:ita, mikropalveluita ja palvelimettomia toimintoja Kubernetes/OpenShift-ympäristössä, mikä tekee niistä paljon pienempiä, nopeampia ja skaalattavampia.
3. Quarkus ja GraalVM: lepotilan kiihdyttäminen supernopeuksiin ja sen pienentäminen subatomisiin kokoihin
Kirjailija: Sanne Grinovero
Esityksestä opit kuinka Quarkus syntyi, miten se toimii ja kuinka sen avulla voit tehdä monimutkaisista kirjastoista, kuten Hibernate ORM:sta, yhteensopivia alkuperäisten GraalVM-kuvien kanssa.
4. Opi kehittämään palvelimettomia sovelluksia
Kirjailija: Martin Luther
Alla oleva video näyttää, kuinka yksinkertainen Java-sovellus luodaan Quarkuksen avulla ja otetaan käyttöön palvelimettomana sovelluksena Knativessa.
5. Quarkus: Pidä hauskaa koodaamisesta
Kirjailija: Edson Yanaga
Videoopas ensimmäisen Quarkus-projektisi luomiseen, jonka avulla voit ymmärtää, miksi Quarkus voittaa kehittäjien sydämet.
6. Java ja kontit - mikä on heidän tulevaisuutensa yhdessä
Lähettäjä Mark Little
Tämä esitys esittelee Javan historian ja selittää, miksi Quarkus on Javan tulevaisuus.
7. Quarkus: Supernopea Subatomic Java
Kirjailija: Dimitris Andreadis
Yleiskatsaus Quarkuksen eduista, jotka ovat saaneet kehittäjien tunnustusta: yksinkertaisuus, huippunopeat nopeudet, parhaat kirjastot ja standardit.
8. Kvarkut ja subatomiset rakettijärjestelmät
Kirjailija: Clement Escoffier
GraalVM-integroinnin ansiosta Quarkus tarjoaa erittäin nopean kehityskokemuksen ja subatomisen ajonaikaisen ympäristön. Kirjoittaja puhuu Quarkuksen reaktiivisesta puolesta ja kuinka sen avulla voidaan rakentaa reaktiivisia ja suoratoistosovelluksia.
9. Quarkus ja nopea sovelluskehitys Eclipse MicroProfilessa
Kirjailija: John Clingan
Yhdistämällä Eclipse MicroProfile ja Quarkus, kehittäjät voivat luoda täysin varusteltuja konttipohjaisia MicroProfile-sovelluksia, jotka käynnistyvät kymmenissä millisekunneissa. Videossa kerrotaan yksityiskohtaisesti, kuinka konttimuotoinen MicroProfile-sovellus koodataan käyttöön Kubernetes-alustalla.
10. Java, "Turbo"-versio
Kirjailija: Marcus Biel
Kirjoittaja näyttää, kuinka Quarkuksen avulla luodaan superpieniä, supernopeita Java-säilöjä, jotka mahdollistavat todellisia läpimurtoja, erityisesti palvelimettomissa ympäristöissä.
Lähde: will.com