it-roy-ru.com

Советы по развертыванию файлов war против исполняемого jar со встроенным контейнером

Похоже, что в Java пространстве наблюдается тенденция отходить от развертывания Java веб-приложений в контейнере сервлетов Java (или на сервере приложений) в форме военного файла (или ear). файл) и вместо этого упакуйте приложение как исполняемый файл jar со встроенным сервлетом/HTTP-сервером, таким как jetty И я имею это в виду в большей степени из-за того, что новые платформы влияют на то, как разрабатываются и разворачиваются новые приложения, а не на то, как приложения доставляются конечным пользователям (потому что, например, я понимаю, почему Jenkins использует встроенный контейнер, который очень легко захватывать и использовать ). Примеры фреймворков, в которых используется опция jar для исполняемого файла: Dropwizard , Spring Boot и Play (хорошо, что он работает не на контейнере сервлета, а на HTTP-сервер встроен).

Мой вопрос заключается в том, что из среды, в которой мы развернули наши (до этого момента, в основном, Struts2) приложения на одном сервере приложений Tomcat, какие изменения, рекомендации или соображения необходимо принять, если мы планируем использовать подход со встроенным контейнером ? В настоящее время у нас есть около 10 собственных приложений, работающих на одном сервере Tomcat, и для этих небольших приложений возможность совместного использования ресурсов и управления ими на одном сервере является приятной. Наши приложения не предназначены для распространения среди конечных пользователей в их среде. Однако, продвигаясь вперед, если мы решим использовать более новую Java среду, должен ли этот подход измениться? Побуждается ли переход к исполняемым банкам растущим использованием облачных развертываний (например, Heroku)?

Если у вас есть опыт управления несколькими приложениями в стиле развертывания Play по сравнению с традиционным развертыванием военных файлов на одном сервере приложений, поделитесь своими мыслями.

80
Brice Roncace

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

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


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

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

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

Некоторые другие моменты:

  • Встроенный сервер можно оптимизировать для фреймворка или лучше интегрировать с инструментами фреймворка (например, с игровой консолью).
  • Не во всех облачных средах имеются настраиваемые образы машин. Вместо написания сценариев инициализации для загрузки и настройки контейнеров сервлетов использование специального программного обеспечения для развертывания облачных приложений намного проще.
  • Мне еще предстоит найти установку Tomcat, которая не приветствует вас ошибка пространства perm gen каждые несколько повторных развертываний вашего приложения. Немного больше времени для (повторного) запуска встроенных серверов - это не проблема, когда вы можете почти мгновенно переключаться между промежуточными и производственными экземплярами без простоев.
  • Как уже упоминалось в вопросе, для конечного пользователя очень удобно просто запустить приложение.
  • Встроенные серверы портативны и удобны для разработки. Сегодня все быстро , прототипы и MVP должны быть созданы и доставлены как можно быстрее. Никто не хочет тратить слишком много времени на настройку среды для каждого разработчика.
74
kapex