سلام به همه! این دومین پست در مجموعه ما در Quarkus است - امروز در مورد کامپایل بومی صحبت خواهیم کرد.
یک پشته جاوا است که برای . در حالی که مطمئناً کارهای بیشتری برای انجام دادن در اینجا وجود دارد، ما در بسیاری از جنبه ها، از جمله بهینه سازی JVM و تعدادی چارچوب، کارهای خوبی انجام داده ایم. یکی از ویژگیهای کوارکوس که توجه بیشتر توسعهدهندگان را به خود جلب کرده است، رویکرد جامع و یکپارچه آن برای تبدیل کد جاوا به فایلهای اجرایی برای یک سیستم عامل خاص (اصطلاحاً «کامپایلسازی بومی»)، شبیه به C و C++ است که در آن چنین کامپایلسازی میشود. معمولاً در پایان یک چرخه ساخت، آزمایش و استقرار رخ می دهد.
و در حالی که کامپایل بومی مهم است، همانطور که در زیر نشان خواهیم داد، باید توجه داشت که Quarkus به لطف بهبودهای عملکردی که در سراسر پشته پیادهسازی کردهایم، واقعاً به خوبی روی رایجترین ماشین جاوا، OpenJDK Hotspot اجرا میشود. بنابراین، تدوین بومی باید به عنوان یک امتیاز اضافی در نظر گرفته شود که می تواند به دلخواه یا ضروری مورد استفاده قرار گیرد. در واقع، Quarkus به شدت به OpenJDK در مورد تصاویر بومی متکی است. و حالت توسعه دهنده، که به گرمی توسط توسعه دهندگان پذیرفته شده است، به دلیل قابلیت های پیشرفته اجرای کد پویا در هات اسپات، آزمایش تقریباً آنی تغییرات را تضمین می کند. علاوه بر این، هنگام ایجاد تصاویر بومی GraalVM، از کتابخانه کلاس OpenJDK و قابلیت های HotSpot استفاده می شود.
بنابراین، اگر همه چیز کاملاً بهینه شده باشد، چرا به کامپایل بومی نیاز دارید؟ در ادامه سعی خواهیم کرد به این سوال پاسخ دهیم.
بیایید با بدیهی شروع کنیم: Red Hat دارای تجربه گسترده ای در بهینه سازی JVM ها، پشته ها و چارچوب ها در طول توسعه پروژه است. ، شامل:
- اولین سرور برنامه ای که در فضای ابری روی پلتفرم کار می کند .
- اولین سرور برنامه برای اجرا بر روی کامپیوتر .
- اولین سرور برنامه ای که روی آن اجرا می شود .
- مجموعه ای از پروژه های در حال اجرا بر روی دستگاه ها .
ما سالهاست که با چالشهای اجرای برنامههای جاوا در فضای ابری و دستگاههای با محدودیت منابع (بخوانید: IoT) سروکار داریم و یاد گرفتهایم که از JVM از نظر عملکرد و بهینهسازی حافظه بیشترین بهره را ببریم. مانند بسیاری دیگر، ما برای مدت طولانی با کامپایل بومی برنامه های جاوا کار کرده ایم , , و حتی و ما به خوبی از مزایا و معایب این رویکرد آگاه هستیم (به عنوان مثال، معضل انتخاب بین جهانی بودن "یک بار - اجرا - هرجا" و این واقعیت که برنامه های کامپایل شده کوچکتر هستند و سریعتر اجرا می شوند).
چرا توجه به این مزایا و معایب مهم است؟ زیرا در برخی شرایط نسبت آنها تعیین کننده می شود:
- به عنوان مثال، در محیط های بدون سرور/رویداد محور که در آن در زمان واقعی (سخت یا نرم) به منظور داشتن زمان برای پاسخگویی به رویدادها. برخلاف خدمات پایدار با عمر طولانی، در اینجا مدت زمان شروع سرد، زمان پاسخگویی به درخواست را به شدت افزایش می دهد. راه اندازی JVM هنوز زمان قابل توجهی نیاز دارد و در حالی که در برخی موارد می توان با روش های سخت افزاری خالص این زمان را کاهش داد، تفاوت بین یک ثانیه و 5 میلی ثانیه می تواند تفاوت بین مرگ و زندگی باشد. بله، در اینجا می توانید با ایجاد یک ذخیره داغ از ماشین های جاوا (که برای مثال ما با ، اما این به خودی خود تضمین نمی کند که JVM های کافی برای پردازش درخواست ها به عنوان مقیاس بار وجود داشته باشد. و از نظر اقتصادی، این احتمالاً صحیح ترین گزینه نیست.
- علاوه بر این، جنبه دیگری وجود دارد که اغلب ظاهر می شود: چند اجاره ای. علیرغم این واقعیت که JVM ها از نظر قابلیت های خود بسیار به سیستم عامل ها نزدیک شده اند، آنها هنوز قادر به انجام کاری که ما در لینوکس به آن عادت داریم - فرآیندهای جداسازی - را ندارند. بنابراین، شکست یک رشته می تواند کل ماشین جاوا را از بین ببرد. بسیاری از افراد سعی میکنند با اختصاص یک JVM جداگانه برای هر برنامه کاربردی، این اشکال را برطرف کنند تا عواقب خرابی را به حداقل برسانند. این کاملاً منطقی است، اما با مقیاس بندی مناسب نیست.
- علاوه بر این، برای برنامه های کاربردی ابر محور، یک شاخص مهم تراکم سرویس ها در میزبان است. گذار به روش شناسی ، میکروسرویس ها و Kubernetes تعداد ماشین های جاوا را در هر برنامه افزایش می دهد. یعنی از یک طرف همه اینها کشش و قابلیت اطمینان را فراهم می کند، اما در عین حال مصرف حافظه پایه از نظر سرویس نیز افزایش می یابد و برخی از این هزینه ها همیشه به شدت ضروری نیستند. فایلهای اجرایی کامپایلشده استاتیک در اینجا به دلیل تکنیکهای بهینهسازی مختلف، مانند حذف کد مرده سطح پایین، سود میبرند، زمانی که تصویر نهایی فقط شامل آن بخشهایی از چارچوبها (از جمله خود JDK) است که سرویس واقعاً از آنها استفاده میکند. بنابراین، کامپایل بومی Quarkus کمک میکند تا نمونههای سرویس را به طور فشرده در میزبان بدون به خطر انداختن امنیت قرار دهید.
در واقع، استدلال های بالا برای درک توجیه کامپایل بومی از دیدگاه شرکت کنندگان پروژه کوارکوس کافی است. با این حال، دلیل دیگری، غیر فنی، اما در عین حال مهم وجود دارد: در سالهای اخیر، بسیاری از برنامهنویسان و شرکتهای توسعهدهنده جاوا را به نفع زبانهای برنامهنویسی جدید کنار گذاشتهاند و معتقدند که جاوا، همراه با JVMها، پشتهها و فریمورکهای آن، بیش از حد شده است. تشنه حافظه، خیلی کند و غیره
با این حال، عادت استفاده از ابزار مشابه برای حل هر مشکلی است . گاهی اوقات بهتر است یک قدم به عقب برگردیم و به دنبال چیز دیگری باشیم. و اگر کوارکوس مردم را وادار به مکث و تفکر کند، این برای کل اکوسیستم جاوا خوب است. Quarkus نمایانگر یک دیدگاه نوآورانه از نحوه ساخت برنامه های کاربردی کارآمدتر است که جاوا را با معماری های برنامه های جدید مانند بدون سرور مرتبط تر می کند. علاوه بر این، به دلیل توسعه پذیری، Quarkus امیدوار است که یک اکوسیستم کامل از برنامه های افزودنی جاوا داشته باشد، که به طور قابل توجهی تعداد فریم ورک هایی را افزایش می دهد که از کامپایل بومی در برنامه های خارج از جعبه پشتیبانی می کنند.
منبع: www.habr.com
