Բարեւ բոլորին! Սա Quarkus-ի մեր շարքի երկրորդ գրառումն է. այսօր մենք կխոսենք մայրենի հավաքածուի մասին:
Java ստեկ է, որը հարմարեցված է . Թեև այստեղ, անշուշտ, անելու շատ ավելին կա, մենք շատ լավ աշխատանք ենք կատարել բազմաթիվ ասպեկտների վրա, ներառյալ JVM-ի և մի շարք շրջանակների օպտիմալացումը: Quarkus-ի առանձնահատկություններից մեկը, որը մեծ հետաքրքրություն է առաջացրել մշակողների կողմից, նրա համապարփակ, անխափան մոտեցումն է՝ Java կոդը գործարկվող ֆայլերի վերածելու կոնկրետ օպերացիոն համակարգի համար (այսպես կոչված՝ «բնական կոմպիլացիա»), որը նման է C-ին և C++-ին, որտեղ նման կոմպիլյացիան սովորաբար տեղի է ունենում կառուցման, փորձարկման և տեղակայման ցիկլի վերջում:
Եվ չնայած հայրենի կոմպիլյացիան կարևոր է, ինչպես ցույց կտանք ստորև, պետք է նշել, որ Quarkus-ը իսկապես լավ է աշխատում ամենատարածված Java մեքենայի՝ OpenJDK Hotspot-ի վրա՝ շնորհիվ կատարողականի բարելավումների, որոնք մենք ներդրել ենք ամբողջ փաթեթում: Հետևաբար, հայրենի կոմպիլյացիան պետք է դիտարկել որպես լրացուցիչ բոնուս, որը կարող է օգտագործվել ըստ ցանկության կամ անհրաժեշտության: Փաստորեն, Quarkus-ը մեծապես ապավինում է OpenJDK-ին, երբ խոսքը վերաբերում է բնիկ պատկերներին: Իսկ մշակողների կողմից ջերմորեն ընդունված մշակողների ռեժիմը ապահովում է փոփոխությունների գրեթե ակնթարթային փորձարկում՝ շնորհիվ Hotspot-ում ներդրված դինամիկ կոդի կատարման առաջադեմ հնարավորությունների: Բացի այդ, GraalVM-ի բնիկ պատկերներ ստեղծելիս օգտագործվում են OpenJDK դասի գրադարանը և HotSpot-ի հնարավորությունները։
Ուրեմն ինչու՞ է ձեզ անհրաժեշտ բնօրինակ կոմպիլյացիան, եթե ամեն ինչ արդեն կատարյալ օպտիմիզացված է: Ստորև կփորձենք պատասխանել այս հարցին:
Սկսենք ակնհայտից. Red Hat-ը նախագծի մշակման ընթացքում JVM-ների, կույտերի և շրջանակների օպտիմալացման մեծ փորձ ունի: , այդ թվում՝
- Առաջին հավելվածի սերվերը, որն աշխատում է ամպի վրա հարթակի վրա .
- Համակարգիչների վրա գործարկվող առաջին հավելվածի սերվերը .
- Առաջին հավելվածի սերվերը, որի վրա գործարկվում է .
- Սարքերի վրա աշխատող մի շարք նախագծեր .
Մենք երկար տարիներ առնչվում ենք ամպում և ռեսուրսներով սահմանափակ սարքերում (կարդալ՝ IoT) Java հավելվածների գործարկման մարտահրավերներին և սովորել ենք առավելագույն օգուտ քաղել JVM-ից՝ կատարողականի և հիշողության օպտիմալացման առումով: Ինչպես շատ ուրիշներ, մենք երկար ժամանակ աշխատել ենք Java հավելվածների հայրենական կոմպիլյացիայի հետ , , եւ նույնիսկ և մենք քաջատեղյակ ենք այս մոտեցման դրական և բացասական կողմերի մասին (օրինակ՝ «կառուցել մեկ անգամ – գործարկել-որևէ տեղ» ունիվերսալության և այն փաստի միջև, որ կազմված հավելվածներն ավելի փոքր են և ավելի արագ են աշխատում):
Ինչու՞ է կարևոր հաշվի առնել այս դրական և բացասական կողմերը: Քանի որ որոշ իրավիճակներում նրանց հարաբերակցությունը դառնում է որոշիչ.
- Օրինակ՝ առանց սերվերի/իրադարձությունների վրա հիմնված միջավայրերում, որտեղ (կոշտ կամ փափուկ) իրական ժամանակում՝ իրադարձություններին արձագանքելու ժամանակ ունենալու համար: Ի տարբերություն երկարակյաց մշտական ծառայությունների, այստեղ սառը մեկնարկի տեւողությունը խիստ մեծացնում է հարցմանը պատասխանելու ժամանակը: JVM-ի գործարկման համար դեռևս զգալի ժամանակ է պահանջվում, և թեև դա որոշ դեպքերում կարող է կրճատվել մաքուր ապարատային մեթոդներով, մեկ վայրկյանից մինչև 5 միլիվայրկյան տարբերությունը կարող է լինել կյանքի և մահվան տարբերությունը: Այո, այստեղ դուք կարող եք խաղալ Java մեքենաների տաք ռեզերվ ստեղծելով (ինչը, օրինակ, մենք արեցինք. ), բայց դա ինքնին չի երաշխավորում, որ կլինեն բավարար JVM-ներ՝ բեռնվածության մասշտաբով հարցումները մշակելու համար: Իսկ տնտեսական տեսանկյունից սա թերեւս ամենաճիշտ տարբերակը չէ։
- Ավելին, կա ևս մեկ ասպեկտ, որը հաճախ ի հայտ է գալիս՝ բազմավճար: Չնայած այն հանգամանքին, որ JVM-ներն իրենց հնարավորություններով շատ մոտ են եկել օպերացիոն համակարգերին, նրանք դեռևս ի վիճակի չեն անել այն, ինչին մենք այնքան սովոր ենք Linux-ում՝ մեկուսացնելու գործընթացները: Հետևաբար, մեկ թեմայի ձախողումը կարող է տապալել ամբողջ Java մեքենան: Շատերը փորձում են շրջանցել այս թերությունը՝ յուրաքանչյուր օգտատիրոջ հավելվածի համար հատկացնելով առանձին JVM՝ ձախողման հետևանքները նվազագույնի հասցնելու համար: Սա միանգամայն տրամաբանական է, բայց լավ չի համապատասխանում մասշտաբի հետ:
- Բացի այդ, ամպի վրա հիմնված հավելվածների համար կարևոր ցուցանիշ է ծառայությունների խտությունը հոսթի վրա։ Անցում մեթոդաբանության , microservices-ը և Kubernetes-ը մեծացնում են Java մեքենաների քանակը մեկ հավելվածում: Այսինքն, մի կողմից, այս ամենը ապահովում է առաձգականություն և հուսալիություն, բայց միևնույն ժամանակ ավելանում է նաև բազային հիշողության սպառումը սպասարկման առումով, և այդ ծախսերի մի մասը միշտ չէ, որ խիստ անհրաժեշտ է։ Ստատիկ կերպով կազմված գործարկվող ֆայլերն այստեղ օգուտ են քաղում օպտիմիզացման տարբեր մեթոդների շնորհիվ, ինչպիսիք են ցածր մակարդակի մեռած կոդերի վերացումը, երբ վերջնական պատկերը ներառում է շրջանակների միայն այն մասերը (ներառյալ հենց JDK-ն), որոնք իրականում օգտագործում է ծառայությունը: Հետևաբար, Quarkus-ի բնիկ կոմպիլյացիան օգնում է խիտ տեղադրել սպասարկման օրինակները հոսթի վրա՝ չվնասելով անվտանգությունը:
Փաստորեն, վերոնշյալ փաստարկներն արդեն բավական են՝ հասկանալու հայրենի կոմպիլյացիայի հիմնավորումը Quarkus նախագծի մասնակիցների տեսանկյունից: Այնուամենայնիվ, կա ևս մեկ, ոչ տեխնիկական, բայց նաև կարևոր պատճառ. վերջին տարիներին շատ ծրագրավորողներ և ծրագրավորողներ լքել են Java-ն՝ հօգուտ նոր ծրագրավորման լեզուների՝ հավատալով, որ Java-ն իր JVM-ների, stacks-ի և Framework-ի հետ մեկտեղ դարձել է նաև: հիշողության քաղցած, չափազանց դանդաղ և այլն:
Այնուամենայնիվ, սովորություն է օգտագործել նույն գործիքը ցանկացած խնդիր լուծելու համար . Երբեմն ավելի լավ է մի քայլ հետ գնալ և այլ բան փնտրել: Եվ եթե Quarkus-ը ստիպում է մարդկանց դադար տալ և մտածել, ապա դա լավ է Java-ի ողջ էկոհամակարգի համար: Quarkus-ը ներկայացնում է նորարարական տեսակետ, թե ինչպես ստեղծել ավելի արդյունավետ հավելվածներ՝ Java-ն ավելի համապատասխան դարձնելով հավելվածների նոր ճարտարապետություններին, ինչպիսին է առանց սերվերի: Բացի այդ, իր ընդարձակելիության շնորհիվ, Quarkus-ը հուսով է կունենա Java ընդլայնումների մի ամբողջ էկոհամակարգ՝ զգալիորեն ավելացնելով շրջանակների թիվը, որոնք կաջակցեն հայրենական կոմպիլյացիան առանց տուփի հավելվածներում:
Source: www.habr.com