Что нас ждет в будущем с GraalVM?
25 октября 2022 г.Прежде чем я перейду к теме поста на этой неделе, у меня есть другие отличные новости. Я только что отправил издателю последнюю (14-ю) главу моей будущей книги по отладке под названием «Практическая отладка в масштабе». Облачная отладка в Kubernetes и продакшене». Было весело писать, и я надеюсь, вам понравится это читать. Подпишитесь на меня или смотрите это пространство для обновления со ссылкой на предварительный заказ. Он должен скоро появиться…
Это идеальное время, чтобы поднять этот вопрос. Так же, как Spring Native выходит на первый план. Не пора ли перейти на GraalVM? Спойлер: это зависит. Да, если вы создаете бессерверную версию, но, вероятно, нет, если вы создаете что-то еще. За некоторыми исключениями для некоторых микросервисов.
Прежде чем я начну, я хочу уточнить, что я говорю о нативном образе (SubstrateVM), который имеет в виду большинство людей, говоря о GraalVM. Эта конкретная функция взяла на себя гораздо более крупный и амбициозный проект, который включает в себя некоторые удивительные возможности, такие как программирование полиглотов. Собственные образы GraalVM позволяют нам компилировать наши Java-проекты в собственный код.
Он выполняет анализ и удаляет ненужные вещи, он может значительно уменьшить размер и время запуска бинарного файла. Я видел 10-20-кратное улучшение времени запуска, это много. Использование оперативной памяти также иногда намного ниже по той же шкале, но обычно не так значительно.
Возможно, по иронии судьбы GraalVM может быть даже более безопасным, чем обычная JVM, поскольку в ней отсутствуют динамические функции. Атаку сериализацией объектов, вероятно, будет гораздо сложнее провести против GraalVM. Надеюсь, я не бросил вызов каждому исследователю безопасности прямо сейчас, чтобы доказать свою неправоту…
Недостатки
Я фанат производительности. С этими числами я обычно спешил бы скомпилировать свои приложения в нативный код и перейти к более высокой производительности. Но ситуация не столь однозначна. JVM может по-прежнему работать лучше в производстве для более длительных процессов. Традиционные развертывания не так зависят от времени запуска или даже от оперативной памяти. Есть некоторые микросервисы, на которые могут повлиять и те, и другие, но в большинстве случаев это не единственное соображение.
Во-первых, история производительности GraalVM имеет больше нюансов, чем просто время запуска. Для долго работающих больших приложений разница во времени запуска и памяти не так значительна. Производительность во время выполнения не такая четкая история и часто может быть в пользу других JVM. Это довольно сложная история, поскольку нативное изображение поддерживает профилирование для создания подсказок по оптимизации для компилятора и других интересных инструментов.
Некоторые библиотеки сложно адаптировать к собственным изображениям (например, FreeMarker), есть такие хитрости, как трассировка агент, который можно использовать на обычной JVM для обнаружения динамического кода. Используя результаты работы агента трассировки, вы можете упаковать нативное приложение. Но это более сложный проект, чем просто добавление зависимости к maven.
Скорость компиляции GraalVM значительно улучшилась за последние несколько лет, но она все еще намного медленнее, чем обычная сборка maven. Но это не худшая часть. Хуже всего то, что история с относительно скудной наблюдаемостью.
Чтобы было ясно, поддерживаются такие инструменты, как JFR и другие возможности Java. Даже JMX на подходе. Это означает, что вы можете использовать консоль и другие потрясающие возможности JVM в собственном исполняемом файле. Это впечатляюще. Вы даже можете отлаживать собственный исполняемый файл, IntelliJ/IDEA только что добавили встроенную поддержку для прямой отладки исполняемого файла. Еще одно потрясающее улучшение!
Но некоторые вещи по-прежнему не поддерживаются. Агентский API — это место, где находятся многие расширения уровня JVM. Судя по всему, в внесены некоторые изменения в поддержку этих функций, но, вероятно, не все, что описано в инструменты. Тем не менее, это было бы огромным стимулом.
Так стоит ли его использовать?
В последний раз я запускал проект Spring Boot задолго до версии 3.0 и выбрал раннюю предварительную версию Spring Native в качестве опции в мастере создания Initializr. . Так что я очень поддерживаю эксперименты с GraalVM, я думаю, что это отличный вариант, который со временем становится все более привлекательным. На самом деле, для многих инструментов CLI это уже лучший вариант.
Должны ли мы использовать его в производстве — другой вопрос. В некоторых случаях это просто нецелесообразно. Если вы создаете приложения с графическим интерфейсом или полагаетесь на динамическую загрузку классов, то ситуация немая. Но опять же, Spring Boot 3 очень интересен, и я очень хочу перенести проекты на него (и JDK 17). Когда мы переносим эти проекты, должен ли я стремиться к тому, чтобы «сначала нативные»?
На данный момент я намереваюсь иметь цель сборки собственного образа GraalVM в CI. Однако мы, вероятно, будем развертывать в облаке стандартную JVM. Основными причинами этого являются все вышеперечисленные, но прежде всего аспекты наблюдаемости и знакомства. Когда мы строим для масштабирования, индивидуальная производительность конкретного узла не так важна. Это важно, но еще важнее общая картина и возможность масштабного решения проблем.
Представьте, что вы просматриваете трассировки между несколькими серверами, смотрите на тайминги и отслеживаете проблему до ее основной причины. Это лежит в основе проблем крупномасштабного производства. Трассировки помогают нам понять основную причину проблемы с производительностью или сбоя. Прелесть трейсов в том, что они бесплатны. Как и в случае с бесплатными, нам не нужно писать для них много кода. Наш код легко настраивается для включения этой функции.
Восходящей звездой в мире трассировки является OpenTelemetry, использующая агентский API. Это не уникально в этой области; API-интерфейс агента широко распространен в отрасли. Без агентского API многие функции, необходимые для крупномасштабных систем (отслеживание, наблюдаемость разработчиков, обработка ошибок, APM и т. д.), фактически исчезнут.
Когда все в порядке?
Бессерверная версия — идеальный вариант. Хотя ему также нужны инструменты для наблюдения за разработчиками, у него уже есть некоторые проблемы с такими расширениями. Для например. Lambda не работает с некоторыми конфигурациями агента. Обратите внимание, что существуют решения для отслеживания для AWS, поэтому этот аспект учитывается. Для бессерверных приложений использование собственного образа снижает затраты, ускоряет получение результатов и делает это бесплатно. Это простое решение.
В других случаях я стараюсь держать руку на пульсе, так как все меняется в одночасье. Вот почему я рекомендую поэкспериментировать с GraalVM прямо сейчас. Это обеспечит вам хорошее положение в будущем, когда мы можем переместить виртуальные машины.
Причина, по которой мы до сих пор развертываем стандартные JVM, заключается в том, что в настоящее время наши развертывания не видят заметного преимущества от GraalVM. У нас недостаточно затрат на масштабирование и увеличение/уменьшение, чтобы сделать переход оправданным.
Наконец-то
В обсуждении в Твиттере я предсказал, что на 50 лет потребуется 10 лет. % разработчиков Java перейдут на GraalVM, если только Лейден внезапно не изменит динамику и не сделает стандартную JVM намного более эффективной. Java-разработчики двигаются медленно, я считаю это фичей, а не багом.
В 22 года GraalVM находится в совершенно ином положении, чем всего 3 года назад. Его вспомогательные инструменты и сторонняя поддержка, наконец, набирают обороты, и он готов преодолеть пропасть. Я думаю, что это уже сделано для инструментов CLI. Даже если вы не возьмете его в руки прямо сейчас, попробуйте, потому что при работе с ним можно многому научиться.
Одним из самых больших преимуществ, которые он дает, является внимание к отражающему коду, который мы используем во всех наших приложениях. Сокращение этого кода повысит качество приложения и улучшит императивную логику, которую будет легче отлаживать. Устранит ошибки и, возможно, улучшит производительность для обычных JVM. Работа, которую поставщики должны выполнять для поддержки GraalVM, важна для всех нас.
Я также почти не коснулся многоязычных аспектов GraalVM, которые являются одними из его самых интересных функций. Интеграция кода Java и Python в нативный двоичный файл — мощное предложение.
Также опубликовано здесь.
Оригинал