การรวบรวมพื้นเมืองใน Quarkus - เหตุใดจึงสำคัญ

สวัสดีทุกคน! นี่เป็นโพสต์ที่สองในซีรีส์ของเราเกี่ยวกับ Quarkus - วันนี้เราจะพูดถึงการรวบรวมภาษาพื้นเมือง

ควาร์คัส เป็น Java stack ที่ปรับแต่งมาโดยเฉพาะ Kubernetes. แม้ว่าจะมีอะไรให้ทำอีกมากมายที่นี่ แต่เราได้ทำงานดีๆ มากมายในหลายๆ ด้าน รวมถึงการเพิ่มประสิทธิภาพ JVM และเฟรมเวิร์กจำนวนหนึ่ง หนึ่งในคุณสมบัติของ Quarkus ที่ดึงดูดความสนใจเพิ่มขึ้นจากนักพัฒนาคือแนวทางที่ครอบคลุมและราบรื่นในการเปลี่ยนโค้ด Java ให้เป็นไฟล์ปฏิบัติการสำหรับระบบปฏิบัติการเฉพาะ (เรียกว่า "การคอมไพล์แบบเนทีฟ") ซึ่งคล้ายกับ C และ C++ โดยที่การคอมไพล์ดังกล่าว มักจะเกิดขึ้นเมื่อสิ้นสุดรอบของการสร้าง การทดสอบ และการปรับใช้

แม้ว่าการคอมไพล์แบบเนทีฟจะมีความสำคัญ ดังที่เราจะแสดงด้านล่างนี้ แต่ก็ควรสังเกตว่า Quarkus ทำงานได้ดีมากบนเครื่อง Java ทั่วไปอย่าง OpenJDK Hotspot ต้องขอบคุณการปรับปรุงประสิทธิภาพที่เราได้นำไปใช้ทั่วทั้งสแต็ก ดังนั้นการคอมไพล์แบบเนทีฟจึงควรถือเป็นโบนัสเพิ่มเติมที่สามารถใช้ได้ตามต้องการหรือจำเป็น ในความเป็นจริง Quarkus อาศัย OpenJDK อย่างมากเมื่อพูดถึงรูปภาพเนทิฟ และโหมด dev ซึ่งเป็นที่ยอมรับอย่างอบอุ่นจากนักพัฒนา ช่วยให้มั่นใจได้ว่าจะทดสอบการเปลี่ยนแปลงได้เกือบจะทันทีเนื่องจากความสามารถขั้นสูงของการเรียกใช้โค้ดแบบไดนามิกที่ใช้งานใน Hotspot นอกจากนี้ เมื่อสร้างอิมเมจ GraalVM ดั้งเดิม จะใช้ไลบรารีคลาส OpenJDK และความสามารถของ HotSpot

เหตุใดคุณจึงต้องมีการคอมไพล์แบบเนทีฟหากทุกอย่างได้รับการปรับให้เหมาะสมที่สุดแล้ว? เราจะพยายามตอบคำถามด้านล่างนี้

เริ่มจากสิ่งที่ชัดเจนกันก่อน: Red Hat มีประสบการณ์มากมายในการเพิ่มประสิทธิภาพ JVM, สแต็ค และเฟรมเวิร์กในระหว่างการพัฒนาโครงการ JBoss, ภาษา:

• แอปพลิเคชันเซิร์ฟเวอร์ตัวแรกที่ทำงานในระบบคลาวด์บนแพลตฟอร์ม RedShift OpenShift.
• แอปพลิเคชันเซิร์ฟเวอร์แรกสำหรับการทำงานบนคอมพิวเตอร์ เสียบปลั๊กพีซี.
• แอปพลิเคชันเซิร์ฟเวอร์แรกที่รันบน ราสเบอร์รี่ Pi.
• โปรเจ็กต์ต่างๆ ที่ทำงานบนอุปกรณ์ Android.

เราจัดการกับความท้าทายในการใช้งานแอปพลิเคชัน Java ในระบบคลาวด์และบนอุปกรณ์ที่มีทรัพยากรจำกัด (อ่าน: IoT) มาหลายปีแล้ว และได้เรียนรู้ที่จะใช้ประโยชน์สูงสุดจาก JVM ในแง่ของประสิทธิภาพและการเพิ่มประสิทธิภาพหน่วยความจำ เช่นเดียวกับคนอื่นๆ เราทำงานร่วมกับการคอมไพล์แอปพลิเคชัน Java แบบเนทีฟมาเป็นเวลานาน กจจ, ไข้หวัดนก, เอ็กเซลซิเออร์ เจ็ต และแม้กระทั่ง Dalvik และเราตระหนักดีถึงข้อดีและข้อเสียของแนวทางนี้ (ตัวอย่างเช่น ภาวะที่กลืนไม่เข้าคายไม่ออกในการเลือกระหว่างความเป็นสากลของ "สร้างครั้งเดียว - ทำงานได้ทุกที่" และความจริงที่ว่าแอปพลิเคชันที่คอมไพล์มีขนาดเล็กกว่าและทำงานเร็วกว่า)

เหตุใดการพิจารณาข้อดีข้อเสียเหล่านี้จึงเป็นสิ่งสำคัญ เพราะในบางสถานการณ์ อัตราส่วนของพวกมันจะกลายเป็นปัจจัยชี้ขาด:

• ตัวอย่างเช่น ในสภาพแวดล้อมแบบไร้เซิร์ฟเวอร์/ที่ขับเคลื่อนด้วยเหตุการณ์ บริการก็ต้องเริ่มต้น แบบเรียลไทม์ (แบบแข็งหรือแบบอ่อน) เพื่อให้มีเวลาตอบสนองต่อเหตุการณ์ต่างๆ ต่างจากบริการถาวรที่มีอายุการใช้งานยาวนาน ระยะเวลาของ Cold Start จะเพิ่มเวลาตอบสนองต่อคำขออย่างมาก JVM ยังคงใช้เวลาจำนวนมากในการเริ่มต้นระบบ และแม้ว่าสิ่งนี้สามารถลดลงได้ในบางกรณีด้วยวิธีฮาร์ดแวร์ล้วนๆ ความแตกต่างระหว่างหนึ่งวินาทีถึง 5 มิลลิวินาทีอาจเป็นความแตกต่างระหว่างชีวิตและความตาย ใช่ ที่นี่ คุณสามารถทดลองสร้างเครื่อง Java สำรองยอดนิยมได้ (เช่น เราทำกับ กำลังย้าย OpenWhisk ไปยัง Knative) แต่ในตัวมันเองไม่ได้รับประกันว่าจะมี JVM เพียงพอที่จะประมวลผลคำขอตามขนาดโหลด และจากมุมมองทางเศรษฐกิจ นี่อาจไม่ใช่ตัวเลือกที่ถูกต้องที่สุด
• นอกจากนี้ยังมีอีกแง่มุมหนึ่งที่มักปรากฏขึ้น: การเช่าหลายรายการ แม้ว่า JVM จะมีความสามารถใกล้เคียงกับระบบปฏิบัติการมาก แต่ก็ยังไม่สามารถทำสิ่งที่เราคุ้นเคยใน Linux ได้ นั่นก็คือกระบวนการแยก ดังนั้นความล้มเหลวของเธรดเดียวอาจทำให้เครื่อง Java ทั้งหมดล่มได้ หลายๆ คนพยายามหลีกเลี่ยงข้อเสียนี้ด้วยการจัดสรร JVM แยกต่างหากสำหรับแอปพลิเคชันของผู้ใช้แต่ละคน เพื่อลดผลที่ตามมาของความล้มเหลว นี่ค่อนข้างสมเหตุสมผล แต่ไม่เหมาะกับการปรับขนาด
• นอกจากนี้ สำหรับแอปพลิเคชันบนคลาวด์ ตัวบ่งชี้สำคัญคือความหนาแน่นของบริการบนโฮสต์ การเปลี่ยนไปใช้ระเบียบวิธี 12 ปัจจัยการใช้งาน, ไมโครเซอร์วิส และ Kubernetes จะเพิ่มจำนวนเครื่อง Java ต่อแอปพลิเคชัน นั่นคือในอีกด้านหนึ่งทั้งหมดนี้ให้ความยืดหยุ่นและความน่าเชื่อถือ แต่ในขณะเดียวกันการใช้หน่วยความจำพื้นฐานในแง่ของการบริการก็เพิ่มขึ้นเช่นกันและค่าใช้จ่ายบางส่วนเหล่านี้ไม่จำเป็นอย่างเคร่งครัดเสมอไป ไฟล์ปฏิบัติการที่คอมไพล์แบบคงที่จะได้รับประโยชน์ที่นี่เนื่องจากเทคนิคการปรับให้เหมาะสมต่างๆ เช่น การกำจัดโค้ดที่ไม่ทำงานในระดับต่ำ เมื่ออิมเมจสุดท้ายรวมเฉพาะส่วนของเฟรมเวิร์ก (รวมถึง JDK เองด้วย) ที่บริการใช้จริง ดังนั้นการคอมไพล์ Quarkus แบบเนทิฟจึงช่วยวางอินสแตนซ์บริการไว้อย่างหนาแน่นบนโฮสต์โดยไม่กระทบต่อความปลอดภัย

ที่จริงแล้วข้อโต้แย้งข้างต้นก็เพียงพอที่จะเข้าใจเหตุผลของการรวบรวมเนทีฟจากมุมมองของผู้เข้าร่วมโครงการ Quarkus แล้ว อย่างไรก็ตาม มีอีกเหตุผลหนึ่งที่ไม่ใช่ด้านเทคนิคแต่ก็สำคัญเช่นกัน ในช่วงไม่กี่ปีที่ผ่านมา โปรแกรมเมอร์และบริษัทพัฒนาจำนวนมากได้ละทิ้ง Java ไปหันไปใช้ภาษาการเขียนโปรแกรมใหม่ๆ โดยเชื่อว่า Java พร้อมด้วย JVMs, สแต็ค และเฟรมเวิร์ก ได้กลายเป็นเกินไป ต้องใช้หน่วยความจำมาก ช้าเกินไป ฯลฯ

อย่างไรก็ตามนิสัยการใช้เครื่องมือเดียวกันในการแก้ปัญหาก็คือ มันไม่ถูกต้องเสมอไป. บางครั้งการถอยกลับและมองหาสิ่งอื่นจะดีกว่า และถ้า Quarkus ทำให้ผู้คนหยุดและคิด นั่นก็เป็นผลดีต่อระบบนิเวศ Java ทั้งหมด Quarkus นำเสนอมุมมองเชิงนวัตกรรมเกี่ยวกับวิธีสร้างแอปพลิเคชันที่มีประสิทธิภาพมากขึ้น ทำให้ Java มีความเกี่ยวข้องกับสถาปัตยกรรมแอปพลิเคชันใหม่ เช่น ไร้เซิร์ฟเวอร์ มากขึ้น นอกจากนี้ เนื่องจากความสามารถในการขยายได้ Quarkus จึงหวังว่าจะมีระบบนิเวศทั้งหมดของส่วนขยาย Java ซึ่งจะเพิ่มจำนวนเฟรมเวิร์กที่จะสนับสนุนการคอมไพล์เนทิฟในแอปพลิเคชันนอกกรอบอย่างมีนัยสำคัญ

ที่มา: will.com