Обновить

Прекратите повторять «тяжеловесный»

Java
Автор оригинала: Sebastian Daschner
Автор: Sebastian Daschner
Оригинал: https://blog.sebastian-daschner.com/entries/stop_saying_heavyweight (09 апреля 2016)
Перевод: Семён Солдатенко

При разработке корпоративных Java приложений приходится выбирать – использовать Java EE или какой-нибудь другой «легковесный» фреймворк. Но что делает корпоративный фреймворк легковесным?

Мы как разработчики в основном должны заботиться о процессе разработки. Наше время драгоценно (и дорого) и чем меньше времени мы потратим на накладные расходы, тем лучше.

Время сборки


Это время в основном складывается из времени на компиляцию, развертывание и тестирование приложения – локально или в специальном окружении. Чтобы время на полный круг было как можно короче, компиляция не должна тянуться больше чем несколько секунд. Да, секунд.

Использование Java EE имеет большое преимущество в том, что разработчик может положится на стандарт, который позволяет разрабатывать опираясь на API – в основном просто интерфейсы и аннотации – при том, что действительная реализация фреймворка не включается в приложение. Собственно зависимость Java EE «поставляется» сервером приложений, что означает, что она требуется только для компиляции, а не включается в пакет установки. У этого есть побочный эффект который состоит в том, что war-файл в основном остается пустым – он содержит только class файлы вашего приложения. А всё остальное должно быть предоставлено Java EE реализацией.

Пока вы будете оставаться тощим и минималистичным, что означает использовать только API Java EE (7), а не сторонние зависимости – если только в этом не возникнет действительная необходимость для ваших бизнес кейсов – вы можете добиться времени компиляции в пределах нескольких секунд. Основные причины медленной сборки либо в медленных (интеграционных) тестах, либо в больших пакетах установки, соответственно требующих много чего копировать.

Размер пакета установки


Типичный простой Java EE war файл имеет размер около нескольких сотен килобайт по сравнению с 50 и более мегабайтами если вы поставляете реализацию даже маленького (ну вы знаете, «легковесного») фреймворка с ним.

Если вы учтёте сервер приложений плюс ваше приложение тогда результат для случая Java EE окажется больше. Но: В целом процесс разработки будет быстрее, так как каждый раз при сборке создаются килобайты. Сервер приложений обычно уже установлен на вашей машине для разработки – или в любом другом окружении – и движущиеся части остаются небольшими. В результате получаем более короткое время сборки и развертывания как на машине разработчика так и на сервере Непрерывной Интеграции. А также: Когда вы размещаете ваши пакеты установки в централизованный репозиторий (Nexus или Maven central, и т. п.) вы также экономите и время, и трафик.

Время развертывания


Все современные Java EE 7 серверы приложений (такие как Wildfly, TomEE, Glassfish / Payara, WLP) демонстрируют очень короткое время на развертывание приложения. В рамках их модульной системы (такой как OSGi) они могут загружать только необходимые компоненты и запускать приложение в течении нескольких секунд.

Сравнивая с другим фреймворком (таким как Spring) работающим на Tomcat самое короткое время развертывания которое я когда либо замерял было как минимум 15 секунд – для простого «Hello World» приложения – при измерении на такой же машине.

Толстые JAR-ы / Интеграция с контейнером


В новом мире микросервисов принято поставлять приложения в виде самостоятельных jar содержащих как разработанное приложение так и реализацию фреймворка. В Java EE этого можно добиться используя технологии подобные Wildfly Swarm или TomEE Embedded.

Однако: Как я говорил выше, я не рекомендую делать ваши пакеты установки такими большими. Самая большая проблема с таким подходом – время сборки, так как вам каждый раз приходится много чего копировать из А в Б. А также: При развертывании с использованием контейнеров, таких как Docker, становится неважным поставляется ли ваше приложение вместе с сервером или сервер является частью контейнера.

В случае если контейнер уже включает установленный сервер приложений вы можете сэкономить много времени сборки (контейнера). В этом случае ваш базовый образ не меняется и вы только добавляете ваше (всего несколько-сот-килобайт-ное) приложение – что достигается почти без затрат времени.

Потребление памяти


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

Заключение


С моей точки зрения одно из самых «легковесных» решений для корпоративных приложений следующее:
  • Java EE 7 и Java 8 с использованием только API которое предоставляется сервером
  • Небольшой war файл содержащий только бизнес-логику плюс минимальные конфигурации (такие как JAX-RS ресурсы или JPA)
  • Быстрые модульные тесты без тестовых фреймворков с внедренным контейнером (только простой JUnit)
  • Развертывание на основе контейнеров из базовых образов содержащих все необходимые компоненты, за исключением приложения
  • Процесс сборки опирающийся на Непрерывную Поставку который развертывает приложение в контейнеры, на каждый коммит
  • Автоматическое системное тестирование развернутого в контейнер приложения (чтобы подтвердить высокое качество приложения без необходимости интеграционного тестирования; при этом разработчики всё также будут получать быстрый отклик)

От переводчика:

  • Корпоративное приложение — Enterprise Application
  • Фреймворк — Framework
  • Пакет установки — Deployment artifact
  • Бизнес кейс — Business use case

Семён Солдатенко, CC-BY-NC-SA 4.0
перевод работы Stop saying “heavyweight”, Sebastian Daschner, CC BY-NC-SA 4.0
Теги:java eewildflytomeespringmicroservices
Хабы: Java
Рейтинг +2
Количество просмотров 20,1k Добавить в закладки 31
Комментарии
Комментарии 67

Похожие публикации

Факультет Java-разработки
10 марта 2021180 000 ₽GeekBrains
Java Developer. Professional
11 марта 202160 000 ₽OTUS
Java QA Engineer
16 марта 202160 000 ₽OTUS
Java-разработчик
14 марта 2021146 090 ₽Специалист.ру

Лучшие публикации за сутки