Бүгдээрээ сайн уу! Манай Quarkus цувралын хоёр дахь нийтлэлд тавтай морил - өнөөдөр бид уугуул эмхэтгэлийн талаар ярилцах болно.
- нь Java-д зориулагдсан стек юм Хийх зүйл их байгаа ч бид JVM оновчлол болон хэд хэдэн хүрээ зэрэг олон талыг сайтар судалсан. Quarkus-ийн хөгжүүлэгчдийн сонирхлыг ихэд татсан нэг онцлог нь Java кодыг C болон C++-тэй төстэй үйлдлийн системд ("уугуул эмхэтгэл" гэж нэрлэдэг) гүйцэтгэх боломжтой файл болгон хөрвүүлэх цогц, саадгүй арга бөгөөд ийм эмхэтгэл нь бүтээх, турших, байршуулах мөчлөгийн төгсгөлд тохиолддог.
Эх сурвалжийн эмхэтгэл чухал хэдий ч бид доор харуулах болно, гэхдээ бидний стек дээр хэрэгжүүлсэн гүйцэтгэлийн сайжруулалтын ачаар Quarkus нь стандарт OpenJDK Hotspot Java машин дээр маш сайн ажилладаг гэдгийг тэмдэглэх нь зүйтэй. Тиймээс уугуул эмхэтгэлийг нэмэлт урамшуулал гэж үзэх нь зүйтэй бөгөөд хүссэн эсвэл шаардлагатай үед ашиглах боломжтой. Үнэн хэрэгтээ, уугуул зургуудын тухай ярихад Quarkus OpenJDK дээр ихээхэн найддаг. Мөн сайн хүлээн авсан хөгжүүлэлтийн горим нь Hotspot-ийн дэвшилтэт динамик код гүйцэтгэх чадамжийн ачаар өөрчлөлтийг шуурхай шалгах боломжийг олгодог. Цаашилбал, уугуул GraalVM зургууд нь OpenJDK ангиллын номын сан болон HotSpot-ын боломжийг ашигладаг.
Хэрэв бүх зүйл аль хэдийн маш сайн оновчтой болсон бол яагаад бидэнд эх эмхэтгэл хэрэгтэй байна вэ? Бид энэ асуултад доор хариулахыг хичээх болно.
Тодорхой зүйлээс эхэлцгээе: Red Hat нь төсөл боловсруулах явцад JVM, стек, фреймворкуудыг оновчтой болгох арвин туршлагатай. Үүнд:
- Платформ дээрх үүлэн дээр ажиллах анхны програмын сервер .
- Компьютер дээр ажиллах анхны програмын сервер .
- Ажиллаж буй анхны програмын сервер .
- Төхөөрөмжүүд дээр ажиллаж байгаа хэд хэдэн төслүүд .
Бид Java програмуудыг үүлэн болон нөөц хязгаарлагдмал төхөөрөмжүүд дээр (жишээ нь, IoT) олон жилийн турш ажиллуулахаар ажиллаж байгаа бөгөөд гүйцэтгэл, санах ойн оновчтой байдлын хувьд JVM-г хэрхэн хамгийн их хэмжээгээр шахаж сурсан. Бусад олон хүмүүсийн нэгэн адил бид Java програмуудын эх хувилбар дээр удаан хугацаанд ажиллаж байна. , , мөн бүр Мөн бид энэ аргын давуу болон сул талуудыг сайн мэддэг (жишээлбэл, "нэг удаа бүтээх - хаана ч ажиллуулах" олон талт байдал, эмхэтгэсэн програмууд нь хэмжээ багатай, илүү хурдан эхлүүлэх гэсэн хоёрын хооронд сонголт хийх эргэлзэл).
Эдгээр давуу болон сул талуудыг авч үзэх нь яагаад тийм чухал вэ? Учир нь зарим тохиолдолд тэдний тэнцвэр шийдэмгий болдог:
- Жишээлбэл, сервергүй/үйл явдалд тулгуурласан орчинд хаана үйл явдалд хариу үйлдэл үзүүлэхийн тулд хатуу эсвэл зөөлөн бодит цагийн горимд. Урт хугацааны байнгын үйлчилгээнээс ялгаатай нь хүйтэн эхлэх хугацаа нь хүсэлтэд хариу өгөх хугацааг эрс нэмэгдүүлдэг. JVM-ийг эхлүүлэхэд ихээхэн цаг хугацаа шаардагддаг бөгөөд зарим тохиолдолд үүнийг зөвхөн техник хангамжийн аргаар багасгаж болох ч нэг секундээс 5 миллисекунд хүртэлх зөрүү нь амь нас, үхлийн асуудал байж болно. Тийм ээ, та Java машинуудын халуун нөөцийг бий болгох талаар тоглож болно (бид үүнийг, жишээлбэл, хэзээ ), гэхдээ энэ нь дангаараа ачааллын масштабын хувьд хүсэлтийг шийдвэрлэх хангалттай тооны JVM-ийн баталгаа биш юм. Мөн эдийн засгийн үүднээс авч үзвэл энэ нь мэдээжийн хэрэг хамгийн сайн сонголт биш юм.
- Дараа нь олон түрээсийн асуудал байнга гарч ирдэг. JVM-үүд үйлдлийн системүүдтэй чадавхаараа илүү ойр болсон ч бидний дассан зүйлсийг адилхан аргаар хийх чадваргүй хэвээр байна. Linux'e – процессуудыг тусгаарлах. Тиймээс ганц урсгалын алдаа нь Java машиныг бүхэлд нь унагааж болзошгүй. Олон хүн алдааны нөлөөллийг багасгахын тулд хэрэглэгч бүрийн програмд тусдаа JVM зориулан үүнийг тойрч гарахыг хичээдэг. Энэ нь нэлээд логик боловч сайн масштабтай биш юм.
- Нэмж дурдахад, үүлэн программуудын хувьд хост дээрх үйлчилгээний нягтрал нь чухал үзүүлэлт юм. Арга зүйд шилжих , microservices болон Kubernetes нь програм бүрт Java машинуудын тоог нэмэгдүүлдэг. Энэ нь уян хатан байдал, найдвартай байдлыг хангахын зэрэгцээ нэг үйлчилгээнд ногдох санах ойн үндсэн хэрэглээг нэмэгдүүлдэг бөгөөд зарим нь үргэлж хатуу шаардлагагүй байдаг. Статик байдлаар эмхэтгэсэн гүйцэтгэгдэх файлууд нь эцсийн зураг дээр зөвхөн тухайн үйлчилгээний бодит ашигладаг фреймворкийн хэсгүүдийг (JDK-г оруулаад) багтаасан доод түвшний үхсэн кодыг арилгах гэх мэт янз бүрийн оновчлолын аргуудаас ашиг тус хүртдэг. Тиймээс, Quarkus-ийн уугуул эмхэтгэл нь аюулгүй байдлыг алдагдуулахгүйгээр хост дээр үйлчилгээний тохиолдлуудыг илүү нягт түгээхэд тусалдаг.
Үнэн хэрэгтээ, дээр дурдсан аргументууд нь Кваркус төслийн оролцогчдын үүднээс уугуул эмхэтгэлийн үндэслэлийг ойлгоход хангалттай юм. Гэсэн хэдий ч, өөр нэг техникийн бус, гэхдээ адил чухал шалтгаан бий: сүүлийн жилүүдэд олон програмистууд болон хөгжүүлэгчид Java-г орхиж, шинэ програмчлалын хэлүүдийг илүүд үзэж, Java-г JVM, стек, фреймворкуудын хамт санах ойд хэт өлсгөлөн, хэт удаан гэх мэт болсон гэж үзэж байна.
Гэсэн хэдий ч аливаа асуудлыг шийдэхийн тулд ижил хэрэгслийг ашиглах зуршил байдаг Заримдаа ухарч, өөр газар хайх нь дээр. Хэрэв Quarkus хүмүүсийг түр зогсоож, эргэцүүлэн бодоход хүргэдэг бол энэ нь Java-гийн бүх экосистемд сайнаар нөлөөлнө. Quarkus нь Java-г сервергүй гэх мэт шинэ хэрэглээний архитектурт илүү хамааралтай болгож, илүү үр ашигтай програмуудыг бүтээх шинэлэг хандлагыг агуулсан байдаг. Цаашилбал, өргөтгөх боломжтой байдгаараа Quarkus нь Java өргөтгөлүүдийн бүхэл бүтэн экосистемийг цуглуулж, жинхэнэ эмхэтгэлийг дэмжих фрэймворкуудын тоог мэдэгдэхүйц нэмэгдүүлэх болно гэж найдаж байна.
Эх сурвалж: www.habr.com
