Нативные микросервисы с SparkJava и Graal

Микросервисы, написанные с помощью SparkJava, представляют собой простой Java-код, использующий стандартную библиотеку Java. Никакой магии аннотаций, просто код. Преимущество этого простого стиля программирования в том, что он прост. Это так просто, что нативный компилятор Graal просто компилирует его, не мигая , что в настоящее время очень сложно для более сложных сред, таких как Spring, например.

Комбинация SparkJava / Graal интересна сама по себе, и опыт людей с ней начинает появляться . Кроме того, в качестве библиотеки Java должна быть возможность использовать ее из других языков, основанных на JVM, и мне было интересно, как Graal справится с этим. На самом деле все оказалось просто, и в этом посте мы увидим, как легко создавать нативные микросервисные двоичные файлы для Java, Kotlin и даже Clojure .

Начиная

Если вы не сталкивались с Graal до того, как я предлагаю вам зайти на их сайт и посмотреть, что он предлагает. Здесь мы используем встроенную функцию компиляции, но на самом деле это просто царапина на поверхности.

Чтобы использовать Graal, вам необходимо установить последнюю версию Graal SDK. На момент написания статьи это 1.0.0-rc9 . Я сделал это с помощью SdkMan :

И с тех пор

Затем создайте базовый проект Gradle и добавьте минимальные зависимости:

(Я предполагаю, что вы уже знакомы с Gradle, если вы предпочитаете, чтобы вы могли делать это с Maven . Обратите внимание, что важно, чтобы выбранная вами реализация Slf4j соответствовала версии, требуемой SparkJava.)

В SparkJava конечная точка микросервиса — это, по сути, привязка или route между путем и обратным вызовом в форме лямбда-выражения. Это стандартный пример «Привет, мир», который мы будем использовать в качестве основы. Реальные сервисы, конечно, будут использовать объекты запроса и ответа. Смотрите документацию для более подробной информации.

Чтобы запустить его как программу командной строки, удобно скопировать все зависимости вместе в один каталог. Мы также можем сделать это с Gradle.

Создайте сервис и запустите его, чтобы убедиться, что он работает.

Давайте скомпилируем его в собственный двоичный файл, используя Graal. Команда, к счастью, очень похожа на команду java :

Теперь мы должны иметь наш собственный двоичный файл в текущем каталоге. Давайте запустим это:

Исполняемый файл имеет размер 14 Мб, но посмотрите на это время запуска, 2 мс , в основном мгновенно! По памяти было бы неразумно уделять слишком много внимания top но очевидно, что удаление JVM из среды выполнения имеет свои преимущества. Это особенно важно в системах микросервисов, где развернуто большое количество независимых процессов.

Как насчет Котлина?

Kotlin — это язык JVM, который набирает обороты и не без причины. Сочетание функционального стиля и функций OO, бесшовная совместимость с Java и краткий синтаксис делают его хорошим языком для общего использования и очевидной заменой Java. Чтобы построить наш сервис с Kotlin, сначала мы добавим библиотеку Kotlin в Gradle (на момент написания версии v1.3.10).

И использовать плагин компилятора Kotlin.

С Kotlin наш нелепо простой микросервис становится еще проще.

Создайте сервис и запустите его, чтобы убедиться, что он работает.

Давайте скомпилируем это изначально. Поскольку это Java, команда почти идентична версии Java (компилятор Kotlin автоматически добавляет суффикс Kt к сгенерированным классам).

И запустите это:

Исполняемый файл почти идентичен по размеру и скорости запуска версии Java, как и следовало ожидать, поскольку по сути это тот же код.

Это базовый пример, но сочетание Kotlin для простоты реализации , SparkJava для простоты микросервиса и Graal для простоты развертывания является очень привлекательным предложением для разработки микросервиса.

Тем не менее, кроме более приятного синтаксиса, Kotlin очень похож на Java. Есть и другие языки JVM, которые мы можем использовать, что может продвинуть Graal дальше.

Потребность в Clojure

Использование Clojure для создания микросервисов — интересная идея. Сервисы по своей природе функциональны, фактически сервис — это функция, и динамическая природа языка может сделать его идеальным в некоторых ситуациях, ориентированных на данные.

Вместо того, чтобы использовать Gradle, мы начнем с нового проекта Leiningen :

Зависимости находятся в основном файле project.clj а также в названии основного класса, который мы запустим для запуска сервера.

Clojure совместим с Java, но не в той же степени, что и Kotlin. Чтобы преодолеть различия, я написал пару адаптеров, позволяющих идиоматическому клоюдж-коду использовать классы SparkJava.

(Позже я нашел хорошую статью с полным сервисом, использующим Clojure и SparkJava. Их адаптеры были немного лучше, чем у меня, поэтому я включил некоторые идеи из этой статьи в последующее.)

Затем мы готовы создать контроллер, который мы делаем из метода main, чтобы его было легко вызвать из командной строки. Также обратите внимание, что выше мы использовали директиву gen-class чтобы гарантировать, что основной класс указан в Manifest:

Чтобы упростить создание сервиса, мы можем создать автономную банку с использованием Leiningen.

Как и прежде, мы сначала проверяем, что сервис работает как обычный Java:

Компиляция в нативный образ так же проста, как и в предыдущих примерах с Java и Kotlin.

И запустите это:

Еще раз исходный двоичный файл составляет примерно 15 МБ, и снова время запуска почти мгновенно.

Вывод

Такое использование Graal с другими языками, основанными на JVM, является очень привлекательным предложением и требует более тщательного изучения, однако у меня есть некоторые опасения по поводу производственного использования. Главным образом, если что-то пойдет не так, в открытом доступе очень мало информации, чтобы помочь вам, и еще меньше за пределами чистой Java. С другой стороны, это все проекты с открытым исходным кодом, так что ничего не скрыто 🙂

Другое ограничение заключается в том, что многие библиотеки просто не работают с Graal. Это не совсем отрицательно, потому что это побудит нас вернуться к простым методам кодирования, однако у вас может быть зависимость, которую вы не можете изменить, и это может вызвать серьезные хлопоты. Я думаю, что основным недостатком изначально будет отображение, основанное на отражении, будь то сериализация или разновидности ORM. Уже приложено немало усилий, чтобы сделать многие библиотеки и фреймворки совместимыми с Graal, но это еще рано.

Третье, прежде всего практическое, соображение — чрезвычайно медленная компиляция нативного образа. Даже этот очень простой пример занимает почти минуту, чтобы построить. Конечно, вы можете выполнять разработку, компилируя только байт-код, но тогда могут возникнуть проблемы с совместимостью. Непрерывный конвейер сборки и всесторонние тесты были бы способом уменьшить этот риск.

Очевидно, что для того, чтобы сделать этот сервис полностью функциональным, нужно сделать гораздо больше, и перед тем, как перейти к производственному использованию, необходимо принять соответствующие меры, но если мы решим продолжать использовать простой код, проблемы будут сведены к минимуму.