Substrate VM написана на Java, и ее код компилируется в нативный исполняемый файл. Получаемая в результате программа быстрее запускается и, соответственно, дает более низкие издержки в использовании памяти по сравнению с Java VM. Теперь есть контейнеры, а им не нужна JVM. Обычные контейнерные приложения, создаваемые при помощи Spring boot, имеют лишний уровень абстрагирования, который совершенно не нужен в мире, где есть Kubernetes. Приложение Java, работающее на JVM внутри контейнера оставляет этот контейнер неизменным, поскольку в современном виде готовый продукт – это контейнер, а не приложение. Теперь нужно упаковывать контейнеры, а не WAR-файлы. Поэтому, все издержки, связанные с использованием приложения на JVM внутри контейнера становятся бесполезными, и AOT становится весьма логичным решением, если вы собираетесь упаковывать ваши приложения в контейнеры.
При этом стоит признать, что AOT-компиляция серьезно ограничивает динамические возможности Java (загрузка классов во время исполнения, рефлексия, прокси, т. д.). На практике это означает, что 90% экосистемы Java без изменений работать не будет. Соответственно, экосистема Java должна адаптироваться. Однако, это вполне возможно сделать во время сборки.
Версию Java не имеет смысла брать ниже 11 – новые версии куда лучше годятся для облачного использования. При выборе фреймворков – есть множество отличных технологий, которые не стыдно использовать на проде – Spring (Pivotal), MicroProfile (Eclipse), Quarkus (RedHat), Micronaut (Object Computing), и другие.
Рынок сейчас устроен так, что Spring задоминировал совершенно всех. Если Quarkus и Micronaut воспринимаются как смелые эксперименты, то Spring давно зарекомендовал себя как «дефолтная» Java-технология, с тех самых пор как JavaEE начала трещать по швам. Можно считать это Spring-шовинизмом, но писать туториал сразу по всему зоопарку технологий – задача непосильная.
Перейдем к тому, как перенести Java-приложение на современную облачную платформу.
Если уже имеется ПО на основе микросервисной архитектуры, первое, что вам понадобится вне зависимости от выбранного поставщика облачных услуг – это платформа для управления контейнеризированными компонентами или «среда оркестрации контейнеров». Лучшим выбором, на мой взгляд является Kubernetes – переносимая платформа с открытым исходным кодом, которая обеспечивает масштабирование при использовании нескольких облачных сред. Это лидирующий на рынке продукт, который в 2020 году использовали 59% Java-разработчиков из крупных организаций.
Кроме того, вам необходим контроллер входящего трафика. Он связывает пользователя с конкретными экземплярами контейнеризированного приложения и выполняет функции балансировщика HTTP-нагрузки и прокси-сервера, например NGINX ingress controller с открытым исходным кодом.
Подготовившись к созданию и облачному развертыванию микросервисных контейнеров, стоит рассмотреть три подхода к этому процессу: традиционный, с применением Quarkus и основанный на нативных образах.
1. JVM в Linux-контейнерах
В мире облачно-ориентированного ПО принято опираться на 4 важных методологии разработки: микросервисы, контейнеры, непрерывная интеграция/непрерывное развертывание (CI/CD) и DevOps. Запуск Docker-контейнеров с облачными Java-приложениями в виртуальных машинах на Linux – простой подход, дающий мощную оптимизацию. Данный метод – в некотором роде наследник способа развертывания файлов WAR на веб-серверах до виртуализации на уровне ОС.
В качестве примера приведем конфигурацию Linux-контейнера: хостовая ОС гипервизора в облаке, гостевая ОС на ВМ в качестве главной ОС для Docker, Docker в гостевой ОС, предоставляющий среду выполнения контейнеров, и JVM внутри контейнера для выполнения байт-кода Java.
Axiom JDK рекомендует использовать Axiom JDK в качестве среды исполнения внутри контейнера. Axiom JDK отлично сочетается с большинством дистрибутивов Linux, включая легковесный Alpine. Такая сборка сократит статический и динамический объем используемой памяти, что в результате снизит затраты и увеличит общую прибыль.
Раньше такой подход сопровождался трудностями при управлении ресурсами контейнера. Если размер динамической памяти превышал ограничение по объему памяти контейнера, реализуемое с помощью контрольной группы (cgroups)), ОС могла остановить работу приложения.
Сейчас эта проблема изучена и по большей части решена сообществом OpenJDK, поэтому шанс столкнуться с данной ситуацией составляет не более 1%.
2. MicroProfile и Quarkus
Еще один популярный подход к развертыванию в облаке – использование различных фреймворков с поддержкой MicroProfile, оптимизирующих применение Jakarta EE для микросервисов. Часть фреймворков включает собственные API, например, Micronaut. Другие, такие как Dropwizard, опираются на библиотеки для легковесной упаковки приложений. Некоторые из них разрабатываются крупными поставщиками JDK, например Helidon (Oracle) или Quarkus (Red Hat).
Рассмотрим подробнее проект Quarkus – фреймворк для Java для full-stack разработки, ориентированный на Kubernetes. Он адаптирован как для OpenJDK с виртуальной машиной HotSpot, так и для GraalVM в варианте нативной компиляции. Для создания микросервисов Quarkus использует библиотеки Eclipse MicroProfile и разнообразные инструменты: Apache Kafka, Camel, внедрение зависимостей, объектно-реляционное отображение Hibernate (аннотации JPA и JTA), RESTEasy (JAX-RS), Vert.x, Apache Camel и другие.
Другие преимущества проекта – поддержка плагинов Maven и Gradle (например, для запуска приложения Quarkus в режиме разработки на локальной или удаленной машине) и относительно короткое время запуска. Расширения Quarkus, встроенные в фреймворк или индивидуальные, упрощают разработку и развертывание микросервисов.
Тем не менее у подхода с применением MicroProfile есть ряд недостатков:
- Quarkus в значительной степени опирается на функции Kubernetes при выполнении задач в облаке (одна из них – управление трафиком). Компании, которые не использовали Kubernetes, столкнутся с трудностями, поскольку переход на него требует времени и сил;
- Внедрение этой технологии невозможно без отладки и тестирования. Например, если включить нативную компиляцию без установки расширения Quarkus, задача Gradle просто не выполнится, и при этом система не выведет сообщение об ошибке;
- Для Quarkus и других фреймворков создано меньше библиотек по сравнению с ближайшим конкурентом – Spring Boot.
3. Axiom NIK и Spring Native
Третий вариант основан на совмещении среды исполнения с целевым приложением. Представляем Native Image – прогрессивный облачно-ориентированный подход к разработке на Java, который объединяет функции JDK, заложенные в коде, и современные фичи. Для его создания подходит Axiom Native Image Kit – инструмент на базе GraalVM CE и технологий Axiom JDK. Axiom NIK преобразует байт-код Java в платформозависимый двоичный код для формирования нативных исполняемых файлов с малым размером и быстрым временем старта.
Axiom NIK поддерживает Alpine Linux с библиотекой musl и поэтому максимально снижает потребление ресурсов, экономит память и позволяет достичь рекордного времени запуска (до десятой доли секунды).
Однако подход Native Image также связан с ограничениями. Иная модель оптимизации и предположение об ограниченности зависимостей в некоторых ситуациях приводят к нестандартному поведению приложений на Java. Следовательно, оптимизация такого рода подойдет не для любого ПО.
Решение данной проблемы заключается в применении Spring Framework и Spring Native – экспериментального набора инструментов и подходов для преобразования приложений Spring в нативные исполняемые файлы. Эти инструменты помогают преодолеть некоторые упомянутые ограничения нативных образов, а также обеспечивают нативное развертывание небольших контейнеров.
Заключение
Для успешной разработки облачных приложений необходимы специализированные навыки и знания, такие как использование облачных платформ, контейнеризация приложений, автоматизация процессов развертывания и мониторинга. Кроме того, важным элементом является обеспечение безопасности данных и защиты от угроз в облачной среде.
Подытоживая, сочетание приведенных в статье инструментов дает продвинутый и в то же время простой и эффективный метод создания облачных приложений на Java.
У каждого из подходов – свои преимущества и недостатки, поэтому вам решать, какой из них оптимален для ваших приложений.
.png&w=640&q=75)
