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