Автор: 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 содержащих как разработанное приложение так и реализацию фреймворка. В Java EE этого можно добиться используя технологии подобные Wildfly Swarm или TomEE Embedded.
Однако: Как я говорил выше, я не рекомендую делать ваши пакеты установки такими большими. Самая большая проблема с таким подходом – время сборки, так как вам каждый раз приходится много чего копировать из А в Б. А также: При развертывании с использованием контейнеров, таких как Docker, становится неважным поставляется ли ваше приложение вместе с сервером или сервер является частью контейнера.
В случае если контейнер уже включает установленный сервер приложений вы можете сэкономить много времени сборки (контейнера). В этом случае ваш базовый образ не меняется и вы только добавляете ваше (всего несколько-сот-килобайт-ное) приложение – что достигается почти без затрат времени.
Со времен старой J2EE существует миф о том, что «тяжеловесные» серверы приложений потребляют много памяти сразу как только стартуют. Adam Bien опубликовал интересное видео показывающее действительные накладные расходы памяти современных Java EE серверов приложений.
С моей точки зрения одно из самых «легковесных» решений для корпоративных приложений следующее:
От переводчика:
Семён Солдатенко, CC-BY-NC-SA 4.0
перевод работы Stop saying “heavyweight”, Sebastian Daschner, CC BY-NC-SA 4.0
Оригинал: 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
