Hei kaikki! Tämä on Quarkus-sarjamme toinen viesti - tänään puhumme natiivikokoelmasta.
on Java-pino, joka on räätälöity . Vaikka täällä on varmasti paljon muutakin tehtävää, olemme tehneet paljon hyvää työtä monissa asioissa, mukaan lukien JVM:n ja useiden puitteiden optimointi. Yksi Quarkuksen ominaisuuksista, joka on herättänyt lisääntynyttä kiinnostusta kehittäjien keskuudessa, on sen kattava ja saumaton tapa muuttaa Java-koodi tietyn käyttöjärjestelmän suoritettaviksi tiedostoiksi (ns. "natiivi käännös"), joka on samanlainen kuin C ja C++, joissa tällainen käännös tapahtuu yleensä rakennus-, testaus- ja käyttöönottosyklin lopussa.
Ja vaikka natiivi käännös on tärkeää, kuten alla näytämme, on huomattava, että Quarkus toimii todella hyvin yleisimmällä Java-koneella, OpenJDK Hotspotilla, kiitos suorituskyvyn parannukset, joita olemme toteuttaneet koko pinossa. Tästä syystä natiivikokoelmaa tulisi pitää lisäbonuksena, jota voidaan käyttää halutulla tai tarpeen mukaan. Itse asiassa Quarkus luottaa suuresti OpenJDK:han alkuperäiskuvien suhteen. Ja kehittäjien lämpimästi hyväksymä dev-tila varmistaa lähes välittömän muutosten testauksen Hotspotissa toteutettujen edistyneiden dynaamisen koodin suorituskyvyn ansiosta. Lisäksi luotaessa alkuperäisiä GraalVM-kuvia käytetään OpenJDK-luokkakirjastoa ja HotSpot-ominaisuuksia.
Joten miksi tarvitset alkuperäistä käännöstä, jos kaikki on jo täydellisesti optimoitu? Yritämme vastata tähän kysymykseen alla.
Aloitetaan ilmeisestä: Red Hatilla on laaja kokemus JVM:iden, pinojen ja kehysten optimoinnista projektin kehittämisen aikana , mukaan lukien:
- Ensimmäinen sovelluspalvelin, joka toimii alustalla pilvessä .
- Ensimmäinen tietokoneissa käytettävä sovelluspalvelin .
- Ensimmäinen käynnissä oleva sovelluspalvelin .
- Useita projekteja käynnissä laitteissa .
Olemme käsitelleet Java-sovellusten ajamisen pilvessä ja resurssirajoitteisissa laitteissa (lue: IoT) jo monta vuotta ja olemme oppineet saamaan JVM:stä kaiken irti suorituskyvyn ja muistin optimoinnin suhteen. Kuten monet muut, olemme työskennelleet Java-sovellusten alkuperäisen kokoamisen parissa pitkään , , ja jopa ja olemme hyvin tietoisia tämän lähestymistavan eduista ja haitoista (esimerkiksi dilemma valita "build Once - Run-Anywhere" -asetuksen yleismaailmallisuuden ja sen tosiasian välillä, että käännetyt sovellukset ovat pienempiä ja toimivat nopeammin).
Miksi on tärkeää pohtia näitä etuja ja haittoja? Koska joissakin tilanteissa niiden suhde tulee ratkaisevaksi:
- Esimerkiksi palvelimettomissa/tapahtumaohjatuissa ympäristöissä, joissa (kovassa tai pehmeässä) reaaliajassa, jotta ehtii reagoida tapahtumiin. Toisin kuin pitkäikäiset jatkuvat palvelut, tässä kylmäkäynnistyksen kesto pidentää kriittisesti vastausaikaa pyyntöön. JVM:n käynnistyminen vie silti huomattavasti aikaa, ja vaikka tätä voidaan joissakin tapauksissa vähentää pelkillä laitteistomenetelmillä, yhden sekunnin ja 5 millisekunnin välinen ero voi olla ero elämän ja kuoleman välillä. Kyllä, täällä voit leikkiä Java-koneiden kuuman reservin luomisella (mitä teimme esimerkiksi ). Ja taloudelliselta kannalta tämä ei luultavasti ole oikea vaihtoehto.
- Lisäksi on toinen näkökohta, joka usein nousee esiin: monivuokraus. Huolimatta siitä, että JVM:t ovat tulleet ominaisuuksiltaan hyvin lähelle käyttöjärjestelmiä, ne eivät silti pysty tekemään sitä, mihin olemme niin tottuneet Linuxissa - eristämään prosesseja. Siksi yhden säikeen epäonnistuminen voi kaataa koko Java-koneen. Monet ihmiset yrittävät kiertää tämän haitan omistamalla erillisen JVM:n jokaiselle käyttäjän sovellukselle minimoidakseen vian seuraukset. Tämä on varsin loogista, mutta ei sovi hyvin skaalaukseen.
- Lisäksi pilvipohjaisissa sovelluksissa tärkeä indikaattori on palveluiden tiheys isännässä. Siirtyminen metodologiaan , mikropalvelut ja Kubernetes lisää Java-koneiden määrää sovellusta kohden. Eli toisaalta tämä kaikki tarjoaa joustavuutta ja luotettavuutta, mutta samalla myös perusmuistin kulutus palvelun kannalta kasvaa, eikä osa näistä kuluista aina ole ehdottoman välttämätöntä. Staattisesti käännetyt suoritettavat tiedostot hyötyvät tässä erilaisista optimointitekniikoista, kuten matalan tason kuolleen koodin eliminoinnista, kun lopullinen kuva sisältää vain ne osat kehyksistä (mukaan lukien itse JDK), joita palvelu todella käyttää. Siksi Quarkuksen alkuperäinen käännös auttaa sijoittamaan palveluesiintymiä tiheästi isäntään tietoturvasta tinkimättä.
Itse asiassa yllä olevat argumentit ovat jo riittäviä ymmärtämään alkuperäisen kokoamisen perusteluja Quarkus-projektin osallistujien näkökulmasta. On kuitenkin toinen, ei-tekninen, mutta myös tärkeä syy: viime vuosina monet ohjelmoijat ja kehitysyhtiöt ovat hylänneet Javan uusien ohjelmointikielten hyväksi uskoen, että Java sekä sen JVM:t, pinot ja kehykset ovat tulleet liian suureksi. muistin nälkäinen, liian hidas jne.
Kuitenkin tapana käyttää samaa työkalua minkä tahansa ongelman ratkaisemiseen on . Joskus on parempi ottaa askel taaksepäin ja etsiä jotain muuta. Ja jos Quarkus saa ihmiset pysähtymään ja ajattelemaan, se on hyväksi koko Java-ekosysteemille. Quarkus edustaa innovatiivista näkemystä tehokkaampien sovellusten rakentamiseen, mikä tekee Javasta merkityksellisemmän uusille sovellusarkkitehtuureille, kuten palvelimettomille. Lisäksi Quarkuksessa on laajennettavuuden ansiosta toivottavasti kokonainen Java-laajennusten ekosysteemi, mikä lisää merkittävästi kehysten määrää, jotka tukevat sovellusten alkuperäistä kääntämistä heti valmiiksi.
Lähde: will.com