Herkese selam! Bu Quarkus serimizin ikinci gönderisi; bugün yerel derleme hakkında konuşacağız.
için özel olarak tasarlanmış bir Java yığınıdır . Burada kesinlikle yapılacak daha çok şey olsa da, JVM'yi ve bir dizi çerçeveyi optimize etmek de dahil olmak üzere birçok konuda çok iyi işler yaptık. Quarkus'un geliştiricilerin artan ilgisini çeken özelliklerinden biri, Java kodunu C ve C++'a benzer şekilde belirli bir işletim sistemi için ("yerel derleme" olarak adlandırılan) çalıştırılabilir dosyalara dönüştürmeye yönelik kapsamlı ve kusursuz yaklaşımıdır. genellikle derleme, test ve dağıtım döngüsünün sonunda gerçekleşir.
Aşağıda göstereceğimiz gibi yerel derleme önemli olsa da, yığın boyunca uyguladığımız performans iyileştirmeleri sayesinde Quarkus'un en yaygın Java makinesi olan OpenJDK Hotspot'ta gerçekten iyi çalıştığı unutulmamalıdır. Bu nedenle native derleme, istenildiği veya gerekli olduğu şekilde kullanılabilecek ek bir bonus olarak değerlendirilmelidir. Aslında Quarkus, yerel görseller söz konusu olduğunda büyük ölçüde OpenJDK'ya güveniyor. Geliştiriciler tarafından sıcak bir şekilde kabul edilen geliştirme modu, Hotspot'ta uygulanan dinamik kod yürütmenin gelişmiş yetenekleri sayesinde değişikliklerin neredeyse anında test edilmesini sağlar. Ayrıca native GraalVM görselleri oluşturulurken OpenJDK sınıf kütüphanesi ve HotSpot yeteneklerinden faydalanılıyor.
Peki her şey zaten mükemmel şekilde optimize edilmişse neden yerel derlemeye ihtiyacınız var? Bu soruyu aşağıda cevaplamaya çalışacağız.
Açık olanla başlayalım: Red Hat, proje geliştirme sırasında JVM'leri, yığınları ve çerçeveleri optimize etme konusunda kapsamlı deneyime sahiptir. , içermek:
- Platformda bulutta çalışan ilk uygulama sunucusu .
- Bilgisayarlarda çalışan ilk uygulama sunucusu .
- Çalıştırılacak ilk uygulama sunucusu .
- Cihazlarda çalışan çeşitli projeler .
Java uygulamalarını bulutta ve kaynak kısıtlı cihazlarda (okuma: IoT) çalıştırmanın zorluklarıyla uzun yıllardır uğraşıyoruz ve performans ve bellek optimizasyonu açısından JVM'den en iyi şekilde yararlanmayı öğrendik. Diğerleri gibi biz de uzun süredir Java uygulamalarının yerel derlemesi üzerinde çalışıyoruz. , , ve hatta ve bu yaklaşımın artılarının ve eksilerinin çok iyi farkındayız (örneğin, "bir kez oluştur - her yerde çalıştır" evrenselliği ile derlenmiş uygulamaların daha küçük ve daha hızlı çalışması arasında seçim yapma ikilemi).
Bu artıları ve eksileri dikkate almak neden önemlidir? Çünkü bazı durumlarda bunların oranı belirleyici oluyor:
- Örneğin, sunucusuz/olay odaklı ortamlarda olaylara yanıt verecek zamana sahip olmak için (sert veya yumuşak) gerçek zamanlı olarak. Uzun ömürlü kalıcı hizmetlerin aksine, burada soğuk başlatmanın süresi, bir isteğe yanıt verme süresini kritik ölçüde artırır. JVM'nin başlatılması hala önemli miktarda zaman alıyor ve bu süre bazı durumlarda salt donanım yöntemleriyle azaltılabilse de, bir saniye ile 5 milisaniye arasındaki fark, yaşamla ölüm arasındaki fark olabilir. Evet, burada Java makinelerinin etkin bir rezervini oluşturmakla uğraşabilirsiniz (bunu örneğin ), ancak bu kendi başına, yük ölçeklendikçe istekleri işlemek için yeterli JVM'nin olacağını garanti etmez. Ekonomik açıdan bakıldığında bu muhtemelen en doğru seçenek değildir.
- Ayrıca sıklıkla ortaya çıkan başka bir husus daha var: çoklu kiracılık. JVM'ler yetenekleri açısından işletim sistemlerine çok yaklaşmış olsalar da, Linux'ta çok alıştığımız izolasyon süreçlerini hala yapma yeteneğine sahip değiller. Bu nedenle, bir iş parçacığının arızalanması tüm Java makinesinin çökmesine neden olabilir. Birçok kişi, bir arızanın sonuçlarını en aza indirmek amacıyla her kullanıcının uygulaması için ayrı bir JVM ayırarak bu dezavantajı aşmaya çalışır. Bu oldukça mantıklı ancak ölçeklendirmeye pek uymuyor.
- Ayrıca bulut odaklı uygulamalar için önemli bir gösterge de ana bilgisayardaki hizmetlerin yoğunluğudur. Metodolojiye geçiş , mikro hizmetler ve Kubernetes, uygulama başına Java makinesi sayısını artırır. Yani tüm bunlar bir yandan esneklik ve güvenilirlik sağlıyor ama aynı zamanda hizmet açısından temel hafıza tüketimi de artıyor ve bu harcamaların bir kısmı her zaman kesinlikle gerekli olmuyor. Statik olarak derlenen yürütülebilir dosyalar, son görüntünün yalnızca hizmetin gerçekten kullandığı çerçevelerin (JDK'nın kendisi dahil) bölümlerini içerdiği düşük düzeyli ölü kodun ortadan kaldırılması gibi çeşitli optimizasyon tekniklerinden dolayı burada fayda sağlar. Bu nedenle Quarkus'un yerel derlemesi, güvenlikten ödün vermeden hizmet örneklerinin ana makineye yoğun bir şekilde yerleştirilmesine yardımcı olur.
Aslında yukarıdaki argümanlar, yerel derlemenin gerekçesini Quarkus projesi katılımcılarının bakış açısından anlamak için zaten yeterli. Ancak teknik olmayan ama aynı zamanda önemli bir neden daha var: Son yıllarda birçok programcı ve geliştirme şirketi, JVM'leri, yığınları ve çerçeveleriyle birlikte Java'nın da çok şey haline geldiğine inanarak yeni programlama dilleri uğruna Java'yı terk etti. hafızaya aç, çok yavaş vb.
Ancak herhangi bir sorunu çözmek için aynı aracı kullanma alışkanlığı . Bazen bir adım geri çekilip başka bir şey aramak daha iyidir. Quarkus insanların durup düşünmesini sağlıyorsa bu tüm Java ekosistemi için iyidir. Quarkus, Java'yı sunucusuz gibi yeni uygulama mimarileriyle daha alakalı hale getirerek, daha verimli uygulamaların nasıl geliştirileceğine dair yenilikçi bir bakış açısı sunar. Buna ek olarak, genişletilebilirliği nedeniyle Quarkus'un, Java uzantılarından oluşan tam bir ekosisteme sahip olacağını ve kullanıma hazır uygulamalarda yerel derlemeyi destekleyecek çerçevelerin sayısını önemli ölçüde artıracağını umuyoruz.
Kaynak: habr.com