Kamusta kayong lahat! Ito ang pangalawang post sa aming serye sa Quarkus - ngayon ay pag-uusapan natin ang tungkol sa katutubong compilation.
ay isang Java stack na iniayon para sa . Bagama't tiyak na marami pang dapat gawin dito, nakagawa kami ng maraming magandang gawain sa maraming aspeto, kabilang ang pag-optimize sa JVM at ilang mga frameworks. Ang isa sa mga tampok ng Quarkus na nakakuha ng mas mataas na interes mula sa mga developer ay ang komprehensibo, walang putol na diskarte nito sa paggawa ng Java code sa mga executable na file para sa isang partikular na operating system (tinatawag na "native compilation"), katulad ng C at C++, kung saan ang naturang compilation kadalasang nangyayari sa dulo ng isang cycle ng build, pagsubok, at deployment.
At bagama't mahalaga ang katutubong compilation, tulad ng ipapakita namin sa ibaba, dapat tandaan na gumagana nang mahusay ang Quarkus sa pinakakaraniwang Java machine, ang OpenJDK Hotspot, salamat sa mga pagpapahusay sa pagganap na ipinatupad namin sa buong stack. Samakatuwid, ang katutubong compilation ay dapat isaalang-alang bilang isang karagdagang bonus na maaaring gamitin ayon sa ninanais o kinakailangan. Sa katunayan, ang Quarkus ay lubos na umaasa sa OpenJDK pagdating sa mga katutubong larawan. At ang dev mode, na mainit na tinatanggap ng mga developer, ay nagsisiguro ng halos agarang pagsubok ng mga pagbabago dahil sa mga advanced na kakayahan ng dynamic na code execution na ipinatupad sa Hotspot. Bilang karagdagan, kapag lumilikha ng mga katutubong larawan ng GraalVM, ginagamit ang OpenJDK class library at mga kakayahan sa HotSpot.
Kaya bakit kailangan mo ng katutubong compilation kung ang lahat ay ganap na na-optimize? Susubukan naming sagutin ang tanong na ito sa ibaba.
Magsimula tayo sa halata: Ang Red Hat ay may malawak na karanasan sa pag-optimize ng mga JVM, stack at framework sa panahon ng pagbuo ng proyekto kabilang ang:
- Ang unang server ng application na gumana sa cloud sa platform .
- Ang unang server ng application na tumatakbo sa mga computer .
- Ang unang server ng application na tatakbo .
- Isang hanay ng mga proyektong tumatakbo sa mga device .
Hinarap namin ang mga hamon ng pagpapatakbo ng mga Java application sa cloud at sa mga device na pinaghihigpitan ng mapagkukunan (basahin: IoT) sa loob ng maraming taon at natutunan namin na sulitin ang JVM sa mga tuntunin ng pagganap at pag-optimize ng memorya. Tulad ng marami pang iba, nagtatrabaho kami sa katutubong compilation ng mga application ng Java sa mahabang panahon , , at kahit at alam namin ang mga kalamangan at kahinaan ng diskarteng ito (halimbawa, ang dilemma ng pagpili sa pagitan ng universality ng "build once - run-anywhere" at ang katotohanan na ang mga pinagsama-samang application ay mas maliit at tumatakbo nang mas mabilis).
Bakit mahalagang isaalang-alang ang mga kalamangan at kahinaan na ito? Dahil sa ilang mga sitwasyon ang kanilang ratio ay nagiging mapagpasyahan:
- Halimbawa, sa mga environment na walang server/event-driven kung saan sa (matigas o malambot) totoong oras upang magkaroon ng oras upang tumugon sa mga kaganapan. Hindi tulad ng matagal nang patuloy na serbisyo, dito ang tagal ng malamig na pagsisimula ay kritikal na nagpapataas sa oras ng pagtugon sa isang kahilingan. Ang JVM ay tumatagal pa rin ng isang malaking halaga ng oras upang magsimula, at habang ito ay maaaring mabawasan sa ilang mga kaso sa pamamagitan ng mga purong pamamaraan ng hardware, ang pagkakaiba sa pagitan ng isang segundo at 5 millisecond ay maaaring ang pagkakaiba sa pagitan ng buhay at kamatayan. Oo, dito maaari kang makipaglaro sa paglikha ng isang mainit na reserba ng Java machine (na, halimbawa, ginawa namin sa ), ngunit ito mismo ay hindi ginagarantiyahan na magkakaroon ng sapat na mga JVM upang iproseso ang mga kahilingan bilang mga sukat ng pagkarga. At mula sa isang pang-ekonomiyang punto ng view, ito ay marahil hindi ang pinaka-tamang opsyon.
- Dagdag pa, may isa pang aspeto na madalas na lumalabas: multitenancy. Sa kabila ng katotohanan na ang mga JVM ay napakalapit sa mga operating system sa kanilang mga kakayahan, hindi pa rin nila kayang gawin ang nakasanayan na natin sa Linux - ang mga proseso ng paghihiwalay. Samakatuwid, ang pagkabigo ng isang thread ay maaaring magpabagsak sa buong Java machine. Maraming tao ang nagsisikap na makayanan ang disbentaha na ito sa pamamagitan ng paglalaan ng hiwalay na JVM para sa bawat aplikasyon ng user upang mabawasan ang mga kahihinatnan ng isang pagkabigo. Ito ay medyo lohikal, ngunit hindi angkop sa pag-scale.
- Bilang karagdagan, para sa mga cloud-oriented na application, isang mahalagang tagapagpahiwatig ay ang density ng mga serbisyo sa host. Paglipat sa pamamaraan , ang mga microservice at Kubernetes ay nagdaragdag sa bilang ng mga Java machine bawat aplikasyon. Iyon ay, sa isang banda, ang lahat ng ito ay nagbibigay ng pagkalastiko at pagiging maaasahan, ngunit sa parehong oras ang pagkonsumo ng base memory sa mga tuntunin ng serbisyo ay tumataas din, at ang ilan sa mga gastos na ito ay hindi palaging mahigpit na kinakailangan. Nakikinabang dito ang statically compiled executable file dahil sa iba't ibang diskarte sa pag-optimize, tulad ng mababang antas ng dead-code elimination, kapag ang panghuling larawan ay kasama lang ang mga bahagi ng frameworks (kabilang ang JDK mismo) na aktwal na ginagamit ng serbisyo. Samakatuwid, nakakatulong ang katutubong compilation ng Quarkus na mailagay ang mga instance ng serbisyo sa host nang hindi nakompromiso ang seguridad.
Sa totoo lang, ang mga argumento sa itaas ay sapat na upang maunawaan ang katwiran ng katutubong compilation mula sa punto ng view ng mga kalahok sa proyekto ng Quarkus. Gayunpaman, may isa pa, hindi teknikal, ngunit mahalagang dahilan din: sa mga nagdaang taon, maraming programmer at kumpanya ng pag-unlad ang tumalikod sa Java pabor sa mga bagong programming language, sa paniniwalang ang Java, kasama ang mga JVM, stack at frameworks nito, ay naging masyadong gutom sa memorya, masyadong mabagal, atbp.
Gayunpaman, ang ugali ng paggamit ng parehong tool upang malutas ang anumang problema ay . Minsan mas mabuting tumalikod at maghanap ng iba. At kung gagawin ng Quarkus na huminto ang mga tao at mag-isip, mabuti iyon para sa buong Java ecosystem. Kinakatawan ng Quarkus ang isang makabagong pananaw kung paano bumuo ng mas mahusay na mga application, na ginagawang mas nauugnay ang Java sa mga bagong arkitektura ng application tulad ng walang server. Bilang karagdagan, dahil sa pagpapalawak nito, ang Quarkus ay inaasahan na magkakaroon ng isang buong ecosystem ng mga extension ng Java, na makabuluhang tumataas ang bilang ng mga framework na susuporta sa katutubong pagsasama-sama sa mga application sa labas ng kahon.
Pinagmulan: www.habr.com