Chào mọi người! Đây là bài đăng thứ hai trong loạt bài về Quarkus của chúng tôi - hôm nay chúng ta sẽ nói về việc biên soạn bản địa.
là một ngăn xếp Java được thiết kế riêng cho . Mặc dù chắc chắn còn nhiều việc phải làm ở đây nhưng chúng tôi đã làm được rất nhiều việc tốt trên nhiều khía cạnh, bao gồm tối ưu hóa JVM và một số khung công tác. Một trong những tính năng của Quarkus đã thu hút sự quan tâm ngày càng tăng từ các nhà phát triển là cách tiếp cận liền mạch, toàn diện của nó để biến mã Java thành các tệp thực thi cho một hệ điều hành cụ thể (được gọi là "biên dịch gốc"), tương tự như C và C++, trong đó việc biên dịch như vậy thường xảy ra ở cuối chu kỳ xây dựng, thử nghiệm và triển khai.
Và mặc dù quá trình biên dịch gốc rất quan trọng, như chúng tôi sẽ trình bày bên dưới, nhưng cần lưu ý rằng Quarkus chạy rất tốt trên máy Java phổ biến nhất, OpenJDK Hotspot, nhờ những cải tiến hiệu suất mà chúng tôi đã triển khai trong toàn bộ ngăn xếp. Do đó, việc biên dịch gốc nên được coi là một phần thưởng bổ sung có thể được sử dụng khi muốn hoặc cần thiết. Trên thực tế, Quarkus phụ thuộc rất nhiều vào OpenJDK khi nói đến hình ảnh gốc. Và chế độ nhà phát triển, được các nhà phát triển chấp nhận nồng nhiệt, đảm bảo kiểm tra các thay đổi gần như tức thời nhờ khả năng thực thi mã động nâng cao được triển khai trong Hotspot. Ngoài ra, khi tạo hình ảnh GraalVM gốc, thư viện lớp OpenJDK và khả năng HotSpot sẽ được sử dụng.
Vậy tại sao bạn cần biên dịch gốc nếu mọi thứ đã được tối ưu hóa hoàn hảo? Chúng tôi sẽ cố gắng trả lời câu hỏi này dưới đây.
Hãy bắt đầu với điều hiển nhiên: Red Hat có nhiều kinh nghiệm tối ưu hóa các JVM, ngăn xếp và khung trong quá trình phát triển dự án , ví dụ:
- Máy chủ ứng dụng đầu tiên hoạt động trên nền tảng đám mây .
- Máy chủ ứng dụng đầu tiên chạy trên máy tính .
- Máy chủ ứng dụng đầu tiên chạy trên .
- Một loạt các dự án chạy trên thiết bị .
Chúng tôi đã giải quyết các thách thức khi chạy các ứng dụng Java trên đám mây và trên các thiết bị có giới hạn tài nguyên (đọc: IoT) trong nhiều năm và đã học cách tận dụng tối đa JVM về mặt hiệu suất và tối ưu hóa bộ nhớ. Giống như nhiều người khác, chúng tôi đã làm việc với việc biên dịch nguyên gốc các ứng dụng Java trong một thời gian dài thông qua , , và thậm chí và chúng tôi nhận thức rõ những ưu và nhược điểm của phương pháp này (ví dụ: vấn đề nan giải khi lựa chọn giữa tính phổ biến của “xây dựng một lần - chạy mọi nơi” và thực tế là các ứng dụng được biên dịch nhỏ hơn và chạy nhanh hơn).
Tại sao điều quan trọng là phải xem xét những ưu và nhược điểm này? Bởi vì trong một số tình huống, tỷ lệ của chúng trở nên quyết định:
- Ví dụ: trong môi trường không có máy chủ/theo hướng sự kiện, nơi trong thời gian thực (cứng hoặc mềm) để có thời gian phản hồi các sự kiện. Không giống như các dịch vụ liên tục tồn tại lâu dài, ở đây thời gian khởi động nguội làm tăng đáng kể thời gian phản hồi cho một yêu cầu. JVM vẫn cần một lượng thời gian đáng kể để khởi động và mặc dù điều này có thể được giảm bớt trong một số trường hợp bằng các phương pháp phần cứng thuần túy, nhưng sự khác biệt giữa một giây và 5 mili giây có thể là sự khác biệt giữa sự sống và cái chết. Có, ở đây bạn có thể thử tạo một kho dự trữ nóng các máy Java (ví dụ: chúng tôi đã làm với ), nhưng bản thân điều này không đảm bảo rằng sẽ có đủ JVM để xử lý các yêu cầu dưới dạng thang tải. Và từ góc độ kinh tế, đây có lẽ không phải là phương án đúng đắn nhất.
- Hơn nữa, có một khía cạnh khác thường xuất hiện: nhiều người thuê nhà. Mặc dù thực tế là các JVM đã tiến rất gần đến các hệ điều hành về khả năng của chúng, nhưng chúng vẫn không có khả năng thực hiện những gì chúng ta đã quá quen thuộc trong Linux - các quy trình cô lập. Do đó, lỗi của một luồng có thể làm hỏng toàn bộ máy Java. Nhiều người cố gắng khắc phục nhược điểm này bằng cách dành một JVM riêng cho từng ứng dụng của người dùng để giảm thiểu hậu quả của lỗi. Điều này khá hợp lý nhưng lại không phù hợp với việc chia tỷ lệ.
- Ngoài ra, đối với các ứng dụng hướng đám mây, một chỉ số quan trọng là mật độ dịch vụ trên máy chủ. Chuyển sang phương pháp luận , microservice và Kubernetes làm tăng số lượng máy Java trên mỗi ứng dụng. Nghĩa là, một mặt, tất cả những điều này mang lại sự linh hoạt và độ tin cậy, nhưng đồng thời, mức tiêu thụ bộ nhớ cơ sở về mặt dịch vụ cũng tăng lên và một số chi phí này không phải lúc nào cũng thực sự cần thiết. Ở đây, các tệp thực thi được biên dịch tĩnh được hưởng lợi nhờ các kỹ thuật tối ưu hóa khác nhau, chẳng hạn như loại bỏ mã chết ở mức độ thấp, khi hình ảnh cuối cùng chỉ bao gồm các phần của khung (bao gồm cả chính JDK) mà dịch vụ thực sự sử dụng. Do đó, trình biên dịch gốc của Quarkus giúp đặt dày đặc các phiên bản dịch vụ trên máy chủ mà không ảnh hưởng đến bảo mật.
Trên thực tế, những lập luận trên đã đủ để hiểu sự biện minh cho việc biên soạn bản địa theo quan điểm của những người tham gia dự án Quarkus. Tuy nhiên, có một lý do khác, phi kỹ thuật nhưng cũng quan trọng: trong những năm gần đây, nhiều lập trình viên và công ty phát triển đã từ bỏ Java để chuyển sang các ngôn ngữ lập trình mới, tin rằng Java, cùng với các JVM, ngăn xếp và khung công tác của nó, đã trở nên quá phổ biến. ngốn bộ nhớ, quá chậm, v.v.
Tuy nhiên, thói quen sử dụng cùng một công cụ để giải quyết bất kỳ vấn đề nào . Đôi khi tốt hơn là nên lùi lại một bước và tìm kiếm điều gì đó khác. Và nếu Quarkus khiến mọi người phải dừng lại và suy nghĩ thì điều đó tốt cho toàn bộ hệ sinh thái Java. Quarkus thể hiện quan điểm đổi mới về cách xây dựng các ứng dụng hiệu quả hơn, làm cho Java phù hợp hơn với các kiến trúc ứng dụng mới như serverless. Ngoài ra, do khả năng mở rộng của nó, Quarkus hy vọng sẽ có toàn bộ hệ sinh thái các tiện ích mở rộng Java, tăng đáng kể số lượng khung công tác hỗ trợ biên dịch gốc trong các ứng dụng sẵn có.
Nguồn: www.habr.com