Облачная разработка на Java: как выбрать фреймворки

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

В результате были разработаны Quarkus и Micronaut, чтобы заполнить пустоту в облачных приложениях с точки зрения языка программирования Java. Чтобы сделать эти фреймворки легкими для микросервисов, важно избегать рефлексии во время выполнения. Это было достигнуто путем объединения GraalVM, генерации кода AOT и использования собственных изображений, а время запуска приложения и его объем памяти были сокращены.

При этом влияние Spring тяжело переоценить, поскольку Quarkus и Micronaut были вдохновлены Spring Boot, потому что нет необходимости изобретать велосипед. Многие из часто используемых аннотаций имеют эквивалентные аналоги как в Quarkus, так и в Micronaut, хотя они могут быть не идентичными. Это означает, что кривая обучения для перехода с Spring Framework на эти фреймворки совершенно некрутая.

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

Однако, разработчики Quarkus пошли еще дальше и создали электронную книгу под названием «Quarkus для разработчиков Spring», чтобы познакомить разработчиков программного обеспечения с Quarkus и предоставить им советы по быстрому и легкому переходу со Spring.

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

Одной из ключевых функций являются контейнеры Inversion of Control (IOC), которые могут немного отличаться в реализации, но имеют общие черты. Правильное использование Dependency Injection (DI) и IOC позволяет нашему коду легче тестироваться, лучше адаптироваться к изменениям и быть слабосвязанным.

Чтобы устранить ограничения собственных образов при использовании рефлексии, и Micronaut, и Quarkus используют компиляцию Ahead-of-Time (AOT) для замены многих процессов генерации времени выполнения. Это помогло сократить как объем памяти, так и время запуска приложения. Эта функция особенно полезна в бессерверных системах, где экземпляры микросервисов могут динамически масштабироваться в зависимости от потребностей балансировки нагрузки. По моему опыту, интеграционные тесты занимают значительно меньше времени с собственными образами, что влияет на время разработки и развертывания.

Декорирование кода аннотациями – распространенный способ использования механизмов в этих фреймворках. Эти декораторы часто полагаются на использование прокси, которые являются объектами, выступающими в качестве посредников между исходным объектом и клиентом. Эти прокси генерируются заранее (AOT), а не создаются во время выполнения с помощью прокси времени выполнения или CGLIB. Одним из известных примеров декоратора аспектно-ориентированного программирования (AOP) является аннотация @Transactional, которая используется для маркировки метода или класса как участвующего в транзакции.

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

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

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

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

Однако одна область, в которой Java испытывает трудности, – это мир серверов, которым часто приходится жонглировать соединениями от тысяч или даже миллионов пользователей. В первые годы инструменты Java были одними из лучших для создания серверных приложений, которые обеспечивали бизнес-логику для всех пользователей. Такие фреймворки Java, как J2EE, Hibernate, Spring и базовая модель сервлетов Java, позволили относительно легко создавать надежные веб-приложения.

Технология процветала до появления JavaScript и Node.js. Node.js привлек к себе много внимания, и разработчики начали переходить на среду выполнения JavaScript. Причин было две: во-первых, разработчики приветствовали возможность запускать один и тот же код на сервере и в браузере-клиенте. Во-вторых, серверы Node.js часто обеспечивали значительно более высокую пропускную способность благодаря своей реактивной модели.

Экосистема Java адаптировалась к конкуренции. Для начала некоторые разработчики приняли такие инструменты, как Google Web Toolkit, который переводит Java в JavaScript. Затем они работали над ускорением Java на сервере. Ранние фреймворки Java для сервера имели одно ограничение: каждому входящему запросу предоставлялся свой собственный поток. Это был чистый способ организации входящих и исходящих данных, но он также был утомителен. Создание потока требует тысяч байтов накладных расходов, что может ограничить количество пользователей, которых может обработать каждый сервер. Node.js использовал другую модель, которая позволяла ему жонглировать гораздо большим количеством пользователей без этих накладных расходов.

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

Современные разработчики Java, ищущие облачный опыт, имеют множество вариантов. Идеальный облачный фреймворк Java использует глубокий опыт, вложенный в платформу Java и ее сторонние библиотеки, одновременно адаптируя их для более быстрой и легкой работы в облаке. Вот пять фреймворков Java, созданных с нуля для разработки и развертывания в облаке.

1. Micronaut

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

Фреймворк создан для поддержки различных языков на основе JVM (в настоящее время Java, Kotlin и Groovy) и запуска их в различных облаках. Предопределенные файлы конфигурации упрощают развертывание серверных или бессерверных функций во всех основных облаках, и есть хорошо написанные страницы документации для всех основных подключений к базам данных.

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

Micronaut предназначен не только для разработки приложений с облачными функциями. Фреймворк достаточно общий для поддержки традиционных ролей и некоторых настольных приложений. Его тесная интеграция с GraalVM позволяет использовать Micronaut для создания собственных приложений.

2. Quarkus

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

3. Spring Cloud Functions

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

Поддержка широкого спектра опций является большой целью проекта. Существуют адаптеры, которые втискивают функции в AWS Lambda, Microsoft Azure, Apache OpenWhisk, Google Cloud Platform и несколько других распространенных сред облачных функций. Существуют также адаптеры для основных потоковых фреймворков, таких, как Apache Kafka, Solace и RabbitMQ, а также автономный вариант Spring Cloud Stream. Упаковка и развертывание в значительной степени автоматизированы, поэтому вы можете сосредоточиться на разработке самих функций.

Команда разработчиков Spring Cloud Functions также усердно работала над устранением многих распространенных ловушек и проблем развертывания в облаке. Spring Cloud Skipper можно использовать для жонглирования развертываниями в нескольких облаках. Spring Cloud Sleuth помогает с отладкой, отслеживая потоки данных. Spring Cloud Security управляет многими рутинными задачами по защите приложения, чтобы только нужные люди могли выполнять функции. Существует несколько десятков различных подпроектов.

4. Vert.x

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

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

Этот проект является частью экосистемы Eclipse. Разнообразие версий и параметров дает большую свободу. Например, генератор приложений Vert.x будет создавать код Java или Kotlin с десятками потенциальных зависимостей, таких как шаблонизаторы или поддержка API.

5. Eclipse MicroProfile

Команда Eclipse создала проект MicroProfile как способ адаптации Jakarta EE для запуска небольших созвездий микросервисов. Он устраняет часть накладных расходов более крупной платформы, объединяя библиотеки, которые являются довольно стандартными для многих архитектур микросервисов. Этот подход наиболее привлекателен для разработчиков, которые могут переносить код из более крупных, старых проектов Java EE или Jakarta EE. Большая часть конфигурации и архитектуры остается прежней. Во многих случаях изменения незначительны. Но дизайн поощряет такие решения, которые упрощают создание более легкого и быстрого кода. Некоторые разработчики используют MicroProfile как ступеньку на пути к более современным облачным фреймворкам.

Заключение

Какие выбрать фреймворки? Сейчас есть куча отличных технологий, которые не стыдно использовать на проде – Spring (Pivotal), MicroProfile (Eclipse), Quarkus (RedHat), Micronaut (Object Computing), и другие. Рынок сейчас устроен так, что Spring задоминировал совершенно всех. Если Quarkus и Micronaut воспринимаются как смелые эксперименты, то Spring давно зарекомендовал себя как «дефолтная» Java-технология, с тех самых пор как JavaEE начала трещать по швам.